@JdeBP Do you have any guidance (or a HOWTO) for how to begin to use #nosh as the init and service manager on a FreeBSD system from start to finish?

The last time I tried (FreeBSD 13.x), I never managed to get it working.

Having a canonical way to do it for the distributions/OSes that interest you might also help garner a following around nosh, redo et. al?

@ermo

There is a fairly lengthy guide, in addition to the manual pages. It's on-line, as well as available packaged up and viewable off-line.

http://jdebp.info/Softwares/nosh/guide/

The package repository doco tries to explain the -run- packages.

http://jdebp.info/Softwares/nosh/freebsd-binary-packages.html

But what you probably want when 1.41 comes out is this:

http://jdebp.info/Softwares/nosh/timorous-admin-installation-how-to.html

(-:

#nosh

nosh Guide

I will be updating that latter before the 1.41 release, by the way. It dates from 2015. Some of the manual information has since expanded and been split out onto its own pages.

There might be short-term package problems because the build machine is fundamentally an old PC-BSD machine. I'm hoping to replace it with a new from-scratch up-to-date #GhostBSD on ZFS machine; but the plan is currently for that to happen, which will need to involve new hard discs, after the 1.41 release.

#nosh

@JdeBP Thank you for the prompt reply!

I should probably have specified that I was trying to build nosh (and therefore redo) from source on FreeBSD with the aforementioned aborted attempt to get redo, nosh et al. working.

@ermo

That's possibly a good approach with 1.41, until I sort out the #GhostBSD machine.

You can take the first step in trying it again, right now. #redo version 1.5 is out.

(Ignore the one in ports. Whoever is in charge of that hasn't made it past version 1.2 and is still using a WWW site that preceded the WWW site that I lost to Brexit half a decade ago.)

As you can see from package/debian/control it has a build dependency upon perl; but I think that that and base are all that you need.

@ermo

I'm doing #djbwares 10 next; right now, in fact (although I need to make a trip to the shops).

When I put it out, that's a good intermediate step to try next. It will test that you have a working redo without being a massive build that builds hundreds of things (as is the case for nosh).

It has the same basic command workflow as for building redo. There's a new accompanying Guide that details building from source but there aren't any real surprises over building #redo.

@ermo

You don't need to do anything with #djbwares 10. It's just exercising some of the building from source mechanisms that it shares with nosh without the massive source base.

You *can* try out things like the host command or

> sntpclock $IP | clockview

to see that you've built working executables, if so moved.

#nosh 1.41 itself is going to be a little while yet. I have a Debian KVT niggle to fix (It isn't disabling the kernel's cursor.) and some doco to review and update.

@ermo

#djbwares 10 is now out. If you have any problems building from source on FreeBSD, please let me know as soon as possible, because I'll want to fix them for #nosh 1.41, and that's next. It definitely builds on my FreeBSD build machine, though. (-:

@JdeBP Thanks for the pointers.

My FreeBSD machine is pretty old, hasn't been turned on in a while, and probably needs a bunch of updates to be current.

Because it is using an AMD FX-8350 CPU, I also used to build everything from source to get a "free" +5-12% performance boost, using jmarino's `synth` tool. I don't know if that is still supported on newer FreeBSD versions, however.

In short, I have a bit of researching and updating to do before I can offer you the feedback you are asking for.

@ermo

How old? I'm currently building on FreeBSD 10. Are you newer than that? Or older? If older, you should probably advance at least as far as 10, because there were some problems with pkg_ng in earlier versions. If newer, you might be alright as-is. (-:

@JdeBP Newer (13.x IIRC).

And I've apparently pulled out the SATA SSD it's installed on, so now I'm running around like a headless chicken trying to remember where I put it so I can re-install it in the box in which it belongs.

*Le sigh*

@JdeBP OK, found the SSD and got the bloody thing started. It's at 13.2 currently (with custom kernel build even). I can see it has _a_ redo installed to /usr/local/bin, but I can't see which version of redo it is (there's no --version argument).

Will give it a go now.

@JdeBP Got both redo-1.5 and djbwares-10 built as standalone executables (not FreeBSD packages). The examples you shared work.

If I run `bsd/rules clean build binary |& tee build.log`, I get the following error:

```
(...)
Building control file for leapsecs.
Building package djbwares-guide
pkg: manifest parsing error: error while parsing <unknown>: line: 40, column: 102 - 'numeric value out of range', character: '5'
*** Error code 1

Stop.
make: stopped in /usr/home/ermo/src/djbwares-10
```

@JdeBP After confirming that my local redo copy works and can build a working djbwares-10 suite, I tried fetching and building http://jdebp.info/Repository/freebsd/nosh-1.41.tar.gz (which I assume to be the current development sources?) and got the following error output:

https://gist.github.com/ermo/857bdc266183065e6a1327888f81aae7

I have included my list of installed packages, as it looks like I might be missing some necessary ports?

Guidance welcome. If this is all PEBKAC, I apologise in advance.

@ermo

That's a good sign. Only ifconfig is failing for you, and only on a socket capability flag, which I shall check in a moment.

The failures of the try*.cpp programs are expected. This the Bernstein style of autoconfiguration, where the redo script for a header compiles a tiny program, sees whether it builds, and writes the header accordingly.

tryevdev.cpp and tryupdwtmpx.cpp are supposed to fail on a FreeBSD system. Those are Linux and GNU libc things. You aren't missing a port.

Garbage collect IFCAP_POLLING_NOCOUNT. It wasn't used since very · freebsd/freebsd-src@17eea32

beginning of polling(4). The module always ignored return value from driver polling handler.

GitHub

@ermo

Ah! The black art of pkg manifests.

Take a look at line 40 of bsd/djbwares-guide/+MANIFEST .

On my system column 102 is right in the middle of a sha256 of a file. For which the digit "5" being out of range is a bizarre error.

I'm guessing that the +MANIFEST is different on your system, which implies that there's something different about either sha256 or stat. What did they actually put into the file for you?

@ermo

I was pointing out the poor state of the #pkgsrc doco in #NetBSD a little while ago. This is the area where #FreeBSD is equally bad with #pkgng.

FreeBSD's pkg-create(8) manual page assures us that +MANIFEST files must have "file" entries one per file. But the actual code for the pkg command only looks for a "files" object with an array of files.

Making manifest and "build-info" files for these tools is not a case of doing what the doco says to do.

https://github.com/freebsd/pkg/blob/main/libpkg/pkg_manifest.c#L114

pkg/libpkg/pkg_manifest.c at main · freebsd/pkg

Package management tool for FreeBSD. Help at #pkg on Libera Chat or [email protected] - freebsd/pkg

GitHub

@JdeBP As requested, line 40 of bsd/djbwares-guide/+MANIFEST looks like this on my system:

```
"/usr/local/share/doc/djbwares/commands/html/dnscache-showctl.html": { uname:root; gname:wheel; sum:56
3e64205b997125c75e8a051c8ea0949175381888cb39f7ae80d448af07d84a; perm:644; }
```

The best I can tell, column 102 is `:` right after `sum`.

HTH.

@ermo

It does, inasmuch as it's genuinely a "5" in the file. That's something, at least.

None of this is as documented, so the change that I've just made may or may not work. Give it a try.

#FreeBSD #pkgng

@JdeBP So just to confirm: I should redownload the djbwares-10 tarball from your site, and I will get the new version?

Do you by any chance host an up to date git repository anywhere public...?

@ermo

Yes. At the moment, because it's unreleased, that's tracking development. I save a fresh archive every so often, and I have saved the changes that I just made for the packaging and ifconfig. There's a similar archive for djbwares 11, now, as that's where development now is. That has the same fix for the package control file generation, that I hope, sans any doco, will work.

I don't track development with git; only releases go into git.

@JdeBP Getting a similar failure:

```
Building package djbwares-guide
pkg: manifest parsing error: error while parsing <unknown>: line: 101, column: 94 - 'numeric value out of range', character: '7'
pkg: Error parsing bsd/djbwares-guide//+MANIFEST
*** Error code 1
```

Line 101 looks like this:

```
"/usr/local/share/doc/djbwares/commands/html/tcprules.html": { uname:root; name:wheel; sum:7202e7161b84571464069af4189a0d22f278c546d1c3e63510c5872bd6e00c72; perm:644; }
```

Column 94 is `:`.

@ermo

There's a new djbwares-11.tar.gz file up that has a revised gencontrol script that quotes the checksum. I did the same fix to both softwares, and it works with the version of pkg that I have at any rate.

Version 11, though. 10 is released and frozen.

@JdeBP At this point, my thinking is that I can continue drip-feeding you current FreeBSD issues (and I'm happy to), or you could perhaps be convinced to do a basic, currently suppported FreeBSD 13.x or 14.x install and see which issues you are getting with your own eyes?

Again, happy to continue reporting issues. FWIW, neither djbwares-10 nor -11 successfully generate FreeBSD packages on my (now updated) 13.5 FreeBSD install.

LMK how you would like to proceed (if at all!).

@ermo

What we're doing is fine. Whilst you've been running things, I've written several of the nosh Guide pages that were on the to-do list, and I'm attacking that Debian KVT bug that needed fixing.

You might enjoy the new guide/building-from-source.html chapter .

I'm fairly sure that you've either pulled the old djbwares-10 archive again, or we've not synched on the djbwares-11 one. Because that generated snippet you showed is not in the format that that file has now.