Re: has anyone gotten nosh to build on Void Linux?

[Guillermo]

2018-07-01 8:38 GMT-03:00 Jonathan de Boyne Pollard:
>
> For the sake of other readers: note that it is not the build system that
> employs the wall program.  (That would be bizarre.)  It is the shutdown
> program, at runtime, as described in its manual.

Yep, that is a runtime dependency rather that a buid-time dependency,
but worth mentioning, because util-linux's build system doesn't build
wall if the 'configure' script is passed a --disable-wall option, and,
for example, Gentoo does not have that program unless explicitly
requested by the administrator with the 'tty-helpers' USE flag.

G.

Re: has anyone gotten nosh to build on Void Linux?

[Guillermo]

2018-06-30 21:27 GMT-03:00 Chris Brannon:
>
> Sorry, I didn't have time to reply, but I made a good deal of progress
> earlier today, after writing to the list.

Great!

> I also needed to fine libtinfo, because
> Void doesn't have it.  Void could probably have libtinfo provided by
> their curses package with a fairly straightforward change.
> I figured out how to get libtinfo from ncurses by looking at the Arch
> PKGBUILD for ncurses.

Depending on how ncurses is built, libtinfo isn't actually needed.
ncurses' build system makes a libncurses library that may come in two
variants: one that only has the narrow character functions, and
another that has both the narrow character and the wide character
functions. You get the latter if ncurses' 'configure' script is passed
an --enable-widec option, and this also renames the library as
libncursesw. This means that libncursesw is essentialy libncurses with
more code, so it has everything libncurses has.

ncurses' build system can also split parts of libncurses out to
separate libraries, one of them being libtinfo, "the termlib library".
You get a libtinfo if the 'configure' script is passed a
--with-termlib option. This means that without that option, libncurses
/ libncursesw has everything libtinfo has. Debian chooses to build
libtinfo, Gentoo does not unless requested by the administrator with
the 'tinfo' USE flag, and Void seems to choose to not build it. If
that is the case, however, instead of trying to produce a libtinfo
somehow, you could just patch nosh's source/system-control.do and
source/system-manager.do scripts (they are shell scripts): change the
lines that do the tinfo=-ltinfo assignment with tinfo=-lncurses. I do
something like this on Gentoo.

> > would also help to know what the ID and VERSION_ID fields of Void's
> > /etc/os-release look like. I believe the former is 'void', and the
> > latter is absent, correct?
>
> That's right.

Good. There are some .do scripts that parse /etc/os-release and have a
case ... esac command that tests for different values of those fields.
They are used by redo to build some service bundle directories (nosh's
native format of a 'service definition') and components of the
configuration import subsystem, and are detailed in the aforementioned
"Packages and Ports" chapter of the nosh Guide. If you can figure out
what should go in new void:*) lines, maybe that might get included
upstream :)

Cheers,
G.

Re: has anyone gotten nosh to build on Void Linux?

[Jonathan de Boyne Pollard]

Guillermo:


 *

There is a |curses.h| file in both Void's 'standard' headers
directory and in a subdirectory named '|ncursesw|' (for the narrow
character and wide character versions of the library,
respectively). Normally, that would be |/usr/include/curses.h| and
|/usr/include/ncursesw/curses.h|.

On that score:  Those of you who have peeked at 1.38 will possibly have 
noticed the manual for the new |console-termio-realizer| command, which 
has a section explaining how it realizes onto terminals.  I have some 
things that I am mulling over.


 *

   The |chkservice| command (also new, and which you might also have
   spotted) uses wide character ncurses.  I am wondering whether it
   should employ |console-termio-realizer|'s mechanism instead.

 * The |monitor-fsck-progress| command uses wide character ncurses, but
   there is no real use case for it running against a terminal that
   does not understand ECMA48 control sequences.  I am wondering
   whether it should employ |console-termio-realizer|'s mechanism instead.
 *

   The only programs that do not explicitly use /wide-character/
   ncurses (and so require the additional slightly different
   development tooling) are |service-status|, and the |start|, |stop|,
   and |reset| subcommands of |system-control|.  And they only employ
   it for colourization, which the ncurses and terminfo models aren't
   particularly good for in the first place.  I am wondering whether
   they too should employ |console-termio-realizer|'s mechanism instead.

The general upshot would be that only |console-ncurses-realizer| ends up 
using wide character ncurses.  Only the one place for patches, and only 
the one flavour of curses; with the tradeoffs that are given in the 
|console-termio-realizer| manual.

Re: has anyone gotten nosh to build on Void Linux?

[Jonathan de Boyne Pollard]

Guillermo:


 *

The |wall|(1) program is available in Void's 'standard'
executables directories.

Because that's what nosh's build system and executables are going to 
expect, as far as I know.


For the sake of other readers: note that it is not the build system that 
employs the |wall| program.  (That would be bizarre.)  It is the 
|shutdown| program, at runtime, as described in its manual.  This is not 
a requirement specific to the nosh toolset's |shutdown| program. The old 
|shutdown| program in FreeBSD and OpenBSD has the same requirement, for 
example, as did the |shutdown| program in 386BSD.  Using the |wall| 
program to do its job rather than duplicating (a fork of) its code into 
|shutdown| (which the van Smoorenburg 
, 
upstart 
, 
and systemd 
 
|shutdown| programs all have) has a long history in the Unix world.

Re: has anyone gotten nosh to build on Void Linux?

[Jonathan de Boyne Pollard]

As someone porting to another operating system, you need also to pull up 
the /_nosh Guide_/  and 
read the _Packages and Ports_ chapter.  There is a section in that 
chapter of things that require attention (in addition to figuring out 
your operating system's required development packages) when porting to 
another operating system.  You'll notice from the current source that 
several people have already told me about their particular operating 
systems.  This is stuff that needs to be figured out just once per 
operating system, as long as the first person to do so tells me the 
right answers.  (-: