OpenBSD release to -current: Xenocara question

[IronForge]

Greetings:

I decided to try out the 4.5 -current and reinstalled from scratch.

I was able to checkout the current tree; but I think I confused the Upgrade Process. I was under the impression from the chart of the FAQ Section 5.3.2, we "check out/fetch" the current and build from it.

I was able to checkout/update (since I just reinstalled release) src and ports; but since Xenocara wasn't built, I had errors from cvs.

I presumed that it may be prudent to try to "build" Xenocara before I tried to rebuild the Kernel and Userland per 5.3.1:

5.3.1 - Overview of the building process
Building OpenBSD from source involves a number of steps:

* Upgrading to the closest available binary.
* Fetching the appropriate source code.
* Building the new kernel and booting from it.
* Building "userland" ("make build").

There are a couple additional steps that some users may wish to perform, depending on the purpose of the build and if X is installed:

* Building a "release".
* Building X

I ended up getting an error during the Xenocara build:

===> lib/libdrm/intel
mkdep -a -I/usr/xenocara/lib/libdrm/intel -I/usr/xenocara/lib/libdrm/intel/.. -I/usr/X11R6/include -I/usr/include/dev/pci/drm /usr/xenocara/lib/libdrm/intel/intel_bufmgr.c /usr/xenocara/lib/libdrm/intel/intel_bufmgr_fake.c /usr/xenocara/lib/libdrm/intel/intel_bufmgr_gem.c /usr/xenocara/lib/libdrm/intel/mm.c
cd /usr/xenocara/lib/libdrm && exec make  all
cc -O2 -pipe     -I/usr/xenocara/lib/libdrm  -I/usr/X11R6/include  -I/usr/include/dev/pci/drm  -DX_PRIVSEP -c /usr/xenocara/lib/libdrm/xf86drm.c -o xf86drm.o
cc -O2 -pipe     -I/usr/xenocara/lib/libdrm  -I/usr/X11R6/include  -I/usr/include/dev/pci/drm  -DX_PRIVSEP -c /usr/xenocara/lib/libdrm/xf86drmHash.c -o xf86drmHash.o
cc -O2 -pipe     -I/usr/xenocara/lib/libdrm  -I/usr/X11R6/include  -I/usr/include/dev/pci/drm  -DX_PRIVSEP -c /usr/xenocara/lib/libdrm/xf86drmMode.c -o xf86drmMode.o
cc -O2 -pipe     -I/usr/xenocara/lib/libdrm  -I/usr/X11R6/include  -I/usr/include/dev/pci/drm  -DX_PRIVSEP -c /usr/xenocara/lib/libdrm/xf86drmRandom.c -o xf86drmRandom.o
cc -O2 -pipe     -I/usr/xenocara/lib/libdrm  -I/usr/X11R6/include  -I/usr/include/dev/pci/drm  -DX_PRIVSEP -c /usr/xenocara/lib/libdrm/xf86drmSL.c -o xf86drmSL.o
building standard drm library
ranlib libdrm.a
cc -O2 -pipe     -I/usr/xenocara/lib/libdrm  -I/usr/X11R6/include  -I/usr/include/dev/pci/drm  -DX_PRIVSEP -c -fpic -DPIC /usr/xenocara/lib/libdrm/xf86drm.c -o xf86drm.so
cc -O2 -pipe     -I/usr/xenocara/lib/libdrm  -I/usr/X11R6/include  -I/usr/include/dev/pci/drm  -DX_PRIVSEP -c -fpic -DPIC /usr/xenocara/lib/libdrm/xf86drmHash.c -o xf86drmHash.so
cc -O2 -pipe     -I/usr/xenocara/lib/libdrm  -I/usr/X11R6/include  -I/usr/include/dev/pci/drm  -DX_PRIVSEP -c -fpic -DPIC /usr/xenocara/lib/libdrm/xf86drmMode.c -o xf86drmMode.so
cc -O2 -pipe     -I/usr/xenocara/lib/libdrm  -I/usr/X11R6/include  -I/usr/include/dev/pci/drm  -DX_PRIVSEP -c -fpic -DPIC /usr/xenocara/lib/libdrm/xf86drmRandom.c -o xf86drmRandom.so
cc -O2 -pipe     -I/usr/xenocara/lib/libdrm  -I/usr/X11R6/include  -I/usr/include/dev/pci/drm  -DX_PRIVSEP -c -fpic -DPIC /usr/xenocara/lib/libdrm/xf86drmSL.c -o xf86drmSL.so
building shared object drm library
ranlib libdrm_pic.a
building shared drm library (version 2.4)
cc -shared -fpic  -o libdrm.so.2.4  `lorder xf86drm.so xf86drmHash.so xf86drmMode.so xf86drmRandom.so xf86drmSL.so|tsort -q` 
===> lib/libdrm/intel
cc -O2 -pipe -g    -I/usr/xenocara/lib/libdrm/intel			 -I/usr/xenocara/lib/libdrm/intel/.. -I/usr/X11R6/include		 -I/usr/include/dev/pci/drm -c /usr/xenocara/lib/libdrm/intel/intel_bufmgr.c -o intel_bufmgr.o
cc -O2 -pipe -g    -I/usr/xenocara/lib/libdrm/intel			 -I/usr/xenocara/lib/libdrm/intel/.. -I/usr/X11R6/include		 -I/usr/include/dev/pci/drm -c /usr/xenocara/lib/libdrm/intel/intel_bufmgr_fake.c -o intel_bufmgr_fake.o
cc -O2 -pipe -g    -I/usr/xenocara/lib/libdrm/intel			 -I/usr/xenocara/lib/libdrm/intel/.. -I/usr/X11R6/include		 -I/usr/include/dev/pci/drm -c /usr/xenocara/lib/libdrm/intel/intel_bufmgr_gem.c -o intel_bufmgr_gem.o
/usr/xenocara/lib/libdrm/intel/intel_bufmgr_gem.c: In function `drm_intel_bufmgr_gem_init':
/usr/xenocara/lib/libdrm/intel/intel_bufmgr_gem.c:1288: error: `I915_PARAM_NUM_FENCES_AVAIL' undeclared (first use in this function)
/usr/xenocara/lib/libdrm/intel/intel_bufmgr_gem.c:1288: error: (Each undeclared identifier is reported only once
/usr/xenocara/lib/libdrm/intel/intel_bufmgr_gem.c:1288: error: for each function it appears in.)
*** Error code 1

