Building a 10.2 system from source

Hi, I'm preparing to build a 10.2 system from source but I'm not sure about the difference between these versions:
  1. http://svnweb.freebsd.org/base/release/10.2.0/
  2. http://svnweb.freebsd.org/base/releng/10.2/
  3. http://svnweb.freebsd.org/base/stable/10/
And the ports versions:
  1. http://svn0.us-east.freebsd.org/ports/tags/RELEASE_10_2_0/
  2. http://svn0.us-east.freebsd.org/ports/branches/2015Q3/
  3. http://svn0.us-east.freebsd.org/ports/head/
My goal is to have a coherent, stable base system that is roughly equivalent to the 10.2 release with patches. The ideal ports system would be a well tested recent version.

Any suggestions?
 
This is 10.2-RELEASE without patches. Do not use. AFAIK checking this out gets you the same sources as the src.txz tarballs on the FTP servers.

This is the one you want. Security patches are applied here.
This will become 10.3-RELEASE eventually.

These articles talk about how FreeBSD releases are created and what all these branches mean: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/ and https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.html

The current quarterly branch of the ports tree. More stable than head. This is probably what you want. 10.2-RELEASE's binary packages updates are build from the latest quarterly branch.
 
This is the one you want. Security patches are applied here.

These articles talk about how FreeBSD releases are created and what all these branches mean: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/ and https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.html

The current quarterly branch of the ports tree. More stable than head. This is probably what you want. 10.2-RELEASE's binary packages updates are build from the latest quarterly branch.

Awesome, and thanks for the doc links! Moving forward with /base/releng/10.2/ and /ports/branches/2015Q3/
 
svn checkout svn+ssh://repo.freebsd.org/base/releng/10.2 /usr/src
Code:
svn: E210002: Unable to connect to a repository at URL 'svn+ssh://repo.freebsd.org/base/releng/10.2'
svn: E210002: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file.
svn: E210002: Network connection closed unexpectedly
svn checkout http://svn0.us-east.freebsd.org/base/releng/10.2 /usr/src
Code:
svn: E175002: Unable to connect to a repository at URL 'http://svn0.us-east.freebsd.org/base/releng/10.2'
svn: E175002: Unexpected HTTP status 400 'Bad Request' on '/base/releng/10.2'
svn checkout https://svn0.us-east.freebsd.org/base/releng/10.2 /usr/src
Code:
Error validating server certificate for 'https://svn0.us-east.freebsd.org:443':
 - The certificate is not issued by a trusted authority. Use the
  fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: svnmir.ysv.FreeBSD.org
 - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT
 - Issuer: clusteradm, FreeBSD.org, CA, US(clusteradm@FreeBSD.org)
 - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61
(R)eject, accept (t)emporarily or accept (p)ermanently? p
svn: E000054: Unable to connect to a repository at URL 'https://svn0.us-east.freebsd.org/base/releng/10.2'
svn: E000054: Error running context: Connection reset by peer
svn checkout https://svn0.us-west.freebsd.org/base/releng/10.2 /usr/src
Code:
Error validating server certificate for 'https://svn0.us-west.freebsd.org:443':
 - The certificate is not issued by a trusted authority. Use the
  fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: svnmir.ysv.FreeBSD.org
 - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT
 - Issuer: clusteradm, FreeBSD.org, CA, US(clusteradm@FreeBSD.org)
 - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61
(R)eject, accept (t)emporarily or accept (p)ermanently? p
Success! (but WTF?)
 
Please use "svn.FreeBSD.org". The other mirrors use self signed certificates which is why those errors came up. The SSH access at "repo.FreeBSD.org" host is only for committers.
 
Use
svn checkout https://svn.FreeBSD.org/base/releng/10.2 /usr/src
and
svn checkout https://svn.FreeBSD.org/ports/branches/2015Q3 /usr/ports

svn.FreeBSD.org will automatically choose a mirror near you.
 
Please use "svn.FreeBSD.org". The other mirrors use self signed certificates which is why those errors came up. The SSH access at "repo.FreeBSD.org" host is only for committers.

Use
svn checkout https://svn.freebsd.org/base/releng/10.2 /usr/src
and
svn checkout https://svn.freebsd.org/ports/branches/2015Q3 /usr/ports

svn.freebsd.org will automatically choose a mirror near you.

Nice, thanks. The Subversion Primer is a little misleading but the canonical(?) method *is* buried in the Using Subversion document. It's sometimes a bit difficult to sort out [within the docs] what is a working example (and/or recommended best practice), e.g.,
# svn checkout [I][URL]https://svn.FreeBSD.org[/URL][/I]/ports/head /usr/ports

and what is an abstract form or general hint, e.g.,
# svn checkout [I]svn-mirror[/I]/[I]repository[/I]/[I]branch[/I] [I]lwcdir[/I]

I'm glad there is an experienced community to help smooth out the rough spots.
 
Hello. Yes the first link is part of the committer's guide so there is quite a bit of information that isn't helpful in this situation. The second link from the FreeBSD Handbook is targeted at normal users.
 
So, what should one do if a checkout ends (presumably unfinished) with:
Code:
svn: E120106: ra_serf: The server sent a truncated HTTP response body.
 
And the ports checkout ended (unfinished) with:
Code:
svn: E120108: Error retrieving REPORT: The server unexpectedly closed the connection.
 
Interesting. Is this repeatable? I just checked out one of the directories without an error. What does svn info and svn status inside the directory say?
 
Interesting. Is this repeatable? I just checked out one of the directories without an error. What does svn info and svn status inside the directory say?
svn info
Code:
Path: .
Working Copy Root Path: /usr/ports
URL: https://svn0.us-west.freebsd.org/ports/branches/2015Q3
Relative URL: ^/branches/2015Q3
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 395736
Node Kind: directory
Schedule: normal
svn status plows through the files, each printed like this (the last one):
Code:
  L  vietnamese/x-unikey
I don't like the idea of putting load on the servers and network but I might delete /usr/src, /usr/ports, and /usr/doc and initiate a new checkout with
svn.FreeBSD.org rather than svn0.us-west.freebsd.org (unless there is a more elegant solution).
 
All the files are locked. How about a svn cleanup to remove the locks and try just a svn up.

Oops, just did a rm -rf src ports doc and launched new checkouts with the proper address. *But*, if any of these checkouts face-plant, I'll happily pursue the svn cleanup svn up approach. (Too much coffee today).
 
sometimes a bit difficult to sort out [within the docs] what is a working example (and/or recommended best practice)
In the HTML documents, user input is shown in bold. Replaceable portions (things that are not literal, that the user is supposed to replace with a real value) are shown in italics.
 
Hi, I'm preparing for a more custom build of the system source for my hardware and use case. Where might I find a list of module names & descriptions for the make.conf(5) variable "WITHOUT_MODULES"?
 
Is there any advantage to compiling drivers into the kernel? There seems to be more flexibility if they are kept as modules that can be loaded and unloaded.
 
Source modules that can be turned on and off are documented in src.conf(5).

There is not much advantage to building drivers into the kernel, except that they are there from boot without being loaded manually or in /boot/loader.conf. Drivers built into the kernel can be a disadvantage if they recognize hardware that the user might want to ignore, like motherboard RAID controllers.
 
Source modules that can be turned on and off are documented in src.conf(5).
My /etc/make.conf looks like this:
Code:
CPUTYPE?=k8
MAKE_SHELL?=sh
INSTALL+= -C
#WITHOUT_MODULES=  bktr plip
NO_PROFILE=true  # Avoid compiling profiled libraries
PRINTERDEVICE=ascii
TOP_TABLE_SIZE=101
DOC_LANG=en_US.ISO8859-1
It was derived from /usr/share/examples/etc/make.conf which has lines like:
Code:
# The list of modules to build instead of all of them.
#MODULES_OVERRIDE=  linux ipfw
#
# The list of modules to never build, applied *after* MODULES_OVERRIDE.
#WITHOUT_MODULES=  bktr plip
Some of those module names, "linux ipfw bktr plip", don't seem to have obvious correlatives in src.conf(5) variables.

For completeness, my /etc/src.conf file looks like this:
Code:
WITHOUT_ATM=true
WITHOUT_ZFS=true
WITHOUT_PROFILE=true
There is not much advantage to building drivers into the kernel, except that they are there from boot without being loaded manually or in /boot/loader.conf. Drivers built into the kernel can be a disadvantage if they recognize hardware that the user might want to ignore, like motherboard RAID controllers.
Groovy, that's what I suspected. Thanks for the confirmation.
 
Don't duplicate settings in both files. Put everything related to source modules in src.conf. There are some universal settings that have to go in make.conf but other than that, try to keep it minimal.
 
I found that a careful reading of section 23.6.2. Configuration Files is helpful. In summary:

[FONT=Times New Roman]Any options which are added to /etc/make.conf will control the how make(1) runs and builds programs. These options take effect every time make(1) is used, including compiling applications from the Ports Collection, compiling custom C programs, or building the FreeBSD operating system. [snip] Unlike /etc/make.conf, the contents of /etc/src.conf only take effect when the FreeBSD operating system itself is being built.[/FONT]​

Given that, I suppose in my current setup: [FONT=Courier New]TOP_TABLE_SIZE=101,[/FONT] could be moved to /etc/src.conf but, in this case, I think it would be simpler to remain consistent with the examples and the man pages.

Update
Some of those module names, "linux ipfw bktr plip", don't seem to have obvious correlatives in src.conf(5) variables.
After some grep(1)'ing and exploring in the source tree, I suspect the kernel module names that can be used with the make.conf(5) variable: WITHOUT_MODULES, might be equivalent to the names of the subdirectories under /usr/src/sys/modules/.
 
Back
Top