# Introductions - Who are you, and what are you building with UNA? **URL:** \ **Category:** Getting Started\ **Created:** [August 20, 2026, 10:21am UTC](https://dev.unawatch.com/t/introductions-who-are-you-and-what-are-you-building-with-una/9 "2026-08-20T10:21:59Z")\ **Posts on this page:** 1\ **Showing post:** 16
**Author:** ![smokey\_foss](https://avatars.discourse-cdn.com/v4/letter/s/6a8cbe/32.png) [@smokey\_foss](https://dev.unawatch.com/u/smokey_foss)\ **Post date:** [August 23, 2026, 2:33am UTC](https://dev.unawatch.com/t/introductions-who-are-you-and-what-are-you-building-with-una/9/16 "2026-08-23T02:33:53Z")
Late to this thread, but your Linux work is the reason I have anything running at all, so _thank you_, and I would like to offer something back. My machine is ARM64 (WSL2 on Windows on ARM), which the Linux path does not quite reach. The vendored TouchGFX Linux libraries are x86-64 only and the framework core ships as binary objects, so there is no native build. I ended up running the simulator and the ARM firmware build in amd64 Docker containers under QEMU. It works, and the emulated build of Waypoint came out byte identical to UNA’s CI artifact apart from the version field and CRC, but it is slow, and two things bite: - QEMU cannot run x86-64 Ruby, so `textconvert` and `videoconvert` die. Since every project commits its `generated/` output, a guarded shim that asserts the committed files exist gets past it, at the cost of not being able to regenerate text or fonts locally at all. - The same QEMU issue breaks `python3-full`’s postinst, which is why I install just `python3-pip` rather than following `apps-ci.yml` exactly. Which brings me to the offer. I noticed your `fix(cmake): make builds independent of where the SDK and app are checked out` and the CI job asserting an app builds identically from two directories. I kept my app outside the SDK checkout and can confirm the CMake side holds up: it built first time with no path changes. The simulator side is still fixed depth, though, and I had to patch each of these by hand: 1. `config/gcc/app.mk`, where `touchgfx_path` goes six levels up 2. `config/msvs/Application.props`, where `TouchGFXReleasePath` goes eight levels up 3. the mock filesystem sandbox, five levels up plus `/Output`, which silently sends `AppConfig` to the wrong directory and falls back to defaults 4. `simulator/gcc/Makefile` and the `.vcxproj` do not glob, so a new `.cpp` links fine as firmware and fails only in the simulator I would be glad to put a PR together extending your two directory CI assertion to the simulator build, if that is a direction you think would be accepted. I could also add a short note to `Simulator.md` along the lines of “ARM64 hosts: use the Windows simulator or an amd64 container, and here is why”. The first symptom is a thoroughly misleading `imageconvert.out: 1: Syntax error: "(" unexpected`, which is really `ENOEXEC`, and it cost me a while to work out. One question, since you have built one of everything: have you run into `std::localtime()` returning UTC? I have [posted about it separately](https://dev.unawatch.com/t/how-should-an-app-get-the-wearers-local-time/41). And I am curious about the Rust GUI PoC. For me TouchGFX is not only an authoring barrier, it is the specific reason I cannot build natively at all. A non TouchGFX GUI path would turn my emulated loop into a native one, so I would be interested in how far you got. --- _[View the full topic](https://dev.unawatch.com/t/introductions-who-are-you-and-what-are-you-building-with-una/9)._