You’re very close. That generic “[ERROR] Unhandled error!” is poudriere’s way of bailing when something went wrong a moment earlier, but the real cause is in the run logs. Here’s a clean, practical way to surface the actual error and get you building.
1) Open the correct logs for this run
Poudriere created a build at:
/usr/local/poudriere/data/logs/bulk/143amd64-development/2025-11-05_11h19m34s
Use poudriere’s log viewer so you do not have to hunt:
sudo poudriere logsh -l
Select the build that matches 2025-11-05_11h19m34s, then check:
build.log for framework messages
errors/ for any per-port error logs
logs/ for the last action before the crash
If you prefer non-interactive:
sudo poudriere logs -j 143amd64 -p development -l # list builds
sudo poudriere logs -j 143amd64 -p development -b 2025-11-05_11h19m34s -a # show all
sudo poudriere logs -j 143amd64 -p development -b 2025-11-05_11h19m34s -e # only errors
2) Rerun once with full verbosity to catch the cause
This will print more detail to your terminal and tee logs:
sudo env POUDRIERE_TEE_LOGS=1 POUDRIERE_VERBOSE=1 POUDRIERE_DEBUG=1 \
poudriere testport -v -j 143amd64 -p development editors/emacs
3) Clear the stale “.building” state first
You have this warning:
Using packages from previously failed, or uncommitted, build: .../.building
Clean it so a bad prior state does not poison the next run:
sudo poudriere pkgclean -j 143amd64 -p development -A
# If it still complains, remove the marker then clean packages:
sudo rm -f /usr/local/poudriere/data/packages/143amd64-development/.building
sudo poudriere pkgclean -j 143amd64 -p development -A
4) Sanity-check your configuration
Minimal working poudriere.conf for ZFS systems:
ZPOOL=zroot
BASEFS=/usr/local/poudriere
RESOLV_CONF=/etc/resolv.conf
DISTFILES_CACHE=/usr/ports/distfiles
ALLOW_MAKE_JOBS=yes
USE_TMPFS=all
If you are not using ZFS, set:
NO_ZFS=yes
BASEFS=/usr/local/poudriere
Also verify these exist and are writable by root:
sudo mkdir -p /usr/ports/distfiles
sudo chown root:wheel /usr/ports/distfiles
5) Make sure your ports tree is complete
Your development tree uses METHOD null which just mounts a directory. If that directory is an overlay or is missing core bits like Mk/, poudriere can crash early.
Create a clean canonical tree for testing:
# Use git to match 14.3
sudo poudriere ports -c -p main -m git -B releng/14.3
# Or the "latest" quarterly:
# sudo poudriere ports -c -p main -m git -B 2025Q4
Then try:
sudo poudriere testport -j 143amd64 -p main editors/emacs
If that works, the issue was your development tree. If it still fails, the problem is elsewhere and the verbose logs will show it.
6) Quick infrastructure checks
Run these to catch common foot-guns.
Kernel and userland versions inside the jail vs host:
freebsd-version -kru
sudo jls -v | grep 143amd64
Networking in the jail is fine in your transcript, since pkg fetched, but confirm DNS is mounted as poudriere shows:
/etc/resolv.conf -> /usr/local/poudriere/.../ref/etc/resolv.conf
Permissions on the packages repo directory:
sudo ls -ld /usr/local/poudriere/data/packages/143amd64-development
7) Try a tiny port first
If the framework itself is unhappy, even a trivial port will fail. This isolates “infra vs emacs.”
sudo poudriere testport -j 143amd64 -p main ports-mgmt/pkg
If pkg builds, your infra is good and any failure with editors/emacs is a port issue or options issue. If pkg fails, fix infra per the logs.
8) About that undeletable ports tree
You can remove a ports tree entry like this:
sudo poudriere ports -d -p ghostbsdports
If poudriere refuses, stop any jails using it and delete its config file and mountpoint:
sudo service jail stop || true
sudo rm -f /usr/local/etc/poudriere.d/ports-ghostbsdports.conf
sudo rm -rf /home/krydos/Projects/ghostbsd-ports/.poudriere.ghostbsdports 2>/dev/null || true
sudo poudriere ports -l
9) How I usually build and test ports
Keep one clean jail per major release, e.g. 14_3amd64.
Keep one canonical ports tree synced by git, e.g. main on releng/14.3 or quarterly.
For quick checks while developing a port:
poudriere testport -j 14_3amd64 -p main category/port
For full sets:
poudriere bulk -j 14_3amd64 -p main -f list-of-origins.txt
Always inspect logs with poudriere logsh -l after failures.
If you run the verbose command in step 2 and paste the final 50 to 100 lines of build.log plus any file under errors/, we can pinpoint the exact cause. The most frequent culprits for an “Unhandled error” at the stage you reached are an incomplete null ports tree, a mis-set ZFS vs NO_ZFS switch, or a stale .building repository directory.
