@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
```

@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?

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

@ermo

I'm fairly confident that the file format change, assuming that the 13 pkg is as happy with it as the 10 pkg is, will overcome the one remaining hurdle to package generation working. It has done all of the rest of the build process, by that point. (-:

Unfortunately, that #GhostBSD installation that I mentioned before will be a comparatively *huge* undertaking, and it seems to me that at this stage we're close to the point where the build problems that you had years ago are fixed.

@JdeBP I can build a FreeBSD package using the newest djbwares-11.tar.gz now, though not a freshly fetched djbwares-10.tar.gz -- 10 still fails for me on the +MANIFEST checksum parsing stuff (in case that is unexpected).

nosh-1.41 w/ sha256sum `17c982a1af29f476e401b8e8137a0503237b0aad5d46b8e2b8a5173891a5c640` fails to compile for me on 13.5 w/ clang 19.1.17:

https://gist.github.com/ermo/82be9beb5c5b79888a96bf590589bb6e

This is a different error to on 13.2, and might be caused by increased compiler strictness w/ 19.1.17?

@ermo

#djbwares 10 is always going to fail. What's going to happen is that I'll push 11 out soon with these fixes in.

This is good news, because I really wasn't planning on doing updated FreeBSD beyond FreeBSD 10 until *after* the #nosh 1.41 release. But now we've almost got things working for FreeBSD 13 before 1.41 gets released.

The u32string thing should be an easy fix, as it's a known change. It's a question of how bleeding edge one can be on older compilers, though. Let me test.

@ermo

It looks like the old compilers do not complain. I don't have a clang 19 system to test, but I it's well-known what the fix for this is and I've just put it into place.

So there's another 1.41 archive up, now.

@JdeBP It looks like the new nosh-1.41 version gets most of the way there now, even if it doesn't fully succeed:

https://gist.github.com/ermo/c8c7cf6218904cc431f6e8105a9bea0c

nosh-1.41-build.log

GitHub Gist: instantly share code, notes, and snippets.

Gist

@ermo

It has build almost everything apart from that 1 service, and that was just a missing list file, which I have now fixed and uploaded a fresh archive for.

You should get well into the package building part, now.

@JdeBP Looks like the latest nosh-1.41 FreeBSD pkg build completed on 13.5.

Here's the build log, in case you spot something you would prefer to fix before releasing:

https://gist.github.com/ermo/2694d499c2803a2eccf745596c5c4ee9

nosh-1.41-build.log

GitHub Gist: instantly share code, notes, and snippets.

Gist

@ermo

Just the nullptrs in the FreeBSD-only code paths, and they won't change actual functionality.

It looks like everything has built.

Here are some fairly innocuous commands that you can try straightaway:

command/ifconfig -a

command/ps -Ad | unvis

command/printenv

command/console-decode-ecma48 --input

what command/*

I suggest not experimenting with any of the -run- stuff until you've looked at what commands and shims you want.

pkg info -F on the packages might help with that.

#nosh

@JdeBP All of the `command/(...)` stuff appears to work.

Next step has to be to read the documentation to get a better feel for how to set up nosh on my system.

Thank you for the help in getting this sorted, and I hope it wasn't too much trouble. ^^'

@ermo

No worries. This was stuff that I was going to have to do anyway, just a bit earlier than planned. And it is quite good that I can push 1.41 out and not have the prospect of people coming back straightaway saying that they couldn't build it on newer versions than my build machine, and having to keep explaining that a build machine upgrade was the next step.

Quite the opposite of trouble. (-:

I was writing Guide pages whilst you were doing things, and I still have 1 to write.

#nosh

@JdeBP I can confirm that redo-1.5, djbwares-11, and nosh-1.41 build packages just fine on both #FreeBSD 13.5 and 14.3.

Build logs on 14.3 in case you end up spotting something interesting:

- redo-1.5: https://gist.github.com/ermo/98d627c15c7768e16c42d460356bbd7e
- djbwares-11: https://gist.github.com/ermo/238af242324aabca481bb9ebd37e1ff4
- nosh-1.41: https://gist.github.com/ermo/166ecefe1599104e668cf7dafd833263

#redo #djbwares #nosh

FreeBSD-14.3-redo-1.5-pkg-build.log

GitHub Gist: instantly share code, notes, and snippets.

Gist

@ermo

That is good news.

I *think* that I've just written the last Guide page that I had on the to-do list for #nosh 1.41.

@JdeBP I have compiled the ncgopher client and tried reaching gopher://repository.jdebp.info:70/1/ to no avail (it is listed at the bottom of http://jdebp.info/Softwares/djbwares/ and is advertised as "Bonus GOPHER content").

gopher://jdebp.info:70/1/ is reachable with ncgopher, but appears to be empty.

Am I missing a trick?

Daniel J. Bernstein's softwares all in one

The djbwares toolset is a whole bunch of Daniel J. Bernstein's toolsets all in one, with some basic patches and modernized documentation.

@ermo

DNS problem at my end. The secondary server polls every half day or so, and last polled at mid-day, so it is going to take a little while for the fix to appear.

@JdeBP To me, one of the benefits of e.g. a git-based dvcs workflow is that the git ref of the tip on the main branch serves as a hash sum, with the dual benefit of having a commit log to follow.

Even if you don't use git, could you perhaps think of a way to approximate this particular benefit somehow?

Perhaps sha256sums could be auto-generated for the in-development software versions you upload, such that it is simple to check whether currently downloaded archives have seen an update?

@ermo

Sounds a bit complex. (-:

Debian apt-ftparchive source actually makes checksum lists for source packages.

No handy equivalent in pkg repo, though.

It's not going to be high on the priority list. I could possibly modify the .do scripts to do something non-standard.

In the meantime, the HTTP Last-Modified: response header is right and the If-Modified-Since: request header is respected by Bernstein publicfile. For what that's worth.

#publicfile #APT #pkg_ng #FreeBSD