Thanks for the testing & review!

You're welcome.

The makeinfo thing just looks like a stylistic warning; do you know why it broke the build? But a larger problem is that the output of the bootstrap is supposed to be independent of the original host, which means any generated files need to be generated by the included tools. (Even if we patch to support however many makeinfo versions, I expect they'll produce slightly different output.) Texinfo could be added to the build tools, but requires Perl which I'm not seeing as justifiable for this. So, better to patch the build system to stop trying to rebuild the .info files, and use the shipped ones as happens when the host lacks makeinfo, unless or until someone finds a better way.

Looks like makeinfo treats the warning as a critical error. I think that not rebuilding the docs is indeed a better solution.

I'm not up enough on Lilo to judge that NVMe patch offhand but glad to hear it works. Seems odd that it needs to be quite such a special case but Lilo does seem to have a lot of that... how to put it... need for reassurance that things are OK and it can do as told.

It seems from the patch that Lilo is having troubles with some classes of devices (MAJOR_SATA1, MAJOR_SATA2), and such errors can appear not only with NVMe devices.

The signing mechanism uses GPG detached signatures alongside the package file and trusts pubkeys in /etc/gpkg-wot/. IIRC it does work; I don't find myself using it, though I don't have the kind of large fleets that might benefit these days. One thought is that the perceived need for binary packages in the first place is an indication that the build systems are doing way too much.

I see, apparently the code for verification exists but there was no documentation for signing.

The /dev/pts mount point is included in the example fstab. Other distros tend to mount it from init scripts before fstab is even consulted. It's also necessary for any sort of screen/tmux/xterm. See pts(4). Not sure what's up with the redundant /dev/ptmx and /dev/pts/ptmx ; I'm seeing the same on Gentoo.

Hm, I wonder what went wrong there then. It is indeed in /etc/examples/fstab - either I fat-fingered and removed that line when editing /etc/fstab, or something else failed.

I'm tending to think this was a doomed effort; as you point out there's no reliable replacement for alloca / VLAs in some cases, and their use is rampant otherwise, so the compiler had better make sure that guard pages actually work - which presently it does not. (Some background.)

The problem is also that it's not only about VLAs, but also about large on-stack allocations - which also calls for correctly working guard pages.

Also, the O0-O1-O2 optimization level selection in both bootstrap and gports looks a bit arbitrary: it would be good to have a look at what -f[optimization] flags are enabled at each level, and hand-pick those that cannot cause any harm

I think there's some inherent arbitrariness here. How would you propose to decide that "cannot cause any harm", and to what? Besides weighing the odds of compiler bugs, there's code with technically undefined behavior by strict interpretation of standards but that was fine in practice until compilers reached a certain threshold of squeezing blood from rocks. My general approach is to use -O1 by default and -O2 for performance-sensitive things, unless there are suspected problems or it's a particularly security-sensitive thing.

Well, there are some inlining-related passes that would be interesting to investigate for potential issues with UB and to enable later (inlining is typically responsible for biggest speedups), while stuff like -fdelete-null-pointer-checks looks like an absolute no-go. Also, IIRC GNAT adds several other passes and options (something like -fpreserve-control-flow) that might be useful.

I don't find the base installation especially habitable anyway. The idea was just enough cross-compiling to get a system that installs and boots to a freestanding environment suitable for further builds. Perhaps another instance of a Linux rather than BSD approach. That said, now that I've tried mandoc it does seem reasonably simple and a good candidate for adding to the bootstrap. I did work out a better workaround for the man path:

(for dir in /gales/man/* ; do echo "manpath $dir" ; done) > /etc/mandoc.conf

Then assuming man-pages and man-pages-posix are installed, move their entries to the end of the file so more specific manuals are not shadowed by generic ones (such as for example "man" itself).

Not sure about bootstrap, but a script to regenerate the mandoc config after installation, to be invoked only manually, would be a useful addition. I have tested your snippet and it works fine.

Hm. Do you mean you see no value in the whole troff formatting system outside the search aspect of "man"? Granted I'd much rather write in HTML or practically any other format... but the existing content is there and I figured it was worthwhile to support.

The comment was to the fact that if default man pages installation is broken, then docs must be shipped in a readable form anyways. With working mandoc, I see no issue with the troff format.

Further automation is certainly possible, as seen with apt-get on top of dpkg or yum on rpm. Unclear to me that it's desirable just yet, if we can move things in the direction of self-contained V trees. What do you see as particularly onerous about Apache or imagemagick? I did get nginx working fine after all (although I now hear it's uncool), and with a somewhat stripped-down PHP too.

IMO dependency management is a big can of worms that is better squashed without opening, so finding some way different from "more automation" should be a goal. Apache and imagemagick were used as packages with rather extensive set of dependencies.

The makeinfo thing just looks like a stylistic warning; do you know why it broke the build? But a larger problem is that the output of the bootstrap is supposed to be independent of the original host, which means any generated files need to be generated by the included tools. (Even if we patch to support however many makeinfo versions, I expect they'll produce slightly different output.) Texinfo could be added to the build tools, but requires Perl which I'm not seeing as justifiable for this. So, better to patch the build system to stop trying to rebuild the .info files, and use the shipped ones as happens when the host lacks makeinfo, unless or until someone finds a better way.

The gnu_inline problem is caused by change of default standard in GCC 5 if I'm reading correctly. The stronger fix then would seem to be adding -std=c89 to the host compiler CFLAGS (BUILD sections 3.3 and 3.5).

The output of the bootstrap process are a kernel image, an archive with base root system (base-$date), and optional archives with compilers (c-$date) and ports (gports-$date).

I'd add the skeleton-.sh and gales-util-.sh shell archives to that list. The gports tarball step is something I'd remove; it's properly a subtree of the overall Gales repository and better to have the whole thing.

I'm not up enough on Lilo to judge that NVMe patch offhand but glad to hear it works. Seems odd that it needs to be quite such a special case but Lilo does seem to have a lot of that... how to put it... need for reassurance that things are OK and it can do as told.

the build process is indeed reproducible

Yep; for the curious, this and some other cleanups are found in base/patches/lilo-24.0-cross.patch in the repository archive.

one wart is that the built packages do need to be signed - and I would not mind doing that - but apparently this feature is not finished yet.

From http://logs.ossasepia.com/log/ossasepia/2020-01-12#1014924 : "certainly a documentation TODO, but safe to skip as dorion_road said. Since for better or worse the gports system works by producing intermediate package files, I figured there'd better be a way to sign & verify them. The step in question is for if you want to include a public key for that in install media."

The signing mechanism uses GPG detached signatures alongside the package file and trusts pubkeys in /etc/gpkg-wot/. IIRC it does work; I don't find myself using it, though I don't have the kind of large fleets that might benefit these days. One thought is that the perceived need for binary packages in the first place is an indication that the build systems are doing way too much.

The /dev/pts mount point is included in the example fstab. Other distros tend to mount it from init scripts before fstab is even consulted. It's also necessary for any sort of screen/tmux/xterm. See pts(4). Not sure what's up with the redundant /dev/ptmx and /dev/pts/ptmx ; I'm seeing the same on Gentoo.

enable by default a GCC flag to warn about excessive stack usage in the applications, with the goal of eliminating it somehow

I'm tending to think this was a doomed effort; as you point out there's no reliable replacement for alloca / VLAs in some cases, and their use is rampant otherwise, so the compiler had better make sure that guard pages actually work - which presently it does not. (Some background.)

Also, the O0-O1-O2 optimization level selection in both bootstrap and gports looks a bit arbitrary: it would be good to have a look at what -f[optimization] flags are enabled at each level, and hand-pick those that cannot cause any harm

I think there's some inherent arbitrariness here. How would you propose to decide that "cannot cause any harm", and to what? Besides weighing the odds of compiler bugs, there's code with technically undefined behavior by strict interpretation of standards but that was fine in practice until compilers reached a certain threshold of squeezing blood from rocks. My general approach is to use -O1 by default and -O2 for performance-sensitive things, unless there are suspected problems or it's a particularly security-sensitive thing.

/package, /command and /service are direct from DJB; that's how daemontools is installed and the distributor is discouraged from breaking cross-system path compatibility. There's a number of other packages that picked up the convention, though not included here. /gales/pkg and the others are my variation on the ideas, which I use for new things and porting FHS-style software. Agreed that documenting the hierarchy would be nice.

The lack of man pager in the default installation is a strange decision.

I don't find the base installation especially habitable anyway. The idea was just enough cross-compiling to get a system that installs and boots to a freestanding environment suitable for further builds. Perhaps another instance of a Linux rather than BSD approach. That said, now that I've tried mandoc it does seem reasonably simple and a good candidate for adding to the bootstrap. I did work out a better workaround for the man path:

(for dir in /gales/man/* ; do echo "manpath $dir" ; done) > /etc/mandoc.conf

Then assuming man-pages and man-pages-posix are installed, move their entries to the end of the file so more specific manuals are not shadowed by generic ones (such as for example "man" itself).

in this case could just convert all docs to text, and use 'more' to read them.

Hm. Do you mean you see no value in the whole troff formatting system outside the search aspect of "man"? Granted I'd much rather write in HTML or practically any other format... but the existing content is there and I figured it was worthwhile to support.

The ports documents already point out the installation order for some of the libraries and applications, and with larger software, this may become inconvenient.

Further automation is certainly possible, as seen with apt-get on top of dpkg or yum on rpm. Unclear to me that it's desirable just yet, if we can move things in the direction of self-contained V trees. What do you see as particularly onerous about Apache or imagemagick? I did get nginx working fine after all (although I now hear it's uncool), and with a somewhat stripped-down PHP too.

Officially, GCC "optimization levels" come with a list of passes enabled by each level. The question is indeed how up-to-date is that list and whether there are any passes that could break program semantics. Unfortunately, determining this is a project in itself, and it would require a GCC expert, or at least someone with the guts and patience to dive into the codebase.

Also, AFAIK anything up to and including -O2 should "be safe", in the sense that the undefined behaviours are deterministic enough so that the compiler can build e.g. the Linux kernel without causing any breakage between e.g. assembly and C code, or between various interfaces. -O3 however will optimize aggressively, to the point that it can break stuff such as threading and structure layout between libraries.