git » armlfs-site.git » commit 77015a3

diff --git a/Makefile b/Makefile
new file mode 100644
index 0000000..d74fecc
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,3 @@
+all:
+	./poke-dates.sh
+	pelican
diff --git a/content/funkystuff/glibc-vs-vfpv4.md b/content/funkystuff/glibc-vs-vfpv4.md
index 1ef1654..838e664 100644
--- a/content/funkystuff/glibc-vs-vfpv4.md
+++ b/content/funkystuff/glibc-vs-vfpv4.md
@@ -1,4 +1,5 @@
 Title: GLibc vs VFPv4
+date: 2024-06-23
 
 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.
diff --git a/content/glasgow-interface-explorer.md b/content/glasgow-interface-explorer.md
new file mode 100644
index 0000000..275173d
--- /dev/null
+++ b/content/glasgow-interface-explorer.md
@@ -0,0 +1,16 @@
+Title: Glasgow Interface Explorer
+date: 2024-07-06
+
+ARMLFS has a build of the FPGA toolchain needed for using the [glasgow](https://glasgow-embedded.org/), plus
+other core dependencies.
+
+Do this first:
+
+    pacman -S python-libusb1 yosys nextpnr-ice40
+
+Then follow the instructions for Arch at [glasgow-embedded.org](https://glasgow-embedded.org/latest/install.html),
+though you can skip install of the builtin toolchain, like so:
+
+    pipx install -e 'glasgow/software'
+
+Happy Hacking :)
diff --git a/content/pages/about.md b/content/pages/about.md
index cbbcace..48f9f5e 100644
--- a/content/pages/about.md
+++ b/content/pages/about.md
@@ -1,4 +1,5 @@
 Title: About
+date: 2024-06-16
 
 The whole project is a one-person distro by Me, Urja  
 You can get in contact on Mastodon: [@urja@treehouse.systems](https://social.treehouse.systems/@urja).
diff --git a/content/pages/blog_index.md b/content/pages/blog_index.md
index b16e7d7..6e8f746 100644
--- a/content/pages/blog_index.md
+++ b/content/pages/blog_index.md
@@ -1,3 +1,4 @@
 Title: Blog
+date: 2024-06-16
 save_as: 
 url: blog_index.html
diff --git a/content/pages/download.md b/content/pages/download.md
index fa6156f..c0fef0e 100644
--- a/content/pages/download.md
+++ b/content/pages/download.md
@@ -1,4 +1,5 @@
 Title: Downloads
+date: 2024-06-15
 
 There are 2 formats provided, and 2 different images provided.
 
diff --git a/content/pages/index.md b/content/pages/index.md
index 18fefe4..7d2ef13 100644
--- a/content/pages/index.md
+++ b/content/pages/index.md
@@ -1,4 +1,5 @@
 Title: Welcome (to ARMLFS)
+date: 2024-06-16
 URL:
 save_as: index.html
 status: hidden
diff --git a/content/pages/known-issues.md b/content/pages/known-issues.md
new file mode 100644
index 0000000..e100f03
--- /dev/null
+++ b/content/pages/known-issues.md
@@ -0,0 +1,10 @@
+Title: Issues
+date: 2024-07-06
+
+This is just a list of weird things that I should look into later.
+
+- C201 kernel doesnt poweroff properly (workarounds: long press, or reboot to chromeos, or sleep)
+- Krita hardware accelerated canvas is just black (workaround: disable hwaccel in prefs)
+- nextpnr-ice40 GUI doesnt show up (workaround: LIBGL_ALWAYS_SOFTWARE=1, but that was _very_ slow. TODO.)
+
+If you've noticed something that you'd want to keep a track of, poke me and atleast i'll put it in this list.
diff --git a/content/pages/sources.md b/content/pages/sources.md
index 5b841e8..c2c67ca 100644
--- a/content/pages/sources.md
+++ b/content/pages/sources.md
@@ -1,4 +1,5 @@
 Title: Sources
+date: 2024-06-16
 
 
 ## TODO: Add the links to:
diff --git a/content/rebuild-process.md b/content/rebuild-process.md
index 7c6f38c..4af8f34 100644
--- a/content/rebuild-process.md
+++ b/content/rebuild-process.md
@@ -1,4 +1,5 @@
 Title: Rebuild Process
+date: 2024-06-23
 
 This is me documenting an ARMLFS system rebuild,
 while at the same time doing so.
@@ -7,12 +8,17 @@ 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
+# Some context
 
-We're running on a 64-bit ARM VPS (so, your host should atleast be an aarch64 device).
+We're running on a 64-bit ARM VPS - your host should atleast be an aarch64 device, with
+plenty of RAM (20GB was allocated during the build run) and some free disk space (like, 100 GB if you still need to download all the sources, maybe 50GB free before building.)
 I've ran the build executive both on top of Arch-ARM and Ubuntu, so the host OS
 should be kinda flexible (YMMV tho).
 
+Obviously, if you just want to build some small packages, and want to wing it
+on your own, ignore that if you like (like, I guess an ARMv7 board could run
+the build executive, and build most things (except nodejs, firefox, qt5-webengine.. maybe some other things I forgot).
+
 # The build executive
 
 The build executive is a "server version" of ARMLFS,
@@ -30,12 +36,12 @@ 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
+    $ 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).
 
@@ -44,13 +50,13 @@ Login as root (or as builder and "su -" to root).
 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
+    # 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
+    # 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.
@@ -81,8 +87,8 @@ 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).
+the whole bootstrap process might be overkill. Thus there's a tarball
+of the [bootstrapper](https://armlfs.urja.dev/dist/armlfs-bootstrapper.tar.zst).
 
 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`.
@@ -98,11 +104,11 @@ 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`.
+need to adjust the repos for only `[core]` from `https://armlfs.urja.dev/pkg/armv7h/core`.
 (FIXME: Adjust this?)
 
- # cd /sources/mk-builders
- # ./make-bootstrapper.sh
+    # cd /sources/mk-builders
+    # ./make-bootstrapper.sh
 
 # Rebuilding the core packages
 
@@ -115,12 +121,12 @@ 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
+    # cd /sources/core-pkgbuilds
+    # ./bs-spawn.sh
 
 And this is how to build all of them, in `order`.
 
- # ./bsbot.py 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
@@ -128,6 +134,169 @@ 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.
+(Note: `exit` from the bootstapper first.)
+We think the pkg' we built are good, and we have no previous core set to avoid clobbering:
+
+    # cd /sources/pkg/armv7h
+    # mv bootstrap core
+
+And run the script to make the (initial) /build-core.
+
+    # cd /sources/mk-builders
+    # ./make-builder.sh
+
+# Some background info on 64-bit ARMLFS
+
+We need a 64-bit (aarch64) build environment to 
+1. build the cross-gcc that's used as-if-native in the 32-bit environment (but can use >4GB RAM).
+2. be a 64-bit host for cross-compiling firefox (because doing the above was not easy for firefox).
+
+Initially, that 64-bit build environment was a version of Arch-ARM aarch64 from 2024/04,
+but then a firefox update happened that needed an update to nss. At that point I 
+realized that I need to be able to update the 64-bit build-host in sync with ARMLFS,
+ergo it would be best if the 64-bit environment _is_ ARMLFS.
+
+Thus i used the 64-bit Arch-ARM (from a set of packages roughly equivalent to ARMLFS `bootstrap`)
+to build the `core` set, and then repeated the process 3 times. 
+
+The first result was very messy - those binaries were linked to some libraries that are not part of ARMLFS core.
+For build 2 i extracted said libraries (but only the runtime .so) into the environment.
+The second result seemed okay, but to be sure I used it to build the `core` set a third time.
+
+(Note: this was not the process used to create 32-bit ARMLFS. 32-bit ARMLFS was initially built 
+following the Linux From Scratch book, from a Debian 12 armhf "host").
+
+So, that's why there is a 64-bit ARMLFS that's used only in the server/build context
+(and we only build core and a part of base for it.).
+
+That said, if there's a 64-bit device that would really benefit from ARMLFS, 
+and the desire to support it, it does mean we _could_ expand the 64-bit build.
+
+## Create the environment for 64-bit builds
+
+This one follows basically the same path we just went through, except for aarch64.
+
+    # cd /sources/mk-builders
+    # ./make-bootstrap64.sh
+
+Adjust the makepkg conf in the 64-bit builder at `/bootstrap64/etc/makepkg.conf`.
+Notably, SRCDEST needs to be set, IIRC.
+
+bs-spawn64.sh enters the 64-bit bootstrapper.
+
+    # cd /sources/core-pkgbuilds
+    # ./bs-spawn64.sh
+    # ./bsbot.py order
+    # exit
+
+Similar to armv7h, move the built packages to core.
+
+    # cd /sources/pkg/aarch64
+    # mv bootstrap core
+
+Note: there are some arch/fpu CFLAGS (passed to clang & rust) in the wrappers in bc64-usr-a32/. Check & adjust if necessary.
+
+    # cd /sources/mk-builders
+    # CARCH=aarch64 ./make-builder.sh
+
+
+## Build the 64-bit to 32-bit cross-gcc
+
+The 64-bit build-env is used by some packages (currently firefox,js115)
+as a cross-compilation "host", because it's easier to set up
+cross-compilation with clang & rust than to "sneak in" a
+64-bit clang & rust (as if they were native compilers) into the 32-bit environment.
+
+OTOH, with gcc, the sneaking in a 64-bit compiler into a 32-bit
+environment works very nicely, so we're going to build that
+and add it both to the 64-bit and 32-bit build environments.
+
+The 64-bit build env also works nicely as the environment in which to build this cross-gcc.
+
+Read these scripts beforehand, and note that gcc.sh in particular has some arch cflags.
+Be sure to run the binutils and gcc builds in the environment entered with bc64.sh.
+Otherwise you're just building a native 32-bit gcc, whoops.
+
+    # cd /sources/cross-a64
+    # ./bc64.sh
+    # ./prep.sh
+    # ./binutils.sh
+    # ./gcc.sh
+    # ./inject-to-buildhost.sh
+
+# Build the base packages
+
+At this point the build environments are ready to start building the base set of packages.
+There will be a couple of additions later (grep will be built with pcre2 support, and
+elfutils will be rebuilt with debuginfod support, come to mind).
+
+There's a pseudo-package armlfs-update-builder that does a pacman -Su in the
+buildcore (in non-volatile "mode"), ran right before llvm in the order list, to
+deal with those - this is so that building any specific normal package will
+not poke the buildcore, but running the full order build will do the update.
+
+Since you're going to want to have as much disk space as possible available, now
+is a good moment to clean up some build artifacts that were left behind:
+
+    # rm -r /sources/cross-a64/bld
+
+Be careful with typing this one (maybe replace rm -r with echo first).
+
+    # rm -r /sources/core-pkgbuilds/*/{src,pkg}
+
+For me, these two things were about 24 GB (combined).
+
+The base (and kde5) build systems do normally cleanup after themselves (unlike core),
+so from this point onwards there shouldnt be that many things to cleanup, unless
+something fails and is interrupted.
+
+Now onto building the base packages. Before starting the build, you should
+adjust /etc/pacman.conf in the build executive to point to the local repos (file:///sources/...)
+for base and core and do a pacman -Syy. The build system uses the executive as the 
+pacman sync database for the builder (as the builder is volatile).
+
+Note: the 64-bit builder uses its own package database (and the executive uses systemd-nspawn to `pacman -Sy` it.)
+You will need to build the first 505 packages (everything before firefox) also for the 64-bit
+environment, so it's upto you to decide which ones to build first, but here's the commands.
+
+64-bit:
+
+    # cd /sources/base-pkgbuilds
+    # CARCH=aarch64 ./build-in-order.py order64
+
+32-bit:
+
+    # cd /sources/base-pkgbuilds
+    # ./build-in-order.py order
+
+
+As with core, if the process is interrupted, you'll need to make up your own partial order-file for 
+"the rest".
+
+Building single packages can be done with `./mpkg.sh <pkgdir>` (`CARCH=aarch64 ./mpkg.sh <pkgdir>` for 64-bit).
+
+
+# Build the KDE5 packages
+
+The kde5 set is built in a similar fashion to base. You will need to initialize
+a repo at /sources/pkg/armv7h/kde5 (eg. repo-add and repo-remove iana-etc or smth to it),
+and add it to /etc/pacman.conf.
+
+    # cd /sources/kde5-pkgbuilds
+    # ./build-in-order.py order
+
+# Partial builds
+
+If you're just doing a partial build (or want to add a package),
+you will need the build-executive, the repos and:
+
+- [bootstrapper](https://armlfs.urja.dev/dist/armlfs-bootstrapper.tar.zst)  if the package is in `core`.
+- [builder](https://armlfs.urja.dev/dist/armlfs-buildcore.tar.zst) for most of base or kde5.
+- [64-bit build env](https://armlfs.urja.dev/dist/armlfs-buildcore64.tar.zst) for firefox or js115 (or aarch64, that is updates to the 64-bit build env itself).
+- [bootstrap64](https://armlfs.urja.dev/dist/armlfs-bootstrap64.tar.zst)  if the package is in `core` for aarch64 (core updates to the 64-bit build env).
+
+Thus I have tarballs of the various builders, linked above, to make partial builds easier.
+
+
+
+
diff --git a/content/the-long-story.md b/content/the-long-story.md
index ae4f3c3..023c084 100644
--- a/content/the-long-story.md
+++ b/content/the-long-story.md
@@ -1,4 +1,5 @@
 Title: The Long Story
+date: 2024-06-14
 
 This all started with ArchLinux ARM breaking the desktop experience on my ASUS C201 laptop, because I happened
 to try to update while they were in the middle of building KDE 6.
diff --git a/poke-dates.sh b/poke-dates.sh
new file mode 100755
index 0000000..820c0e8
--- /dev/null
+++ b/poke-dates.sh
@@ -0,0 +1,12 @@
+#!/bin/bash
+cd content
+for f in $(find -name '*.md'); do
+	if ! grep -q "^date:" $f; then
+		echo "Adding date to $f"
+		DATE=$(stat -c "%w" $f | cut -f 1 -d ' ')
+		sed -e "1 a date: $DATE" -i $f
+	else
+		# echo "$f has a date"
+		true
+	fi
+done