No no no!
This means you can have 66 trees as a user running user-level services like dbus-user or xdg-user-dirs
So if you run the above as user $
Remove this username tree
$ 66-tree -R username

tty1 tty2 are the consoles starting after boot so you can log in, if you are not using a DM

The user level services are a capability of 66 but not necessary.
As far as I know 66-enable -C tty@ tty1 tty2@ tty2 run by user will result to an error as tty can only be enabled by root.

In general if you see instructions that start with # it implies instructions run as root, and $ or % are instructions by user. Your prompt should change accordingly when you are using su or you have logged in as root.

Nhaok wrotehttps://web.obarun.org/index.php?id=111

1 First of all, I think this information with link to that article should be somewhere in announcements or update warnings subforums as pinned post with big RED LETTERS, I really got into that much by accident.
2 And one last question, if I have like basic minimal install, it says adapt for your case - what are some most common things I put there besides tty1 and dhcpcd, anything that I should care (think of minimal install use-case)?

1 There was an announcement https://forum.obarun.org/viewtopic.php?id=836
And you should have obnews pkg installed so when important announcements come out you will see them while upgrading. Ideally only conscious testers should have -testing repositories enabled, willing to contribute feedback to software that create major changes in the system.
In my opinion obnews should be included in the base-s6 group and be mandatory after each installation. New isos will come out as soon as 66-0.2 transfers to the stable repository.

If you read around I had problems in the transition as well with one installation but it was my fault having a mistake in fstab of trying to mount a partition uuid that didn't exist.

2 I use dhcpcd for networking, and most people use dbus, I don't use a dm. But let's say you use connmand and you also use sddm for a display manager and you also use consolekit. Your root should be something like this:
First you need all the appropriate service files for those services to be run by 66:
# pacman -S connmand-66serv sddm-66serv consolekit-66serv dbus-66serv

The necessary dependencies will come in with them.

# 66-enable -t root -C -S tty@ tty1 tty@ tty2 sddm connmand dbus consolekit

# 66-info -T root
will show you if in fact all those things are active and enabled in the root tree.
As soon as you type the above command though and enable sddm your screen will leave console and start sddm, where you have to log in and go to terminal to check on 66-info

To look through all the 66 services available;
# pacman -Sl observice (or observice-testing if you are on v.0-2)

Appart from fungalnet informations i will add some intructions to properly deal with user tree and DM and corrects a thing about sddm and consolekit relationship
The task can be tedious to have a dbus envrionment set correctly for a desktop machine, but by chance we have the necessary tools to accomplish this on automatic way.

Follow this:(as fungalnet said you every command beginning by # mean root execution, and $ mean normal user execution)

Assumptions:
- you are on v0.2.x.x 66 package version and testing repo are activated
- you have dbus-66serv and sddm-66serv packages installed on your system
- you have dbus, sddm, consolekit packages installed on your system
- you have dbus, sddm enabled on some root's tree. Now the precision about sddm and consolekit. When you use sddm service do not enable consolekit. Both can enter in conflict. Just let sddm starts consolekit when sddm need it.

1) first at all install boot-user-@ -66mod modules

# pacman -S boot-user-@ -66mod

2) create a new tree with a desire name (e.g boot-user). this is optionnal. The modules can be enabled on every tree. Otherwise it can be a good idea to separate things when you are not accustomed with 66.

# 66-tree -nE boot-user

3) configure the modules to deal with the correct user (e.g oblive)

# 66-mods.sh boot-user-@ oblive

4) enable the modules onto the boot-user tree

# 66-enable -t boot-user boot-user-oblive

Ok, now what do the modules. When you start the machine after the boot procedure the boot-user tree will be launched. This tree will start a scandir for the oblive user with good envrionment into it like the definition of DBUS_SESSION_BUS_ADDRESS XDG_RUNTIME_DIR and so on. Creation of the /run/user/<uid> directory, and so on. Some of those operation need to be made as root (like the run/user directory), that's why the modules is set with root user.
Note: if you have x user you can make the exact same procedure as above replacing oblive by the name of another user. In this case each user will have his own directory with correction permissions on it... yeah multi-session is possible with 66 and multi-seat too.

Anyway, we will now configure the user itself.
5) create a tree named e.g graphics

$ 66-tree -Ecn graphics

6) enable dbus into it and every service that you want but dbus is mandatory

$ 66-enable dbus-session-@ oblive xdg-user-dirs

you're are done.

A tree user tree (and every 66 command is general) react as exactly the same way as root user. So, you deal with service for user as you make it with root.

If you have any question, don't hesitate.

Note: if you want some precision about what do the modules :

$ 66-mods.sh -H boot-user-@

will display the help of the modules boot-user-@

Sddm consolekit was my example, he didn't say he is using such a thing. But I think it is good reference for anyone wanting to get a dm functional.

