@ Q1: Whether a service is logged or not is defined by the service file?
can you ask me the question differently because i don't understand what you mean, sorry

@ Q2: By default tty# is not logged, right?
yes, by default you don't have any service. the admin of the distro should provide the necessary service to boot a machine and the packager should provide service for a daemon, this is called portability :). You have an hammer, you do what you want with it

@ atomic.
Generic term to define longrun or oneshot service, refer to s6 documentation https://skarnet.org/software/s6-rc/overview.html :
"Oneshots and longruns are called atomic services. By opposition to atomic services, s6-rc also handles an additional kind of service that it calls a bundle. A bundle is just a collection of atomic services, described under a single name"
On service tty@ options ( env ) --> ( log env )
why not, and if set where is the log ?
Or is this on a cumulative log for 66 services and tty is added, but really unnecessary?

66.conf.pacnew
The usual entries have a ! in front of them. Why?
if you don't set the log options, 66 do not attach any logger. For tty a don't really see the interest but you can do it if you want. For example make a copy of your /etc/66/service/tty@ to the /etc/66/sysadmin/service directory. when you enable a service the sysadmin directory as precedence over /etc/66/service (yes you can define your own service with the same name without risking a change when the packager change the main service :), see 66-enable doc for more information here : http://web.obarun.org/software/ ). Now change your frontend service file as you want (in this case @ options=(env log) and re enable it by the -f option: 66-enable -f tty@ tty1.
the 66-info give you a lot of information about a service including the log place, note you can directly see the n last log line of associated logger by 66-info -S -p20 tty1, refer to 66-info doc for further information

the '!' character mean , do not keep this variable in the hidden environment. if the '!' character is not present the variable is set in the hidden environment. see 66-envfile documentation for more information
I have a couple of small installations with s6-conf I can convert to 66 if you are getting close to the final stage.
Let me know when it would be a good time to try them.
Oooh man I feel like a kid before christmas, I can't wait any longer! Go publish! :D :D
(Although I'm not a kid anymore, so please don't publish if you don't feel like it's ready yet :) )
eric wrotethe '!' character mean , do not keep this variable in the hidden environment. if the '!' character is not present the variable is set in the hidden environment. see 66-envfile documentation for more information
The word hidden doesn't exist in: http://web.obarun.org/software/66-envfile.html but I think in theory I get why this is, I think. It is like setting keys within a sub-environment that are not permanent, and their effect goes away unless they run again? So is hidden and not hidden as permanent or temporary?

Practically, on 66.conf, do we live those ! marks on, or do we delete them? Is # and ! alternatives but variables with ! have to be set while with # can be left not set?
4 days later
sorry for my last answer

open a terminal and : 
# printenv
this is the "hidden" environment. If you want to know the environment of a process 
# cat /proc/<pid of process>/environ
so when you use the '!' character the variable is used in the executed script but not set in the environment, you will not see the variable in your cat /proc/<pid of process>/environ.

on 66.conf
a '# ' is used as usual way to comment a line,so the script skip the line.
a '!' is used to unexport the variable from the environment after the use in a script.
6 days later
Eric, no pressure here but WHEN'S THE FIRST OFFICIAL ISO?! Hahaha. Greetings from Mexico and have a nice week :D
Currently testing the stuff deeply to be sure that's ready for production, but yeah it comes very soon
leave your hat on :D
What's there to test any more, it is like a speeding bullet.
I suppose you only need to make some service files yet.
well, it's a little bit complicated, what about the installer? or pacopts? :).
Anyway the testing phase is now finished...
I tried this once, I edited the pacman.conf and pkg lists on the installer and made one installation with 66, it seemed fine. It booted first try. But I think the pacman.conf installed had to be re-edited to 66.
I think that was 2 weeks ago. One thing that I can't visualize yet, after all the changes, whether there would be adequate scripts to adopt everything to 66 by simply updating when 66 comes to [obarun]. Is there a way to copy modified variables/entries from s6.conf to 66.conf, then delete all the s6serv stuff? I suspect it would have to be all in one hit.
ok this last announcement on this thread, stable release of 66 is here(v0.0.2.2)

Manual intervention (the last one) is necessary on existing system, follow this

- first remove any backup but do not remove the backup directory itself 
# rm -rf /var/lib/66/system/backup/*
- remove all existing tree 
# rm -rf /var/lib/66/system/boot
# rm -rf /var/lib/66/system/root
# rm -rf /var/lib/66/system/<tree_name>
...
- do the same if any tree exist with your normal user at $HOME/.66/system and backup too $HOME/.66/system/backup
DO NOT use 66-tree to remove your tree, you will goes on trouble, do it manually as described
- now create and build again your tree 
# 66-tree -n boot
# 66-enable -t boot boot
# 66-tree -cnE root
# 66-enable tty@ tty1 tty@ tty2 dbus connmand ntpd
Obviously adapt the command enable command line to suit your needs
do the same for your user tree if you needs.
check if all is ok 
# 66-info -T
you're done , reboot.
Ok with conversion
I am trying out the installer
I am going to use last iso and update the installer only
Using my own scripts over the installer messes it up, it updates scripts and picks up older scripts from the git
I think the installer would work once it has repositories to match, it is in a very confused and confusing state.

  • [deleted]

  • Post #96
That right fungalnet. Be patient, it's coming soon at this time on testing branch, eric and me are working very hard to offer you the best.
Ok, thanks, it helped notice the work done on obarun-testing.
I have applied all updates to 66 on my void installation. I have renamed it from FrankenVoid66 to Fukoshima66
It takes a 9R earthquake to bring down this system :)
% xbps-query -Rs yajl                  
[*] yajl-2.1.0_4       Yet Another JSON Library
[-] yajl-devel-2.1.0_4 Yet Another JSON Library - development files
% xbps-query -Rs libcap
[*] libcap-2.26_1             POSIX.1e capabilities suite
% pacman -Qs | grep "base s6-suite"
local/66 0.0.2.2-4 (base s6-suite)
local/boot-66serv 0.0.1.4-1 (base s6-suite)
local/execline 2.5.1.0-1 (base s6-suite)
local/oblibs 0.0.1.1-1 (base s6-suite)
local/s6 2.8.0.0-1 (base s6-suite)
local/s6-linux-utils 2.5.0.1-1 (base s6-suite)
local/s6-rc 0.5.0.0-1 (base s6-suite)
local/skalibs 2.8.0.0-1 (base s6-suite)
Everything that can come from void comes from void. I have used as little as possible from obarun/arch other than its s6/66 and pacman. Getting 66 to void-musl would be the next challenge.

Powered by Obarun