Repository navigation
mesa-m3: catch Bash append overrides during system handoff - #213
chriskearney wants to merge 1 commit into
Conversation
Bash accepts NAME+=VALUE in POSIX mode, but the scanner only recognizes NAME=VALUE. A late uwsm export such as LIBGL_ALWAYS_SOFTWARE+=1 therefore passes the system-provider check before selecting software rendering. Report tracked append assignments as unknown in system-provider mode, keeping the software recovery path. Leave the default legacy scanner unchanged. Exercise Bash's actual result and the complete handoff under both shells, and bump the package release with its updated checksum. Generated-by: LLM Signed-off-by: Chris Kearney <303316+chriskearney@users.noreply.github.com>
|
Native package validation completed for
No GPU, package installation, compositor restart or fresh M3 login was performed for this change. This tightens the scanner’s admission decision; it does not qualify the general native-Mesa image/login handoff. That physical check remains pending. No kernel, firmware, boot or CODEOWNERS change. |
[Medium impact] The PR appears safe to merge; no actionable issues were found. SummaryIn
Reviews (1) · Last reviewed commit: "mesa-m3: refuse unresolved Bash append o..." · Reviewed by Greptile |
|
@chriskearney could you review this when you get a chance? #232 is stacked on it and adds the other half you listed: the 15-inch Air (J615) in both the hook and How #232 behaves:
Tests (Arch ARM container, sh and bash): session env 280, system provider 31, board parser 28, user-setup 51, uwsm 7, udev 5, confirm 9. Checksums match 24/24. The review debate with GPT 6 Astra converged after three fixes. No hardware login yet. |
maralcbr
left a comment
There was a problem hiding this comment.
@chriskearney the fix is right. With --system-provider, a tracked NAME+=VALUE word now comes back as (name, None) (mesa-m3-user-setup:206-212). judge() already records a None value as an unsure finding (:356-358), so a late LIBGL_ALWAYS_SOFTWARE+=1 or LD_LIBRARY_PATH+=... in uwsm env no longer looks clean, and the hook keeps the software fallback. The name in names filter at :542 drops untracked appends, so MY_TOOLS_PATH+= stays clean. The legacy parser is unchanged. I also like that the test runs Bash in POSIX mode, which proves both assignments really take effect.
Not blocking:
- The scanner still misses an append split across a line continuation. Bash takes it:
export LIBGL_ALWAYS_SOFTWARE+\ =1check_envfile()splits on physical lines (:527), and the trailing backslash is dropped (:156-160), so neither line matches. That gap was already there for plainNAME=assignments. If you want to close it, join continuation lines before splitting. - The scanner now also refuses a few things that don't really append: an
echo LIBGL_ALWAYS_SOFTWARE+=1word, or a+=line inenvironment.d, which doesn't support appends. Both end on the software fallback, which seems the right trade for system admission. I'm calling it out only so it's a conscious choice.
Approving the code. As you said, this is outside the 4.5 rc scope, so I'd land it after the rc cut together with the stacked #232.
A late uwsm line such as
export LIBGL_ALWAYS_SOFTWARE+=1passes the merged #211 scanner asuser_setup=none, but Bash accepts it even in POSIX mode and enables software rendering.LD_LIBRARY_PATH+=/another/provideris missed the same way. The clean-environment probe can therefore pass before the desktop gets a different setting.In
--system-providermode, report tracked Bash append assignments as unknown and keep the existing software fallback. The default legacy parser is unchanged, and unrelated appends remain allowed. Bumpmesa-m3to26.1.4.m3.2-8and refresh its detector checksum.Validation at
5a4d693:shand Bash; the new late-append cases refuse before the native helper runs.git diff --checkpass.Follow-up to #211, based on integration including #212. The exact
-8recipe built successfully in a native aarch64 VM, including its existing shader/compiler and package checks. Artifact SHA256:c8018060cc29a5acc180bfc639f7c0c43ff4ba5607ac2656b0ec61c25ddf6d4a; extracted detector matches this source. No hardware, kernel, firmware, boot or CODEOWNERS changes. These host checks do not qualify the pending fresh M3 login/image handoff.