lundukecity-git

Build times (auto-updated)

x86_64: 1m29s (2026-10-10 13:38 UTC, MAKEFLAGS=-j6)

Build times (auto-updated)

x86_64: 2m6s (2026-10-05 22:10 UTC, MAKEFLAGS=-j6)

Category: maintained/, same convention as [[lunduke-edit-git]] and [lunduke-paint-git]. Created 2026-09-28. New AUR submission, not yet pushed to AUR.
Requested pkgname was literally “lundukecity-git” (no hyphen between “lunduke” and “city”), even though upstream’s own meson.build project name is lunduke-city (hyphenated) – kept the requested spelling rather than “fixing” it to match, since the user asked for it explicitly. provides/conflicts use the same unhyphenated lundukecity base name for consistency with the pkgname.
meson + gtkmm-3.0 (gtkmm3 covers it – no extra direct deps unlike lunduke-paint-git, since this package doesn’t link cairomm/gdk-pixbuf2/pugixml/etc directly, only gtkmm_dep + micropolis_dep (bundled, subdir('third_party/micropolis')) + thread_dep). third_party/micropolis and third_party/micropolis-assets are vendored directly in the repo (not git submodules), so a plain non-recursive clone already has everything.
PulseAudio is dlopen’d at runtime (src/sound_player.cpp), not linked – optdepends=('libpulse: sound effects'), no makedepends needed, matches upstream’s own Debian packaging (Recommends: libpulse0 vs Depends:).
License: GPL-3.0-or-later (COPYING is GPLv3, NOTICE confirms “or-later” for both the Micropolis engine and the original gtkmm UI, with additional EA-derived terms on top – kept the license array as a plain SPDX id matching sibling packages’ own convention, same simplification they already made).
Asset path note (not a bug, verified before building): meson.build bakes meson.project_source_root()/third_party/micropolis-assets into the binary via -DLUNDUKE_CITY_ASSET_DIR=..., which is a build-tree path – makepkg flags this at packaging time (WARNING: Package contains reference to $srcdir, harmless, not a build failure). Confirmed in src/assets.cpp this doesn’t break the installed binary: asset_root() tries that macro’s path first, but falls through (via is_asset_root()’s existence check) to an exe-relative candidate (exe_dir() + "/../share/lunduke-city/micropolis-assets") that correctly resolves to /usr/share/lunduke-city/micropolis-assets for an installed /usr/bin/lunduke-city – matches meson.build’s own install_subdir(...) target exactly. An $LUNDUKE_CITY_ASSETS env var override also exists for advanced use. No PKGBUILD workaround needed.
check() runs upstream’s meson test unconditionally (unlike lunduke-paint-git, which has to guard for DISPLAY) – both engine_smoke/features tests are headless (no gtkmm_dep in tests/meson.build), confirmed by reading the test sources before relying on it, not just copying lunduke-paint-git’s pattern blind.
First real build: pkgver()’s placeholder guess (r1.b5272fb, from a shallow --depth 1 probe clone used only to inspect the repo before writing the PKGBUILD) was superseded during the actual build by a full clone’s real git rev-list --count (r14.b5272fb) – expected/normal for a fresh -git package, not a discrepancy to chase.
Built + published cleanly first try, x86_64 only (r14.b5272fb-1,
- debug package). User asked about extending arch=() to match the project’s other supported archs, then said to leave it for now – x86_64-only stays the status quo pending a future session.

2026-10-10: upstream added new UI tests that need a real DISPLAY – fixed with xvfb-run, 2 tests still fail

Rebuild attempt failed in check(): 6 new upstream tests (ui_round3/4/6/7, ui_graphs, argv_open) now explicitly fail (not skip) with “no DISPLAY; this GUI test must fail rather than skip or start its own server” – a deliberate upstream testing-policy change, unlike the headless-safe engine_smoke/ features tests this package’s own memory entry above describes. User approved wrapping check() in xvfb-run (project precedent: python2’s PKGBUILD does the same for its GUI tests) + checkdepends=('xorg-server-xvfb'); pkgrel 1 -> 2.

Result: 4 of the 6 now pass (ui_round3, ui_round6, ui_graphs, production_binary/round7 also passed). 2 still fail, for unrelated reasons – NOT a DISPLAY problem anymore:

argv_open: Lunduke City: map tiles not found (images/micropolisEngine/tiles.png) – a saved city passed on the command line doesn’t load. Looks like a real asset-path issue in the test (or the test’s working-directory assumption), not something xvfb-run can fix.
ui_round7: floods of dconf-WARNING: failed to commit changes to dconf: Error spawning command line "dbus-launch ..." – no D-Bus session bus available in the chroot, which cascades into a real assertion failure (“a graph swatch is not its series color”). dbus-run-session is the usual companion fix to xvfb-run for GTK apps needing a session bus, but there’s no existing precedent for it in this tree and it’s untested here – not applied speculatively.

Not fixed further or published this pass – flagged back to the user rather than guessing twice in the same session. PKGBUILD/.SRCINFO changes (pkgrel 2, xvfb-run, checkdepends) are sitting uncommitted (git tracked, not pushed) pending a decision on the remaining 2 tests.

Resolved same session: user chose to exclude just those 2 tests (meson test --exclude argv_open --exclude ui_round7) rather than chase dbus-run-session or leave it unpublished. Built+published cleanly, r37.933f826-1 (+ debug package), x86_64. pkgrel stays at 2. PKGBUILD change is self-documenting (comment above the --exclude flags explains why each test is skipped) – no further action needed unless upstream fixes either test’s underlying issue later.

Other lunduke-* packages’ arch coverage (checked 2026-09-28, not changed)

Both siblings are also arch=('x86_64') only:

lunduke-edit-git: genuinely constrained, not just untested – its dependency gtksourceviewmm3 (a custom-maintained package pinning the old GTK3-era gtksourceviewmm-3.0 API) is itself x86_64-only, never built for any other arch.
lunduke-paint-git: looks like it was just never tried elsewhere – its deps (gtkmm3 cairomm gdk-pixbuf2 glib2 libarchive pugixml pango) are all standard official Arch packages likely available broadly, no known blocker like the compiler-backend cases (lacc-git/slimcc-git) or the gtksourceviewmm3 case above.