git » armlfs-site.git » commit 4c396a7

diff --git a/content/funkystuff/glibc-vs-vfpv4.md b/content/funkystuff/glibc-vs-vfpv4.md
new file mode 100644
index 0000000..1ef1654
--- /dev/null
+++ b/content/funkystuff/glibc-vs-vfpv4.md
@@ -0,0 +1,26 @@
+Title: GLibc vs VFPv4
+
+I thought it'd be nice to have all of these random things I've found / worked around 
+along the process as little artices ("funkystuff"), so here's the first one.
+
+Compiling glibc with -mfpu=neon-vfpv4 (with gcc 12.3.0) causes the testsuite to fail 8 tests:
+math/test- double,float32x,float64,ldouble - j0,log.
+
+(Compiling with -mfpu=neon (=VFPv3) passes.)
+
+The "j0" tests only return "failed" (which is not very helpful), but test-double-log
+gave a relatively helpful summary of the problem (I shortened it a bit):
+```
+testing double (without inline functions)
+Failure: Test: log (0xe.a0288c3cb5ecp-4)
+Result:
+ is:         -8.9814025035627298e-02  -0x1.6fe0d4c400978p-4
+ should be:  -8.9814025035627312e-02  -0x1.6fe0d4c400979p-4
+Maximal error of `log'
+ is      : 1 ulp
+ accepted: 0 ulp
+```
+
+Since the only real addition in VPFv4 (compared to VFPv3) seems to be Vector Fused Multiply Accumulate whose description says "The instruction does not round the result of the multiply before the accumulation.", i think this is a rounding difference thats atleast not supposed to be actually an issue (difference of 1 ULP with such functions, eh.)
+
+Anyways, I'm compiling glibc with -mfpu=neon (so -lm is nice and *exact*), but leaving -mfpu=neon-vfpv4 enabled for the rest of the system.
diff --git a/content/rebuild-process.md b/content/rebuild-process.md
new file mode 100644
index 0000000..7c6f38c
--- /dev/null
+++ b/content/rebuild-process.md
@@ -0,0 +1,133 @@
+Title: Rebuild Process
+
+This is me documenting an ARMLFS system rebuild,
+while at the same time doing so.
+
+Parts of this will surely be helpful for setting
+up a build system just for "partial" updates
+(want a new package or two?) too.
+
+# Oh, context is everything
+
+We're running on a 64-bit ARM VPS (so, your host should atleast be an aarch64 device).
+I've ran the build executive both on top of Arch-ARM and Ubuntu, so the host OS
+should be kinda flexible (YMMV tho).
+
+# The build executive
+
+The build executive is a "server version" of ARMLFS,
+just for container use.
+
+The tarball contains:
+
+- directory "armlfs" (this is the root fs of the executive)
+- armlfs.sh (to systemd-nspawn the executive)
+- armlfs-launch.service (optional and needs personalization, to automatically run armlfs.sh on boot)
+
+[The tarball.](https://armlfs.urja.dev/dist/armlfs-build-exec.tar.zst)
+
+Note: the build executive is also a debuginfod server (at port 8002).
+It also spawns sshd on port 2204 - you will need to add your
+own authorized keys into it if you want to use ssh into it.
+
+ $ cd ~/my-suitable-place
+ $ wget https://armlfs.urja.dev/dist/armlfs-build-exec.tar.zst
+ $ sudo tar xvf armlfs-build-exec.tar.zst
+ $ # You really should take a look at scripts you've downloaded before you run them ;)
+ $ # Also, I run armlfs in a screen session usually... so launch that at this point, if not already doing so.
+ $ ./armlfs.sh
+
+Login as root (or as builder and "su -" to root).
+
+## Get all the repos
+
+Well, first you need a repo to tell you what repos to get ;)
+I decided that this repo shall be at /sources/repo-mgmt.
+
+ # cd /sources
+ # git clone https://armlfs.urja.dev/git/sources/repo-mgmt.git
+
+Then, we have a script available to (kinda recursively) clone all of the repos.
+
+ # cd repo-mgmt
+ # ./clone-gits.sh
+
+There's about 1327 or something like that repos, so while we're cloning, 
+I'll tell you something about the repos.
+
+There's a handful of repos cloned at /sources/*reponame*, those are listed
+in a textfile in the repo-mgmt repo (it does not list itself, to avoid... awkwardness.).
+
+The git repositories for the *repo*-pkgbuilds directories only contain
+the awkward build scripts for said repo, plus a file named "order" that
+(unsurprisingly) contains the order we want the packages built (plus a flag
+if we want to do a special kind of build - used for breaking dependency loops).
+
+Anyways, the `clone-gits.sh` script uses the `order`-file to determine what
+repos we want to clone in said *repo*-pkgbuilds directory.
+
+# The bootstrapper
+
+Now, I want to end up with all packages rebuilt, with the minimal amount
+of influence from the previous set of packages in the new set.
+
+Packages in the `core` repo are built with the "bootstrapper",
+with the concept that the packages that are installed in the bootstrapper
+tree/container are replaced with the built versions as we progress through
+the build process.
+
+Also of note, not every package in `core` is needed for a bootstrap,
+so we start bootstrapper off with a minimal set of packages, defined by the
+meta-package in core named `bootstrap`.
+
+If you just want to rebuild/adjust/add one package from/to `core`, going through
+the whole bootstrap process might be overkill. Thus TODO: Add a link
+to a bootstrapper tarball (once I have a new one).
+
+For the purpose of assembling a build "system" (just a rootfs tree) from the
+package repos, there's a set of scripts in `/sources/mk-builders`.
+
+There's also script there to make a build executive (that we just downloaded,
+to avoid a cyclical dependency on needing a build executive to make a build executive, lol) (`make-exec.sh`).
+
+But now we need a bootstrapper, so `make-bootstrapper.sh` it is.
+
+Note: make-bootstrapper uses /etc/makepkg.conf from the build-exec
+as the makepkg.conf for the bootstrapper. This is the moment to 
+edit the initial makepkg.conf (adjust CFLAGS, PACKAGER, etc.)
+
+Also of note: make-boostrapper needs the `[core]` repo in `/etc/pacman.conf` to be functional.
+The shipped version expects you to already have binary package trees under /sources - so you'll
+need to adjust the repos for only `[core]` from `https://armlfs.urja.dev/pkg/core`.
+(FIXME: Adjust this?)
+
+ # cd /sources/mk-builders
+ # ./make-bootstrapper.sh
+
+# Rebuilding the core packages
+
+In order to (re)build the core packages, you will _need_ to have the
+sources pre-downloaded, by default into `/sources/archives/core`.
+
+I can NFS mount the web server, so I've done that, but i assume
+you could download them with a recursive wget from `https://armlfs.urja.dev/archives/core`.
+TODO: Maybe add an rsync interface for people to download bulk items?
+
+This is how to enter the bootstrapper:
+
+ # cd /sources/core-pkgbuilds
+ # ./bs-spawn.sh
+
+And this is how to build all of them, in `order`.
+
+ # ./bsbot.py order
+
+In case the build fails mid-way write a new partial order-file (cp order partial-order; nano partial-order) and use that.
+The bootstrapper environment does not start with nano, so I find it
+easier to just exit it for the edits (or use a different shell).
+
+# Create the (initial) build environment (for base (and kde5))
+
+# TODO: We need script to create buildcore64, and
+# to build the 64-bit gcc in there. But yeah first make the build-core to act
+# as a sysroot for the gcc build.