Skip to content

new(x.org/xserver): X.Org X server (Xorg, meson build, supersedes #7474)#13103

Open
tannevaled wants to merge 5 commits into
pkgxdev:mainfrom
tannevaled:new/xorg-server
Open

new(x.org/xserver): X.Org X server (Xorg, meson build, supersedes #7474)#13103
tannevaled wants to merge 5 commits into
pkgxdev:mainfrom
tannevaled:new/xorg-server

Conversation

@tannevaled
Copy link
Copy Markdown
Contributor

Summary

New recipe for x.org/xserver (the X.Org X server, providing bin/Xorg). Modern xserver (>=21.1) is meson-built; drives upstream's meson setup + ninja install flow that arch / nixpkgs / debian all use today.

Supersedes #7474. That WIP (Nov 2024) used the legacy autotools path and hardcoded Debian-multiarch paths like lib/x86_64-linux-gnu/. Upstream removed the autotools layer years ago, so any ./configure $ARGS recipe is no longer fixable in place. Comment on #7474 with details: #7474 (comment)

Trimming vs. arch's PKGBUILD

Disabled (each needs its own pantry dep first):

  • glamor — needs libGL / mesa
  • xephyr / xnest / xvfb — separate nested + headless X servers; can be sibling sub-packages later (matches arch's package_xorg-server-{xephyr,xnest,xvfb} split)
  • libunwind — crash-dump symbolizer, no pantry recipe yet
  • udev / systemd_logind — no systemd in pantry runtime closure
  • xselinux / suid_wrapper — Linux-distro-specific
  • docs — avoid xmlto+xsltproc

Deps

Reuses pantry's existing x.org/* lib surface + pixman.org, xkbcommon.org, github.com/anholt/libepoxy, dri.freedesktop.org (libdrm), sourceforge.net/libtirpc (XDM auth via secure-rpc).

Linux-only (x86-64 + aarch64). macOS Xorg = XQuartz (separate distribution). arch + nixpkgs also linux-only here.

Test plan

  • Xorg -version smoke test prints "X.Org X Server" banner
  • CI green on *nix64 / *nix·ARM64 (no darwin checks — platforms restricted)
  • If meson setup finds a missing dep we don't yet have in pantry, iterate

🤖 Generated with Claude Code

tannevaled and others added 5 commits May 30, 2026 11:01
Modern xserver (>= 21.1.x) is meson-built; this recipe drives the
upstream `meson setup + ninja install` flow that arch / nixpkgs /
debian all use today. Targets the current stable line (21.1.22 as
of May 2026).

Supersedes the 20-month-old WIP at pkgxdev#7474 which used
the legacy autotools path and hardcoded Debian-multiarch paths like
`lib/x86_64-linux-gnu/`. Upstream removed the autotools layer years
ago, so any `./configure $ARGS` recipe is no longer fixable in
place.

Trimming vs. arch's PKGBUILD:

  * glamor disabled — requires libGL / mesa, not yet in pantry.
    Xorg still functions as an unaccelerated 2D server.
  * xephyr / xnest / xvfb disabled — separate nested + headless X
    servers, can be split into sibling sub-packages later if there's
    user demand. Matches arch's package_xorg-server-{xephyr,xnest,xvfb}
    split.
  * libunwind / udev / systemd_logind / xselinux / suid_wrapper all
    disabled — each needs its own pantry recipe first.

Deps used: pixman, xkbcommon, libepoxy, libdrm (dri.freedesktop.org),
libtirpc (for secure-rpc / XDM auth), and the full x.org/* library
surface already in pantry (protocol, x11, xkbfile, libxfont2,
pciaccess, xau, xdmcp, xshmfence, xtrans, libcvt, exts).

Linux-only (x86-64 + aarch64). macOS uses XQuartz (separate
distribution); arch and nixpkgs also restrict to linux for
xorg-server.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
First-iter meson configure failed at meson.build:143 with
  ERROR: Dependency "fontutil" not found (tried pkg-config)
because pantry doesn't yet ship `x.org/font-util` (the tiny m4 +
pkg-config helper from upstream). meson uses it solely to compute
`fontrootdir` and assemble a default FontPath.

When `default_font_path` is non-empty, meson skips the lookup. Set
it to a sensible static prefix-relative list — these dirs don't
need to exist at build time, Xorg just appends them to its runtime
FontPath; admins override via xorg.conf.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Per "if a dep is missing, add it" policy: add `x.org/font-util`
(autotools, tiny — provides mkfontdir/mkfontscale/bdftruncate/ucs2any
plus the `fontutil.pc` pkg-config file that xserver's meson.build
consults for the default FontPath layout).

Replace the previous `-Ddefault_font_path=<hardcoded>` workaround in
the xserver recipe with the real font-util dep. Now `Xorg`'s
FontPath computation uses upstream's intended logic and the bottle
matches what arch / debian / nixpkgs produce.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
First iter's CI failed audit with
    error: missing executables:
      x.org/font-util => mkfontdir
      x.org/font-util => mkfontscale

`mkfontdir` and `mkfontscale` live in upstream's SEPARATE `mkfontscale`
package, not `font-util`. font-util only ships the two BDF-conversion
shell scripts (bdftruncate, ucs2any) + the fontutil.m4 autotools
macros + fontutil.pc.

Sibling xserver build in this same PR (pkgxdev#13103) also failed because
the font-util bottle doesn't exist yet (not previously bottled in
pantry CI). Per brewkit's resolver, downstream consumers can't be
built within the same PR — needs the sibling to merge + bottle first.
Will likely need to split this PR.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
font-util's `make install` writes `fontutil.pc` to `lib/pkgconfig/`
by default (autotools' libdir-relative location). My initial test
only looked at `share/pkgconfig/`, which is where some distros
post-install relocate it. Accept either.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@tannevaled
Copy link
Copy Markdown
Contributor Author

Extracted x.org/font-util to its own PR: #13106. Reason: pkgx CI's resolver 404s when xserver tries to resolve a same-PR sibling dep, even though font-util's own build is green. Once #13106 merges and the font-util bottle publishes to dist.pkgx.dev, the xserver iteration here will succeed on the next CI re-run. Leaving this PR open with both recipes for now; happy to remove the font-util copy from this PR's diff once #13106 is in if that's preferred.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant