diff options
| -rw-r--r-- | todo.org | 10 |
1 files changed, 4 insertions, 6 deletions
@@ -224,18 +224,16 @@ Core automation infrastructure - enables continuous validation ** TODO [#B] Fix install errors surfaced by the 2026-05-11 VM test run Errors logged during the VM install. Status as of the 2026-05-11 18:36 run (=test-results/20260511-183643/archsetup-output.log=) after the =48c9439= fontconfig/dconf fix: 7 → 6. - refreshing font cache — RESOLVED in =48c9439= (now installs =fontconfig= before calling =fc-cache=). -- configuring GTK file chooser — exit 1. NOT a missing-package issue: =dconf= is installed; =sudo -u user dbus-launch dconf write …= still fails (exit 1) in the headless fresh-user install context. Deeper fix needed — make it tolerant when there's no session, or defer the writes to first login (these settings only matter for desktop-session perf, not install correctness). -- configuring GNOME interface settings in dconf — was exit 127, now exit 1 after =48c9439= (=dconf= now installed). Same underlying issue as the GTK one above. +- configuring GTK file chooser — RESOLVED in =ecab29f= (switched to a system-wide dconf db at =/etc/dconf/db/site.d/=; needs no session bus during install). +- configuring GNOME interface settings in dconf — RESOLVED in =ecab29f= (same fix as the GTK file chooser above). - enabling firewall — exit 1: =iptables v1.8.13 (nf_tables): Could not fetch rule set generation id: Invalid argument=. Still present in the 18:36 run; likely a VM-kernel/nf_tables artifact — confirm on bare metal before treating as an archsetup bug. - verifying firewall is active — exit 1 (follow-on from the firewall-enable error). - enabling gamemode for user — exit 1 → step "gaming" FAILED — non-critical. - tidaler (AUR) — logged in the error summary with exit code 0 (odd; logging quirk or transient AUR build noise?). Also seen in the 18:36 run's log-diff (post-install systemd noise, probably VM-environment): =pam_systemd … CreateSession failed= / =logind: Failed to start session scope … Permission denied=, and =Failed to start Proton VPN Daemon= (no VPN config in the test VM). -*** TODO [#B] AUR exit-0 logged as error — pattern expanded beyond tidaler -The =tidaler= bullet above noted "logged in the error summary with exit code 0". The 2026-05-16 07:40 VM run (=test-results/20260516-074025/=) shows the same pattern now affecting 6 AUR packages: =tidaler=, =mkinitcpio-firmware=, =speedtest-go-bin=, =rar=, =masterpdfeditor=, =zsh-fast-syntax-highlighting-git=. Every entry has =error code: 0= — the installs succeeded (the packages appear in =archsetup-installed-packages.txt=) but =aur_install= or its caller is mis-categorizing them as errors. The bug isn't AUR build noise (transient) — it's a deterministic logging-classification bug in the install path. - -Recommendation: trace =aur_install= and the error-summary aggregator in =archsetup=. Likely candidates: (a) the exit-code capture grabs a non-final command's status (e.g., a =makepkg=/=yay= sub-step that exits 0 still triggers the error branch via an =||= chain whose left side returned non-zero earlier); (b) the summary's =error_warn= sink is keyed on a flag the calling code sets even when the wrapping command succeeds. Add a small log line at each =error_warn= invocation site showing both the wrapped command's actual exit and the captured value to triangulate. Real packages are installing — this is purely a noise issue, but the noise is now drowning out genuine failures in the error summary. +*** 2026-05-19 Tue @ 13:18:56 -0500 Fixed AUR exit-0 logging bug at the root +Root cause was in =retry_install=: =last_exit_code=$?= ran AFTER =if eval ...; then return 0; fi=. Bash defines an if-compound's exit status as zero when no condition tested true, so a failing eval's exit code got overwritten with 0 before reaching =error_warn=. Fix in =8221c54=: capture =$?= from =eval= directly into a local var, then compare against the captured value in the if. VM-verified in =test-results/20260519-115318/=: =mkinitcpio-firmware (AUR)= and =tidaler (AUR)= now report =error code: 1= (yay's actual exit) instead of the misleading =error code: 0=. The same packages still appear in the summary because yay returns non-zero when sub-deps fail to build (e.g. =aic94xx-firmware=), but the codes are accurate now. If the underlying sub-dep failures stay noisy, that's a separate concern — open a new task. *** 2026-05-16 Sat @ 09:00:41 -0500 AI Response: Surfaced the expanded AUR-exit-0 pattern 2026-05-16 07:40 VM run passed (52/0/5) with the same warning profile as the 2026-05-11 18:36 run. Error count went 7 → 13: 5 fixed/unchanged, +5 new AUR-exit-0 entries (broadens the existing tidaler item into the dedicated =[#B]= subtask above), +1 genuinely new error in =setting up emacs configuration files= (=git pull= ran in =~/.emacs.d= which existed from stow but had no =.git=). Patched =archsetup:1932-1945= with a three-branch check: clone if missing/empty, pull if =.git= exists, =git init=/=fetch=/=checkout= in place if the dir came from stow. |