fix: X11 forwarding entrypoint; allow empty rolling_tag in macos workflow - #10
Merged
Conversation
Two bugs in the X11-forwarding path:
- The entrypoint took the caller's $DISPLAY (e.g. host.docker.internal:0
for XQuartz) and tried to start Xvfb on it. Xvfb only binds local
display numbers, so it failed immediately and the loop printed
"ERROR: Xvfb exited unexpectedly!" on every X11-forwarded run.
- The Wine priming step ran with that same caller-supplied DISPLAY,
meaning Wine's first-run service init talked to the real host X
server in a half-initialised state — exactly the case the comment
in the file warned against ("services try to create windows and
block forever"). The visible symptom: the first `ltspice` invocation
in the resulting shell failed and only the second succeeded.
Pin the prime step to DISPLAY=:99 (Xvfb hasn't started yet, so the
connection fails fast and Wine init completes cleanly). Then branch:
if the caller supplied DISPLAY, use it as-is and skip Xvfb entirely;
otherwise start the private Xvfb on :99 as before.
Drops the now-stale "first-run Xvfb failure" note from README; the
underlying race is gone.
Default stays "macos-latest" so existing behavior is unchanged. Setting rolling_tag to an empty string in the workflow_dispatch form now skips the rolling pointer push and only publishes the immutable devel-YYYYMMDD-wine-X.Y tag — useful for trial builds that should not move macos-latest.
aanas-sayed
changed the title
The previous commit's entrypoint logic checked
USER_DISPLAY="${DISPLAY:-}"
if [ -n "$USER_DISPLAY" ]; then ... skip Xvfb ...
to decide whether the caller had set DISPLAY (X11 forwarding) or not.
But the Dockerfile baked DISPLAY=:99 into ENV, so $DISPLAY was
*always* non-empty inside the container even when the caller passed
nothing. The entrypoint mistook the image default for a caller value
and skipped Xvfb on every run — Wine then had no X server to talk to
and the simulation produced a perm-denied / no-log failure (visible
in the macos-latest workflow run as "Using caller-provided
DISPLAY=:99 (skipping Xvfb)").
Drop DISPLAY from ENV; set it inline only on the build-time wine
commands that actually need it. Now an unset DISPLAY at runtime
correctly means "headless, start Xvfb."
GitHub's workflow_dispatch UI substitutes the configured default back in when a string field is left blank, so the previous "leave rolling_tag empty to skip" mechanism never actually skipped — every run still pushed macos-latest. Replace with a publish_rolling boolean input (defaults to true so the common case is unchanged); rolling_tag is only consulted when the toggle is true.
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.
Summary
Two unrelated-but-small changes bundled into one PR.
1. X11 forwarding entrypoint fix
Two bugs surfaced when running with
-e DISPLAY=host.docker.internal:0(XQuartz on macOS):\$DISPLAYand trying to start Xvfb on it. Xvfb only binds local display numbers, so it failed immediately — source of theERROR: Xvfb exited unexpectedly!line on every X11-forwarded run.DISPLAY, so Wine's first-run service init talked to the real host X server in a half-initialised state. That's why the firstltspiceinvocation in the resulting shell failed and only the second succeeded.Fix:
DISPLAY=:99(Xvfb isn't running yet → connection fails fast → Wine init completes cleanly).:99as before.2. macos-latest workflow: optional rolling tag
Publish macos-latest (Wine 9)now accepts an emptyrolling_taginput. Default staysmacos-latestso existing behavior is unchanged; setting the input to an empty string publishes only the immutabledevel-YYYYMMDD-wine-X.Ytag and leavesmacos-latestpointing at whatever it was before. Useful for trial builds that should not move the rolling pointer.Test plan
test.sh(no callerDISPLAY) — Xvfb path unchanged, CI greendocker run -it -e DISPLAY=host.docker.internal:0 -v /tmp/.X11-unix:/tmp/.X11-unix aanas0sayed/docker-ltspice:macos-latest— no Xvfb error in entrypoint output,ltspiceopens GUI on first invocationrolling_tag— confirm only the dated devel tag appears on Docker Hubrolling_tag— confirm both tags appear (regression check)