Conversation
Stage 2 of run 35075286983 died at ninja edge 2077 with ninja: job failed with status 1: python3 ../../third_party/dawn/tools/generate-sources-gn.py gen failed to initialize build cache at /home/pmos/.cache/go-build: mkdir /home/pmos/.cache/go-build: file exists That path is a symlink pmbootstrap makes to /mnt/pmbootstrap/go/gocache, a directory inside the cache_go bind mount. Both the symlink and the directory are created by pmb.chroot.init(), but only on the way that creates the chroot: for one that exists it mounts and returns. chromium-state.sh stores the prep layer with --exclude='./cache_*/*', so the cache directories are restored empty and gocache is not restored at all. Every stage that re-enters the work directory therefore has a dangling /home/pmos/.cache/go-build, and Go's os.MkdirAll() on a dangling symlink returns EEXIST: stat() fails, mkdir() then hits the symlink. Go prints "not a directory" for a regular file and succeeds on a missing one, so this message only ever means the symlink. The three cargo directories under cache_rust are missing for the same reason. Stage 1 was not spared, it just stopped at edge 1206 before any Go action ran. Recreate the missing targets in enter(), after pmb.chroot.init(), which is where this script already redoes what run_abuild() sets up. Only the missing ones: a target that is there but wrong keeps failing where it is used, instead of being quietly replaced here. The caches stay out of the stored state: ninja records a finished Go action in .ninja_log, so no later stage reruns it, and a build cache that is only used within one stage is not worth 2 GB of release assets. Assisted-by: Claude
Not observed yet: only the package stage writes to $WORK/packages, and no run has reached it. run_abuild() chowns $WORK/packages to the chroot's build user (12345), but only on the branch that creates the directory. In a restored work directory it exists, and it belongs to the runner's uid: the prep container's exit trap in run-pmbootstrap.sh hands /work/packages back to HOST_UID so the runner can read it, and that is the owner the prep layer was tarred with and restores to. abuild runs as pmos and would get EACCES writing the apk into $REPODEST/pmos/aarch64, after however many hours the package stage spent on check. Do what run_abuild() does, in enter(), where this script already redoes its setup. The container's exit trap still hands the directory back to the runner for the upload step. Assisted-by: Claude
Symbolic icons from the on-disk Adwaita theme drew as solid white quads in a GTK4 header on this device, while icons compiled into GTK itself rendered fine -- which looks like a broken icon theme and is not one. It is the renderer. Measured on one binary in one session: six consecutive captures under GSK_RENDERER=gl were byte-identical squares, and both ngl and cairo drew the icons correctly. Every icon name resolved on disk, so nothing was missing. This is not the a5xx S-order GMEM corruption either. That one flickers frame to frame, and its fix is installed here -- mesa 26.2.2-r51, mapped by both phoc and the app. The gl pin dated from a comment reading "the default ngl/vulkan renderer path is not what this device wants", which conflated two things: Turnip rejecting a5xx is a Vulkan problem, handled by the VK_LOADER_DRIVERS_DISABLE line right below, and ngl does not use Vulkan. No measurement was ever recorded for preferring gl. ngl is what postmarketOS ships as its general Adreno + GTK4 workaround. Assisted-by: Claude
Jertlok
marked this pull request as draft
September 16, 2026 13:15
Jertlok
added a commit
that referenced
this pull request
Sep 20, 2026
…shim The fork sat at 50.4-r53 while Alpine moved to 51.0, so apk took stock 51.0-r0 and this port lost both patches it carries: the NFC privacy page and users-offer-fingerprint-login-without-gdm. Same mechanism as mesa -- pkgver is compared before pkgrel -- and `apk policy` on the device showed it plainly. The cost of that was not theoretical. The fingerprint row's absence was diagnosed from scratch this session, down to reading cc-user-page.c and discovering that gnome-control-center gates the row on GDM's org.gnome.login-screen schema. That is exactly what the missing patch had already fixed, on 2026-09-13. An evening went into re-deriving a fix that was already written and had silently stopped being installed. Both patches needed rebasing; 51.0 moved under them. users-offer-fingerprint-login-without-gdm: 51.0 rewrote the condition, dropping the act_user_is_local_account() term and reflowing the expression. Rewritten against the new text, same intent -- defer to GDM's setting when it exists, treat its absence as no policy against. privacy-add-an-nfc-page: the new files applied untouched; only the wiring into the privacy panel drifted. 51.0 reindented cc-privacy-panel.c to four spaces and reflowed cc-privacy-panel.blp, so three hunks were rebuilt against the real text. The struct hunk was then cut to minimal context after two attempts at guessing its line number failed -- minimal context matches where a hand-counted @@ header does not. Verified on the device: gnome-control-center-51.0-r54 installed, the binary carries the cc_fprintd_* symbols and the NFC page, and both apply with no rejects. taimen-login-screen.gschema.xml is deleted in the same change. It was written earlier tonight to declare the GDM schema ourselves, which made the row appear -- but it is a workaround for a fix this fork already had, and shipping both leaves two mechanisms for one problem. The patch is the better one: it keeps deferring to GDM where GDM exists, rather than declaring a schema we do not own. Verified that `gsettings list-schemas` no longer lists org.gnome.login-screen after r64. device-google-taimen r64, and taimen-gsk.conf takes the ngl renderer from PR #20 with the measurement recorded beside it: gl 31.0/31.6/31.5 against ngl 31.9/31.8/31.9, interleaved, on both mesa builds. No difference outside noise, and both figures are the probe's own paint cost rather than the session's rate (a no-damage control on the same clock reached 59 fps). It is the white symbolic icons that justify the switch, not frames. Assisted-by: Claude
Contributor
Author
|
The renderer half of this landed on Measured 2026-09-20, interleaved A/B with No difference outside noise, so this PR's framing is right: it is a One caveat worth carrying forward: both figures above are the PROBE's own What is still open here is the |
Jertlok
added a commit
that referenced
this pull request
Sep 20, 2026
…shim The fork sat at 50.4-r53 while Alpine moved to 51.0, so apk took stock 51.0-r0 and this port lost both patches it carries: the NFC privacy page and users-offer-fingerprint-login-without-gdm. Same mechanism as mesa -- pkgver is compared before pkgrel -- and `apk policy` on the device showed it plainly. The cost of that was not theoretical. The fingerprint row's absence was diagnosed from scratch this session, down to reading cc-user-page.c and discovering that gnome-control-center gates the row on GDM's org.gnome.login-screen schema. That is exactly what the missing patch had already fixed, on 2026-09-13. An evening went into re-deriving a fix that was already written and had silently stopped being installed. Both patches needed rebasing; 51.0 moved under them. users-offer-fingerprint-login-without-gdm: 51.0 rewrote the condition, dropping the act_user_is_local_account() term and reflowing the expression. Rewritten against the new text, same intent -- defer to GDM's setting when it exists, treat its absence as no policy against. privacy-add-an-nfc-page: the new files applied untouched; only the wiring into the privacy panel drifted. 51.0 reindented cc-privacy-panel.c to four spaces and reflowed cc-privacy-panel.blp, so three hunks were rebuilt against the real text. The struct hunk was then cut to minimal context after two attempts at guessing its line number failed -- minimal context matches where a hand-counted @@ header does not. Verified on the device: gnome-control-center-51.0-r54 installed, the binary carries the cc_fprintd_* symbols and the NFC page, and both apply with no rejects. taimen-login-screen.gschema.xml is deleted in the same change. It was written earlier tonight to declare the GDM schema ourselves, which made the row appear -- but it is a workaround for a fix this fork already had, and shipping both leaves two mechanisms for one problem. The patch is the better one: it keeps deferring to GDM where GDM exists, rather than declaring a schema we do not own. Verified that `gsettings list-schemas` no longer lists org.gnome.login-screen after r64. device-google-taimen r64, and taimen-gsk.conf takes the ngl renderer from PR #20 with the measurement recorded beside it: gl 31.0/31.6/31.5 against ngl 31.9/31.8/31.9, interleaved, on both mesa builds. No difference outside noise, and both figures are the probe's own paint cost rather than the session's rate (a no-damage control on the same clock reached 59 fps). It is the white symbolic icons that justify the switch, not frames. Assisted-by: Claude Signed-off-by: Giuseppe Maggio <jertlok@proton.me>
Jertlok
added a commit
that referenced
this pull request
Sep 20, 2026
…shim The fork sat at 50.4-r53 while Alpine moved to 51.0, so apk took stock 51.0-r0 and this port lost both patches it carries: the NFC privacy page and users-offer-fingerprint-login-without-gdm. Same mechanism as mesa -- pkgver is compared before pkgrel -- and `apk policy` on the device showed it plainly. The cost of that was not theoretical. The fingerprint row's absence was diagnosed from scratch this session, down to reading cc-user-page.c and discovering that gnome-control-center gates the row on GDM's org.gnome.login-screen schema. That is exactly what the missing patch had already fixed, on 2026-09-13. An evening went into re-deriving a fix that was already written and had silently stopped being installed. Both patches needed rebasing; 51.0 moved under them. users-offer-fingerprint-login-without-gdm: 51.0 rewrote the condition, dropping the act_user_is_local_account() term and reflowing the expression. Rewritten against the new text, same intent -- defer to GDM's setting when it exists, treat its absence as no policy against. privacy-add-an-nfc-page: the new files applied untouched; only the wiring into the privacy panel drifted. 51.0 reindented cc-privacy-panel.c to four spaces and reflowed cc-privacy-panel.blp, so three hunks were rebuilt against the real text. The struct hunk was then cut to minimal context after two attempts at guessing its line number failed -- minimal context matches where a hand-counted @@ header does not. Verified on the device: gnome-control-center-51.0-r54 installed, the binary carries the cc_fprintd_* symbols and the NFC page, and both apply with no rejects. taimen-login-screen.gschema.xml is deleted in the same change. It was written earlier tonight to declare the GDM schema ourselves, which made the row appear -- but it is a workaround for a fix this fork already had, and shipping both leaves two mechanisms for one problem. The patch is the better one: it keeps deferring to GDM where GDM exists, rather than declaring a schema we do not own. Verified that `gsettings list-schemas` no longer lists org.gnome.login-screen after r64. device-google-taimen r64, and taimen-gsk.conf takes the ngl renderer from PR #20 with the measurement recorded beside it: gl 31.0/31.6/31.5 against ngl 31.9/31.8/31.9, interleaved, on both mesa builds. No difference outside noise, and both figures are the probe's own paint cost rather than the session's rate (a no-damage control on the same clock reached 59 fps). It is the white symbolic icons that justify the switch, not frames. Assisted-by: Claude Signed-off-by: Giuseppe Maggio <jertlok@proton.me>
Assisted-by: Codex
Assisted-by: Codex
Assisted-by: Codex
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Symbolic icons from the on-disk Adwaita theme drew as solid white quads in a GTK4 header on this device, while icons compiled into GTK itself rendered fine — which looks like a broken icon theme and is not one.
It is the renderer. Measured on one binary in one session: six consecutive captures under
GSK_RENDERER=glwere byte-identical squares, and bothnglandcairodrew the icons correctly. Every icon name resolved on disk, so nothing was missing.It is also not the a5xx S-order GMEM corruption. That one flickers frame to frame, and its fix is installed here — mesa 26.2.2-r51, mapped by both phoc and the app. Stable squares are not that bug.
The
glpin dated from a comment reading "the default ngl/vulkan renderer path is not what this device wants", which conflated two things: Turnip rejecting a5xx is a Vulkan problem, handled by theVK_LOADER_DRIVERS_DISABLEline directly below it, andngldoes not use Vulkan at all. No measurement was ever recorded for preferringgl, andnglis what postmarketOS ships as its general Adreno + GTK4 workaround.Sign-off is yours to add before merge.