has anyone gotten nosh to build on Void Linux?

has anyone gotten nosh to build on Void Linux?

[Chris Brannon]

When I run package/compile from the root of the unpacked source tree, I
get:
redo: ERROR: all: Cannot find .do file to use.

-- Chris

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

[multiplexd]

On Sat, Jun 30, 2018 at 01:44:45AM -0700, Chris Brannon wrote:
> When I run package/compile from the root of the unpacked source tree, I
> get:
> redo: ERROR: all: Cannot find .do file to use.
> 
> -- Chris

Do you have pax installed? As I recall, not having pax is a common
stumbling block when trying to compile software packaged by JdeBP.

multiplexd.

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

[Jonathan de Boyne Pollard]

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

Chris Brannon:

> When I run package/compile from the root of the unpacked source tree, 
> I get:
>
>> redo: ERROR: all: Cannot find .do file to use.
>
You need to make your operating system POSIX-conformant.  I make fairly 
liberal use of some standard utilities in the build process including 
|pax 
<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html>|, 
|uname 
<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/uname.html>|, 
|mv 
<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html>|, 
and |expr 
<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/expr.html>| 
amongst others.  A POSIX-conformant operating system is a fairly minimal 
expectation for a build environment.  (It is not as though the build 
process is requiring, for example, the Bourne Again shell and its 
non-POSIX extensions for building from source on host operating systems; 
as some softwares do.) The source package page 
<jdebp.info./Softwares/nosh/source-package.html> notes the 
*non*-standard tools that are needed.

This information is pre-encoded in the |package/debian/control| file 
that I supply for Debian Linux, to be automatically checked by 
|dpkg-buildpackage|.  (There's no equivalent list that I supply for the 
BSDs; but it is also the case that the BSDs provide nearly all of this 
stuff, including the non-POSIX |install| tool, out of the box, in 
base.)  If you are building on a different Linux operating system, that 
is a good hint, with two caveats: Your Linux operating system won't 
necessarily package things up the same way as Debian or have the same 
package dependency tree, and Debian mandates a group of tools as 
standard without their needing to be mentioned in a 
|package/debian/control| file 
<https://debian.org/doc/debian-policy/#package-relationships>. 
Furthermore: Thomas Caravia has already worked out the build 
requirements for Arch Linux in terms of pre-requisite Arch packages, and 
the doco for Archnosh is a further source of clues for building on other 
Linux operating systems.

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

[Guillermo]

Hi,

2018-06-30 5:44 GMT-03:00 Chris Brannon:
>
> When I run package/compile from the root of the unpacked source tree, I
> get:
> redo: ERROR: all: Cannot find .do file to use.
>
> -- Chris

The nosh-1.37 source package? If you unpacked the source tarball in a
directory named 'nosh-1.37', you have a 'source' and a 'package'
subdirectory, you ran package/compile, but it *did not* create a
subdirectory named 'build', then, as people have said, most likely you
don't have an implementation of pax(1) installed. It is a
POSIX-specified utility, but on most [GNU/]Linux distributions you
have to manually install some package to get it. I believe on Void
that would be the 'pax' package.

Not related to redo's error message, but because distributions differ
in the way they package ncurses and util-linux, you might want to
check if:

* The libtinfo, libncursesw and libuuid libraries are present in
Void's 'standard' libraries directory.
* 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.
* 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. If not, patches will probably be needed. It
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?

It would be interesting to see what is needed for different OSes to
make nosh build. If you do try again, please report :)

Hope that helps,
G.

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

[Chris Brannon]

Guillermo <gdiazhartusch@gmail.com> writes:

> Hi,
>
> The nosh-1.37 source package? If you unpacked the source tarball in a
> directory named 'nosh-1.37', you have a 'source' and a 'package'
> subdirectory, you ran package/compile, but it *did not* create a
> subdirectory named 'build', then, as people have said, most likely you
> don't have an implementation of pax(1) installed. It is a
> POSIX-specified utility, but on most [GNU/]Linux distributions you
> have to manually install some package to get it. I believe on Void
> that would be the 'pax' package.

Sorry, I didn't have time to reply, but I made a good deal of progress
earlier today, after writing to the list.

Yes that is correct; pax was one of the things I was missing.  I was
also missing libuuid-devel.  I needed to change the header paths for
ncurses headers in the source.  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.

> 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.

> It would be interesting to see what is needed for different OSes to
> make nosh build. If you do try again, please report :)

Indeed.  Ideally, I'll eventually end up with a package script for
Void -- known as a "template" in Void parlance.  I'll keep working on
that until it's written.

> Hope that helps,

Thank you.

-- Chris

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]

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

As someone porting to another operating system, you need also to pull up 
the /_nosh Guide_/ <http://jdebp.info./Softwares/nosh/guide.html> 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.  (-:

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

[Jonathan de Boyne Pollard]

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

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 
<https://sources.debian.org/src/sysvinit/2.88dsf-59.10/src/dowall.c/>, 
upstart 
<https://bazaar.launchpad.net/%7Eupstart-devel/upstart/trunk/view/head:/util/shutdown.c#L672>, 
and systemd 
<https://github.com/systemd/systemd/blob/b0450864f1723ad12176d7956377d89ff4a84d8c/src/shared/utmp-wtmp.c#L361> 
|shutdown| programs all have) has a long history in the Unix world.

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?

[Jonathan de Boyne Pollard]

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

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.