Stop in /usr/xenocara/lib/libdrm/intel (line 92 of /usr/share/mk/sys.mk).
*** Error code 1

Stop in /usr/xenocara/lib/libdrm (line 48 of /usr/share/mk/bsd.subdir.mk).
*** Error code 1

Stop in /usr/xenocara/lib/libdrm (line 203 of /usr/X11R6/share/mk/bsd.xorg.mk).
*** Error code 1

Stop in /usr/xenocara/lib (line 48 of /usr/share/mk/bsd.subdir.mk).
*** Error code 1

Stop in /usr/xenocara (line 48 of /usr/share/mk/bsd.subdir.mk).
# 

I'm on an AMD Processor Box...Is that causing the build to fail?

I've read in other threads about Binary Upgrades and snapshot fetches; but Xenocara looks like it needs to be built from scratch.

I've obviously overlooked and "read too much into" the FAQ/Manuals. May I have some clarification on this witha few <SPOONFED> instructions if needed for the following questions:

a) Would the Upgrade Option from the install CD allow me to follow -current (kernel, src, ports) AND create the Xenocara "Port Directory"?

b) Should I have (re)built the system in the sequence listed in 5.3.2; and was my Xenocara build-error based on not having my kernel rebuilt after fetching the -current src/port directories?

c) May I have the "step by step" terminal instructions on the binary snapshot upgrade procedures that doesn't involve the install CD; and would that create the Xenocara Ports Directory?

Thanks.

[ocicat]

Originally Posted by IronForge

I decided to try out the 4.5 -current and reinstalled from scratch.

You have not given a reason why you want to run -current. Be aware that -current is pre-release software & is not vetted in the same manner as -release.

Likewise, at this point there is no 4.5-current because the OPENBSD_4_6_BASE CVS tag was created nearly a month ago. The head of the CVS tree is now 4.6-current.

I was able to checkout/update (since I just reinstalled release) src and ports; but since Xenocara wasn't built, I had errors from cvs.

If you are at -release, & your goal is to end up with -current:

• Follow the table given in Section 5.3.2 of the FAQ.
• Either upgrade to a -current snapshot, or download the head of CVS as described, and follow the Following -current document:
  
  http://openbsd.org/faq/current.html

If you had just recently had reinstalled 4.5-release. It would have been simpler to just install a 4.6-current snapshot.

I presumed that it may be prudent to try to "build" Xenocara before I tried to rebuild the Kernel and Userland per 5.3.1:

As if other errors had not already been made, this was a major mistake. Always build the kernel first.

I'm on an AMD Processor Box...Is that causing the build to fail?

No.

Would the Upgrade Option from the install CD allow me to follow -current (kernel, src, ports) AND create the Xenocara "Port Directory"?

Basically, yes as this is described in the 5.3.2 table already mentioned. Again as a teminology nit, you are describing the Xenocara CVS branch, not "Port Directory". Given that the prominence of the third-party ports tree, you only confuse people using this description.

Should I have (re)built the system in the sequence listed in 5.3.2; and was my Xenocara build-error based on not having my kernel rebuilt after fetching the -current src/port directories?

Yes.

May I have the "step by step" terminal instructions on the binary snapshot upgrade procedures that doesn't involve the install CD; and would that create the Xenocara Ports Directory?

My suggestion to you is:

• simply install the most current snapshot.
• download the source CVS branch & Xenocara branch as described in Sections 5.3.3 & 5.5. You trouble before was in not specifying the appropriate CVS tag. When playing in the -current world, don't specify any CVS tag.

Again, running -current is running on the cutting edge. We do not recommend casual usage unless there is a specific need which is being addressed.

[ocicat]

As an afterthought, given the trouble you have had in following the FAQ, you should also seriously study the release(8) manpage. This is the final authority when it comes to information on building the system.

[jggimi]

To remove an existing CVS Tag in your working directory structure -- making the tree -current -- use the "-A" opton of cvs(1) update or cvs checkout.

To reiterate what ocicat stated -- because it is so very, very important -- when either upgrading to -current for the first time, or installing -current for the first time, always begin with the latest snapshot. This is stated in the FAQ, but it bears stating again. And again. The reason is that the build process does not take into account either OS architectural or OS infrastructure changes. Once at -current, the user must always review the Following -current FAQ in order to take these changes into consideration. In the event of so-called "Flag Days", which typically happen once or twice per year, a standard build or release process will fail without manual intervention -- typically, these are gcc(1) or other build tool changes that must already be compiled and installed (sometimes called "bootstrapped") before the standard build process is executed. Often, the recommendation in the Following -current FAQ is to await the next snapshot rather than execute the complicated Flag Day procedure.

Some people who run -current do not build the system at all. They "upgrade" from snapshot to snapshot. But they must still review the Following -current FAQ in case there are manual infrastructure changes to be made.

[IronForge]

Thank you, gents:

I was looking too much into the faq - the sample that included the "checkout" of all directories threw me off that round. Beginner's goof.

Regards