Since you converted to 66 v.0.2 you need to keep them active, at least till Aug 18th when the transition period expires and they all move to the stable repositories.
With tesing enabled you should be getting:

obcore-testing/dbus 1.12.16-3 [installed]
obcore/dbus 1.12.16-2 [installed: 1.12.16-3]
core/dbus 1.12.16-1 [installed: 1.12.16-3]

Note the 1,2,3 versions at the end of the pkg name.

With trees and services it is up to you and what you want to do, what desktop you use, if you are running any servers from your machine, etc. There may be occassions where temporarily you need a "bunch" of services run for specific use and you group them under one tree, you activate the tree and when you are done you put them back to sleep so they don't have to run at all times. For example I have one for printing that has cupsd and dbus in it. I don't use dbus for anything else and cups doesn't need to be active all the time.

Welcome to the club. The documentation for 66.v.0.2 for now only exists in the git (framagit https://web.obarun.org/index.php?id=52 the link "packages" in the top bar) and it is also as a manual entry. Previous editions didn't have a manual entry. $ man 66-all will give the documentation for command 66-all.

We will have the entire 66 documentation replacing the current one in the wiki in the next few days.

Most, nearly all, instructions for 66 and advise can be found in the thread
https://forum.obarun.org/viewtopic.php?id=666

Many options and software have been introduced/added but as far as I can tell everything that worked for v.0.1 still works on v.0.2 The position of files relating to 66 changed around the system so 66 can be used in various other systems than arch. Currently it works for void, debian/devuan, and a 3rd one I forget the name of.

The reason everyone else is not using s6/66 yet is because they don't know about it.

ntpd-66serv corrects your time to internet time servers.
sshd-66serv so you can access your system from other network connections
$ pacman -Sl observice
$ pacman -Sl observice-testing
or $ pacman -Ss 66serv

udo wroteand which services would you recommend to put in the root tree and which in the user tree. or does it matter?

Let's define some term.
If you talk about root tree that's mean that service running inside it are service with needs root permissions. For example you cannot launch command with user permissions, you need root privileges.
At opposite if you talk about user tree that's mean that the service can be running with normal user privileges. For example xdg-user-dirs can be run with normal user privileges.
Another example is tty, you cannot launch a tty service with normal user.

So, now you can make what you want , it's up to you. No advices, no policies decision will be made for you about your tree contains. Some user use one tree which contains all they needs, some other will separate things between multiple tree. Depending of your way, your needs and so on. For example i have one tree called "root" which contain tty1, tty2. An another called "common" containing dbus, connmand, ntpclient. An another called security containing sshd,... and so on. It's up to you to configure your system as you want :)

what did the above poster mean by graphics tree?

It was just an arbitrary name for the explanation. The name of a tree to not require specific name.

Are you using a desktop/wm? Which one?

Try creating a user tree (as user, not root)
$ sudo pacman -S xdg-user-dirs-66serv dbus-66serv
$ 66-tree -ncE usergfx (or whatever name you like)
$ 66-enable -t usergfx -S xdg-user-dirs dbus

restart, or exit user and login again.

PS I use openbox mostly and never have needed a user tree and as much as I can never use dbus.

i use openbox.. afaiui dbus is a dependency of xorg-server among other things.. my root tree has: dbus dhcpcd tty1 tty2
xdg-user-dirs-66serv just runs xdg-user-dirs-update which does not set XDG_RUNTIME_DIR env variable.. only the dirs as per ~/.config/user.dirs.dirs
ie.:

XDG_DESKTOP_DIR="$HOME/Desktop"
XDG_DOWNLOAD_DIR="$HOME/Downloads"
XDG_TEMPLATES_DIR="$HOME/Templates"
XDG_PUBLICSHARE_DIR="$HOME/Public"
XDG_DOCUMENTS_DIR="$HOME/Documents"
XDG_MUSIC_DIR="$HOME/Music"

i'm curious to know how it was set previous to the upgrade..
note, i'm using xorg-server, not xorg-server-rootless, if that's at all relevant..

ncmprhnsbl wroteis this a good way of doing it? or am i missing something? how was this set before?

yes should be good. Also you can set it at .xinitrc be this will make no difference.

i assume that there's no way to remove a service from a tree.

no sure to understand what you mean here. You can disable any service from any tree without the need to destroy your tree, simply do : 66-disable -t <tree> <service>. At this state the service will not be available at the next boot.
if you want to unsupervise the service immediately after the disable command do: 66-stop -u <service> and the service is stopped and completely removed from the scandir.

about dbus, auto-launch, user-session and X flags was disabled at the compilation time. Dbus do not start by itself now and this is the expected behaviour. We want to keep the control of it in any occasion. A daemon should not start by itself without any request from the admin and this is avoid conflict between API like consolekit sddm etc etc. Obviously that's mean that you need to start it in the right way and at the good time with good variable.
So yes if you don't use boot-user-@ modules you need to set XDG_XXX_XXX var by yourself on your xinitrc for example