re: Incompatibilities between runit and s6?

re: Incompatibilities between runit and s6?

[Avery Payne]

[-- Attachment #1: Type: text/plain, Size: 372 bytes --]

I am guessing the differences will be subtle, and most of the general
behavior you desire will remain the same.  You may be able to get a way
with a "sed 's/sv\ /s6-sv\ /' <old-script-name >new-script-name" on some of
your scripts; give it a try, what could it hurt?

Also, for those systems not running CentOS, what are you currently using
for init + service management?

re: Incompatibilities between runit and s6?

[Charlie Brady]

On Wed, 10 Jan 2018, Avery Payne wrote:

> I am guessing the differences will be subtle, and most of the general
> behavior you desire will remain the same.  You may be able to get a way
> with a "sed 's/sv\ /s6-sv\ /' <old-script-name >new-script-name" on some of
> your scripts; give it a try, what could it hurt?

That would fail because, eg, 'sv t xxx' needs to become 's6-svc -t xxx'.  

> Also, for those systems not running CentOS, what are you currently using
> for init + service management?

That's actually a null set, except for some old embedded systems running 
busybox init+runit.

Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Charlie Brady]

On Thu, 11 Jan 2018, Charlie Brady wrote:

> On Wed, 10 Jan 2018, Avery Payne wrote:
> 
> > I am guessing the differences will be subtle, and most of the general
> > behavior you desire will remain the same.  You may be able to get a way
> > with a "sed 's/sv\ /s6-sv\ /' <old-script-name >new-script-name" on some of
> > your scripts; give it a try, what could it hurt?
> 
> That would fail because, eg, 'sv t xxx' needs to become 's6-svc -t xxx'.  

I've started thinking that I wouldn't need to abandon use of 'sv'. With 
both runit and s6 installed, and a supervision tree of s6-svscan and 
s6-supervise processes, I suspect that 'sv t ...' would still work. 'sv 
status ...' on the other hand might not. I would need to study the control 
fifo protocol and status file layout to be sure.

Again, has anyone else considered these things and can offer an opinion? 
Are the differences documented anywhere? There is a certain level of 
compatibility between daemontools and runit, and I presume the same exists 
for s6. The devil is in the detils.

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Laurent Bercot]

>I've started thinking that I wouldn't need to abandon use of 'sv'. With
>both runit and s6 installed, and a supervision tree of s6-svscan and
>s6-supervise processes, I suspect that 'sv t ...' would still work. 'sv
>status ...' on the other hand might not. I would need to study the 
>control
>fifo protocol and status file layout to be sure.

  sv status will not work, because the status file has a different
format in s6 and in runit.
  sv t and others? It may work; it may not. If you try this, it's on
you: the interface between s6-svc and s6-supervise is not public and
is not guaranteed stable. Generally speaking, using the tools of one
supervision suite on another one isn't something I think is worth
spending effort on.

--
  Laurent

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Jonathan de Boyne Pollard]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

Charlie Brady:

> There is a certain level of compatibility between daemontools and 
> runit, and I presume the same exists for s6. The devil is in the detils.
>
The |service-manager| manual page from version 1.37 or later of the nosh 
toolset contains  a full breakdown of the control/status API in a 
|supervise/| directory, including the daemontools-encore extensions and 
the nosh service-manager's own extensions.  I am hoping to get version 
1.37 released within the next week.  In the meantime, I have pushed the 
new manual page to the on-line copy of the /nosh Guide/ 
<http://jdebp.info./Softwares/nosh/>.  You can find the HTML-form manual 
page for |service-manager| hyperlinked from several pages in the 
/Guide/, including the _new Interfaces_ page.

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Charlie Brady]

Thanks Jonathan.

Do you know whether anyone has documented how to build on a non-Debian 
linux? An rpm spec file would be ideal, but just simple non-Debian centric 
build instructions would be better than nothing.

On Sun, 14 Jan 2018, Jonathan de Boyne Pollard wrote:

> Charlie Brady:
> 
> > There is a certain level of compatibility between daemontools and runit, and
> > I presume the same exists for s6. The devil is in the detils.
> >
> The |service-manager| manual page from version 1.37 or later of the nosh
> toolset contains  a full breakdown of the control/status API in a 
> |supervise/| directory, including the daemontools-encore extensions and 
> the nosh service-manager's own extensions.  I am hoping to get version 1.37
> released within the next week.  In the meantime, I have pushed the new manual
> page to the on-line copy of the /nosh Guide/
> <http://jdebp.info./Softwares/nosh/>.  You can find the HTML-form manual page
> for |service-manager| hyperlinked from several pages in the /Guide/, including
> the _new Interfaces_ page.
> 
> 

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Jonathan de Boyne Pollard]

[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]

Jonathan de Boyne Pollard:

> The |service-manager| manual page from version 1.37 or later of the 
> nosh toolset contains  a full breakdown of the control/status API in a 
> |supervise/| directory, including the daemontools-encore extensions 
> and the nosh service-manager's own extensions.  I am hoping to get 
> version 1.37 released within the next week.  In the meantime, I have 
> pushed the new manual page to the on-line copy of the /nosh Guide/ 
> <http://jdebp.info./Softwares/nosh/>.  You can find the HTML-form 
> manual page for |service-manager| hyperlinked from several pages in 
> the /Guide/, including the _new Interfaces_ page.
>
Charlie Brady:

> Do you know whether anyone has documented how to build on a non-Debian 
> linux? An rpm spec file would be ideal, but just simple non-Debian 
> centric build instructions would be better than nothing.
>
Yes.  I have.  The slashpackage-style build instructions, which are of 
course /not/ Debian-specific nor even /Linux-/specific, are actually 
right there on the source package WWW page.

The only thing that is Debian-specific is the step that gets one from a 
/built/ slashpackage-style package to Debian binary packages.  This is 
in the supplied |package/debian/rules| command.  But even that is not 
actually Debian-specific, as there is a similar |package/bsd/rules| 
command that does the same thing on the BSDs.

Thomas Caravia constructed the Archnosh PKGBUILD the same way. It does 
the slashpackage-style build, then takes the built slashpackage-style 
package and parcels it out into a set of Arch binary packages, with a 
light dusting of patches to a handful of service bundles.  It even 
mostly re-uses the Debian maintenance scripts.

(On that note, Thomas: You may enjoy the start that I have made in 1.37 
to a _Packages and Ports_ chapter in the /nosh Guide/.  Yes, I currenly 
plan for the |.p|/|.func| system to get at least a short mention.)

I was only expecting you to read the manual for doco on the common 
control/status API that you were interested in, not build the software.  (-:

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Thomas Caravia]

Hello,

> > Do you know whether anyone has documented how to build on a non-Debian 
> > linux? An rpm spec file would be ideal, but just simple non-Debian 
> > centric build instructions would be better than nothing.
> 
> Thomas Caravia constructed the Archnosh PKGBUILD the same way. It does 
> the slashpackage-style build, then takes the built slashpackage-style 
> package and parcels it out into a set of Arch binary packages, with a 
> light dusting of patches to a handful of service bundles.  It even 
> mostly re-uses the Debian maintenance scripts.

I'm not familiar with rpm but my packaging is just this:

1) package/compile: you'll need "redo" to build

2) package/stage: you can tweak this script to fit your distribution's
filesystem hierarchy

3) use the resulting package trees for your packaging: in my case
one-for-one copying

4) include install/upgrade/remove scripts from package/debian for the
packages that need them

Service bundle patches account for differences in paths or usernames
with Archlinux, when I find them.

> (On that note, Thomas: You may enjoy the start that I have made in 1.37 
> to a _Packages and Ports_ chapter in the /nosh Guide/.  Yes, I currenly 
> plan for the |.p|/|.func| system to get at least a short mention.)

It did not go unnoticed!

Regards,
Thomas

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Laurent Bercot]

  Note that s6 has been using a configure/make/sudo make install
building scheme since 2014, and supports FHS as well as slashpackage,
so it can be easily packaged for any distribution. :P

--
  Laurent

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Charlie Brady]

On Mon, 15 Jan 2018, Thomas Caravia wrote:

> I'm not familiar with rpm but my packaging is just this:
> 
> 1) package/compile: you'll need "redo" to build

Sorry, doesn't work for me:

bash-4.2$ package/compile 
redo: ERROR: all: Cannot find .do file to use.
bash-4.2$ sh -ex package/compile
+ '[' '!' -d package ']'
+ '[' '!' -d source ']'
+ ./package/prepare
+ ./package/make
redo: ERROR: all: Cannot find .do file to use.
bash-4.2$ 

The redo build works, but isn't perfect either:

bash-4.2$ package/compile
./package/tools: line 17: type: clang++: not found
redo.cpp: In function void read_db_line(std::istream&, Information&, 
std::string&):
redo.cpp:394:14: warning: unused variable c [-Wunused-variable]
  switch (int c = s.get()) {
              ^
popt.cpp: In member function virtual void popt::table_definition::help():
popt.cpp:147:13: warning: unused variable short_name [-Wunused-variable]
    if (char short_name = n->query_short_name()) l += 2;
             ^
popt.cpp:149:14: warning: unused variable short_name [-Wunused-variable]
     if (char short_name = n->query_short_name()) l += 1;
              ^
popt.cpp:162:14: warning: unused variable short_name [-Wunused-variable]
     if (char short_name = n->query_short_name()) t += "|";
              ^
bash-4.2$ 

Build platform is Fedora linux.

nosh build problems (Re: Compatibilities between runit and s6 (re: )

[Charlie Brady]

On Mon, 15 Jan 2018, Charlie Brady wrote:

> > 1) package/compile: you'll need "redo" to build
> 
> Sorry, doesn't work for me:
> 
> bash-4.2$ package/compile 
> redo: ERROR: all: Cannot find .do file to use.
> bash-4.2$ sh -ex package/compile
> + '[' '!' -d package ']'
> + '[' '!' -d source ']'
> + ./package/prepare
> + ./package/make
> redo: ERROR: all: Cannot find .do file to use.
> bash-4.2$ 

Here's some more detail on the build failure:

bash-4.2$ sh -ex package/make
+ test '!' -d package
+ test '!' -d source
+ test '!' -d build
+ expr '' : --jobs
+ expr '' : --jobs
+ case "`uname`" in
++ uname
++ fgrep -c processor /proc/cpuinfo
+ cpus=2
+ exec redo --directory build --jobs 2 -- all
redo: ERROR: all: Cannot find .do file to use.
bash-4.2$ ls build/
bash-4.2$

Re: nosh build problems (Re: Compatibilities between runit and s6 (re: )

[Charlie Brady]

OK, with pax installed, but gets a lot further.

Now seeing these many times:

/usr/include/curses.h:843:31: error:   initializing argument 1 of 'char* 
tigetstr(char*)' [-fpermissive]

service-status.cpp:148:21: error: invalid conversion from 'const char*' to 
'char*' [-fpermissive]
   s = tigetstr(setaf);

and this:

service-status.cpp:276:111: warning: enumeral and non-enumeral type in 
conditional expression [enabled by default]
   const char state(b >= ENCORE_STATUS_BLOCK_SIZE ? 
status[ENCORE_STATUS_OFFSET] : p ? encore_status_running : 
encore_status_stopped);

 This is on CentOS7 build platform.

Re: nosh build problems (Re: Compatibilities between runit and s6 (re: )

[Jonathan de Boyne Pollard]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

Charlie Brady:

> /usr/include/curses.h:843:31: error:   initializing argument 1 of 'char*
> tigetstr(char*)' [-fpermissive]
>
> service-status.cpp:148:21: error: invalid conversion from 'const char*' to
> 'char*' [-fpermissive]
>     s = tigetstr(setaf);

This is a problem that I thought was confined to OpenBSD, and its 
not-|const|-correct ncurses library.  Certainly this has never been a 
problem on Debian nor on FreeBSD, and M. Caravia did not report any lack 
of |const|-correctness on Arch Linux.  What does line 843 of your 
|/usr/include/curses.h| actually say?  Because that's not the location 
of that function declaration in that header in either Dickey ncurses or 
Acton pdcurses as far as I can see.  So what curses are you actually using?

Re: nosh build problems (Re: Compatibilities between runit and s6 (re: )

[Guillermo]

2018-01-16 17:51 GMT-03:00 Jonathan de Boyne Pollard:
>
> Charlie Brady:
>
>> /usr/include/curses.h:843:31: error:   initializing argument 1 of 'char*
>> tigetstr(char*)' [-fpermissive]
>>
>> service-status.cpp:148:21: error: invalid conversion from 'const char*' to
>> 'char*' [-fpermissive]
>>     s = tigetstr(setaf);
>
> This is a problem that I thought was confined to OpenBSD, and its
> not-|const|-correct ncurses library.  Certainly this has never been a
> problem on Debian nor on FreeBSD, and M. Caravia did not report any lack of
> |const|-correctness on Arch Linux.

Neither has been a problem on Gentoo. However...

>  What does line 843 of your
> |/usr/include/curses.h| actually say?  Because that's not the location of
> that function declaration in that header in either Dickey ncurses or Acton
> pdcurses as far as I can see.  So what curses are you actually using?

Dickey ncurses' 'configure' script has options --enable-const and
--disable-const. When ncurses is built with --disable-const,
tigetstr()'s parameter has type char *, when built with
--enable-const, it has type const char *. When neither is specified,
default is --disable-const for ncurses 5, and --enable-const for
ncurses 6.

On my computer:

$ grep -E '(define NCURSES_CONST|tigetstr)' /usr/include/curses.h
#define NCURSES_CONST const
extern NCURSES_EXPORT(char *) tigetstr (NCURSES_CONST char *);  /*
implemented */

I can't check what is the case for CentOS, asuming it ships Dickey
ncurses, but I could bet...

G.

Re: nosh build problems (Re: Compatibilities between runit and s6 (re: )

[Jonathan de Boyne Pollard]

[-- Attachment #1: Type: text/plain, Size: 920 bytes --]

Guillermo:

> Jonathan de Boyne Pollard:
>
>> What does line 843 of your |/usr/include/curses.h| actually say? 
>> Because that's not the location of that function declaration in that 
>> header in either Dickey ncurses or Acton pdcurses as far as I can 
>> see. So what curses are you actually using?
>>
> Dickey ncurses' |configure| script has options |--enable-const| and 
> |--disable-const|. [...]
>
I am aware.  It doesn't shift that declaration onto line 843 of that 
header. It was quite a few lines further down a few years ago 
<https://github.com/ThomasDickey/ncurses-snapshots/blame/5246b41942b2734b012b118903ca869b1a1fae2f/include/curses.h.in#L854>, 
and is even further down nowadays.  So either this is a significantly 
older Dickey ncurses, older even than what is in Debian 8 
<https://anonscm.debian.org/cgit/collab-maint/ncurses.git/tree/include/curses.h.in?h=jessie#n854>, 
or it is something else.

Re: nosh build problems (Re: Compatibilities between runit and s6 (re: )

[Charlie Brady]

On Tue, 16 Jan 2018, Jonathan de Boyne Pollard wrote:

> This is a problem that I thought was confined to OpenBSD, and its
> not-|const|-correct ncurses library.  Certainly this has never been a problem
> on Debian nor on FreeBSD, and M. Caravia did not report any lack of
> |const|-correctness on Arch Linux.  What does line 843 of your 
> |/usr/include/curses.h| actually say?  Because that's not the location 
> of that function declaration in that header in either Dickey ncurses or Acton
> pdcurses as far as I can see.  So what curses are you actually using?

CentOS 7 is not an obscure distribution.

bash-4.2$ sed -n 843p /usr/include/curses.h
extern NCURSES_EXPORT(char *) tigetstr (NCURSES_CONST char *);          /* 
implemented */
bash-4.2$ rpm -qf /usr/include/curses.h
ncurses-devel-5.9-14.20130511.el7_4.x86_64
bash-4.2$ 

Re: nosh build problems (Re: Compatibilities between runit and s6 (re: )

[Guillermo]

2018-01-17 12:25 GMT-03:00 Charlie Brady:
>
> bash-4.2$ sed -n 843p /usr/include/curses.h
> extern NCURSES_EXPORT(char *) tigetstr (NCURSES_CONST char *);          /*
> implemented */
> bash-4.2$ rpm -qf /usr/include/curses.h
> ncurses-devel-5.9-14.20130511.el7_4.x86_64

And

$ grep 'define NCURSES_CONST' /usr/include/curses.h

probably says:

#define NCURSES_CONST /*nothing*/

Correct?

G.

Re: nosh build problems (Re: Compatibilities between runit and s6

[Charlie Brady]

On Thu, 18 Jan 2018, Guillermo wrote:

> And
> 
> $ grep 'define NCURSES_CONST' /usr/include/curses.h
> 
> probably says:
> 
> #define NCURSES_CONST /*nothing*/
> 
> Correct?

Correct.

bash-4.2$ grep 'define NCURSES_CONST' /usr/include/curses.h
#define NCURSES_CONST /*nothing*/
bash-4.2$ 

Re: nosh build problems (Re: Compatibilities between runit and s6 (re: )

[Guillermo]

2018-01-16 13:09 GMT-03:00 Charlie Brady:
>
> Now seeing these many times:
>
> /usr/include/curses.h:843:31: error:   initializing argument 1 of 'char*
> tigetstr(char*)' [-fpermissive]
>
> service-status.cpp:148:21: error: invalid conversion from 'const char*' to
> 'char*' [-fpermissive]
>    s = tigetstr(setaf);
> [...]
>  This is on CentOS7 build platform.

This should be fixed in nosh 1.37. So, unless there were other
compiler errors (warnings are nonfatal), nosh binaries should now
build on CentOS too.

G.

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Jonathan de Boyne Pollard]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

Charlie Brady:

> Sorry, doesn't work for me:
>
You need a POSIX-conformant system with all of the POSIX utilities, 
including |pax| 
<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html>.  
The Debian |package/debian/control| file automatically ensures this on 
Debian, with its |Build-Depends:| information.  The BSDs have these 
tools /as standard/ in the base operating system, out of the box.  
Thomas Caravia both notes this in the Archnosh doco (in the section 
headed "Dependencies") and declares it as a |makedepends| in the 
|PKGBUILD| itself so that it is automatically ensured on Arch.  You are 
going to have to do this yourself on your operating system, too.

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Charlie Brady]

On Tue, 16 Jan 2018, Jonathan de Boyne Pollard wrote:

> Charlie Brady:
> 
> > Sorry, doesn't work for me:
> >
> You need a POSIX-conformant system with all of the POSIX utilities, including
> |pax| <http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html>.

OK, so this statement is incomplete:

"It requires redo to build, and builds with the g++ and clang++ 
compilers".

Perhaps you should use "or" there, rather than "and". Both compilers 
aren't required, IIUC.

And the build doesn't fail gracefully. There is no indication that the 
build failed for lack of "pax".

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Jonathan de Boyne Pollard]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

Charlie Brady:

> OK, so this statement is incomplete:
>
It also does not tell you that you need other POSIX-standard commands 
such as |mv| and |ln|.   But you need them, too.  I draw the line at 
listing every command, that POSIX-conformant systems have had to have 
for two decades and that are also listed in the Linux Standard Base 
<https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Common/LSB-Common/rcommands.html>, 
that is required.  That would be ridiculous.  I also don't mention 
things that /operating system doco/ says are fundamental for building 
packages, like build-essential 
<https://www.debian.org/doc/manuals/maint-guide/start.en.html#needprogs> 
and base-devel 
<https://wiki.archlinux.org/index.php/Creating_Packages#Prerequisite_software>. 
Pointing out that you need |redo|, on the other hand, is pointing out 
something that is not POSIX, not in the LSB, and not in the operating 
system doco.  On those grounds, I should add that you need |xmlto|.

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Jonathan de Boyne Pollard]

Thomas Caravia:

> I'm not familiar with rpm but my packaging is just this:
>
You have prompted me to fill in a long-standing dangling hyperlink.

* http://jdebp.eu./FGA/slashpackage.html

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[multiplexd]

On Tue, Jan 16, 2018 at 08:06:09AM +0000, Jonathan de Boyne Pollard wrote:
> You have prompted me to fill in a long-standing dangling hyperlink.
> 
> * http://jdebp.eu./FGA/slashpackage.html
> 

Ah, good to hear! I've been waiting for that page to be written for a 
while :).

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Laurent Bercot]

>You have prompted me to fill in a long-standing dangling hyperlink.
>
>* http://jdebp.eu./FGA/slashpackage.html

  If I may add my two cents: I think you're mixing two very different
things in this page.

  There is the slashpackage convention for installed packages, i.e.
visibility of executables in /package/category/name/command/name
and the like. I find it useful; and my software *still follows* that
convention, if compiled with --enable-slashpackage.

  And there is the internal structure for building packages, which is
package/compile, package/run, etc. I liked its simplicity at first,
but with experience, I found that it wasn't ideal.

  The primary issue is that it's inherently not cross-compile-friendly.
Having a pre-written compilation script makes it difficult to separate
gathering information about the target and actually building for the
target; whereas a configure/make system can frontload the data
gathering operation. (And in my case I frontload it all in the
skalibs package, so when the annoying part of finding correct sysdeps
for the target has been done once, all the rest of the software
cross-compiles effortlessly.)

  A secondary issue is that system administrators and distribution
packagers, i.e. the intended users of the build system, just could
not stop complaining about it, to the point that complaints about the
build system were for some time the majority of the mailing-list's
traffic. No matter whether their reasons were good or bad, if the
intended users of an interface don't like the interface, then it's
probably a good idea to change the interface. Since switching to
configure/make, the popularity of s6 has skyrocketed; I don't think
it's entirely accidental.

  So yes, the internal package/compile build system is something I
stepped away from. But IMO that's not at all the important part of
the "slashpackage convention", one does not imply the other; and
I wish you would emphasize that.

--
  Laurent