flatpak: stamp the version and arch in the build script, and name the bundle by arch by Ryanmello07 · Pull Request #10 · urnetwork/linux

Ryanmello07 · 2026-08-21T06:20:25Z

Stacked PR — depends on #5, #7 and #9 (metainfo).
Opened against main because a cross-fork PR needs its base branch to exist in
this repo, so the diff below currently includes its parent's changes too.
Review after its parent lands.

Three defects in the Flatpak path. All three only show up in a shipped artifact,
never at build time.

1. Every build reported 0.0.0

The committed manifest carries no -Dapp_version, so meson falls back to its dev
sentinel. That is not cosmetic here: the Flatpak is the only artifact that
installs the AppStream metainfo — packaging/lib/common.sh's
assemble_daemon_root() whitelist excludes usr/share/metainfo, and
make-appimage.sh does not package it either — and that file is what GNOME
Software, KDE Discover and the Flathub page read. A 0.0.0 there is valid
AppStream, so nothing rejects it; it just appears on the store page.

make-flatpak.sh now stamps -Dapp_version into a copy of the manifest
before the build, leaving the developer's working tree untouched, and refuses
to continue if the config-opts anchor it keys off has moved — rather than
silently building an unstamped bundle. It is done in the script rather than in
the release workflow so a local --install and a CI build produce the same
version.

2. No `-Dsdk_arch`

flatpak-builder builds for the machine it runs on, so the value is derived from
uname -m and stamped alongside the version. Overridable with ARCH= for the
rare cross case, with an explicit error on an unrecognised machine.

3. Both architectures wrote the same bundle filename

URnetwork-<version>.flatpak carries no arch, so the amd64 and arm64 legs
collide and one silently overwrites the other wherever the artifacts are
collected. The bundle is now URnetwork-<version>-<arch>.flatpak, matching what
every other script in packaging/ already does: the build script names its own
output rather than leaving a workflow to rename it.

Manifest header

Updated to say "go through make-flatpak.sh", and to add the third Flathub
prerequisite alongside the two already documented: Flathub builds this manifest
on its own infrastructure, where make-flatpak.sh never runs, so
-Dapp_version has to be written into config-opts before submission or the
listing shows 0.0.0.

The launcher gains a Flatpak fallback

app/packaging/urnetwork-launcher now falls back to flatpak run com.bringyour.network as its last candidate. Last on purpose: the Flatpak
exports its own desktop entry under the same app id, so on a Flatpak machine this
launcher normally loses on XDG precedence and is never invoked at all. It is
reached only when that export is missing or shadowed — and in exactly that case
the old behaviour was to tell the user to download a GUI they already had
installed.

Verified

bash -n on the script and the launcher (also sh -n, since the launcher is
POSIX sh); the manifest parses as YAML before and after the stamping sed is
applied for real, and the stamped config-opts land in the right module.

Why this is split this way

This is the Flatpak's build plumbing, which is a different review than "what
does the store listing say" (PR 4) or "what is the app id" (PR 2). The launcher
change rides along because it is the same question from the other side — how a
machine that has the Flatpak finds it.

The Android and Apple clients ship under `com.bringyour.network`. Linux was the only platform on a different reverse-DNS id, and every place the id is written down had to be told which one to use. This makes Linux match, and it has to be done in one change because the id is a join key: the GTK application id, the .desktop basename, the AppStream component id, the polkit action namespace, the icon-theme name and the Flatpak app id must all agree or the desktop stops recognising the app. WHAT MOVES, AND WHY IT IS ALL ONE COMMIT main.cpp Gtk::Application::create() -- the GApplication id *.desktop filename, Icon=, StartupWMClass= metainfo.xml filename, <id>, <launchable> polkit .policy filename + all four action ids, matched in ControlProtocol.hpp so the daemon asks about the actions the file actually declares icons hicolor basenames; Flatpak refuses to export an icon whose name is not the app id flatpak manifest filename + id + the desktop-file-edit paths deb/rpm/tarball/ the installed paths, the conffile entries, and the AppImage/snap uninstaller's stale-path list Splitting these would leave an intermediate commit where, for example, the .desktop names an icon that does not exist, or the daemon checks polkit actions the shipped .policy does not declare -- both of which fail silently at runtime rather than at build time. TWO THINGS THAT ARE NOT PURE SEARCH-AND-REPLACE 1. `UrTheme::kAppIconName`. The icon name was spelled as a literal in two places -- the by-path load in UrTheme.cpp and the by-name fallback in MainWindow.cpp. Renaming the packaging alone left both lookups pointing at a file that no longer existed, and `set_from_icon_name()` renders a blank image without raising anything, so the title-bar logo simply went empty. It is now one constant that the packaging and both call sites share. 2. The libsecret keyring attribute in SecretServiceRpcSessionStore.cpp moves with the id. This is deliberately NOT dual-read: an entry written by an older build is no longer found, the app falls back to a fresh RPC session (the same one-time cost as the Flatpak data path moving), and the previous app identity is not left holding live key material in the user's keyring with nothing to clean it up. No behaviour changes beyond those two. `network.ur.urnetwork` no longer appears anywhere in the tree.

Two separate problems with the shipped icon, both visible on a normal desktop. TRANSPARENCY. The old artwork had an opaque background baked in, so the icon rendered as a square tile wherever the shell composites over its own surface -- the GNOME dash, the app grid, and the window's own title bar. The replacements are RGBA with a real alpha channel. SIZES. Only 48 and 256 were installed. The desktop asks for 64 in the app grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the nearest size it has, so those lookups were served an upscale. This installs 48, 64, 128, 256 and 512. All five are downscales of a single 1024x1024 master, taken from the same AppIcon artwork the Apple client ships, so they cannot drift apart the way separately-drawn assets do. The master is committed at packaging/icons/com.bringyour.network-master-1024.png for regenerating them. 512 IS THE CEILING, DELIBERATELY. Installing the 1024 breaks the Flatpak build outright: `flatpak build-export` refuses it with "Image too large (1024x1024). Max. size 512x512" and fails the whole build at export time. Nothing downstream wants a larger one -- Flathub renders the store page at up to 512 -- so the master is kept in the tree but not installed. app/meson.build (the Flatpak's installer) and packaging/lib/common.sh (the staging tree the .deb, .rpm and tarball are all built from) now list the same five sizes, and the tarball uninstaller removes all five; a size installed by one and forgotten by the other is a file left behind on uninstall.

…validate it Three things the AppStream metadata needed before it could be submitted anywhere, and one reason nothing caught them. 1. THE RELEASE VERSION WAS HARDCODED, so it was wrong. Nothing wrote it, so the file said whatever was typed into it last while the pipeline shipped a different version. This element is not decoration: GNOME Software, KDE Discover and the Flathub page all read <release version=...> and show it. The file becomes a configure_file() template. app/meson.build derives both attributes from -Dapp_version, which the pipeline already passes and which both binaries already compile in as UR_APP_VERSION, so there is now exactly one place the release version is written down. The FULL version is stamped, suffix and all. appstreamcli accepts it, and truncating would advertise a version matching no artifact -- every other consumer of $VERSION (both binaries, every package filename, the release-asset gates) uses the whole string -- and would collapse every build of the same UTC day into one indistinguishable release element. Only the date is derived, from the leading <YYYY>.<M>.<D>. When -Dapp_version is not passed, meson warns loudly. That branch cannot be caught any other way: a document saying version="0.0.0" is perfectly valid AppStream, so no validator objects -- it just appears on the store page. 2. NO SCREENSHOT. Flathub requires at least one, and it is the single largest thing a store listing is judged on. Added as a committed PNG plus the raw URL Flathub mirrors from; a repo-relative path does not work, because the mirror step runs on a build host with only the URL. The declared width and height match the file exactly, which Flathub's linter checks. 3. NOTHING VALIDATED THE FILE. That is how (1) survived. appstreamcli is the validator Flathub gates submissions on, so it now runs in two places against the GENERATED file rather than the template: as a meson test (optional -- not every build host has appstreamcli) and as a CI step in the gui job, which is the one that always has it. Verified: `appstreamcli validate --no-net --pedantic` passes on the stamped output for a real release version and for the 0.0.0 sentinel, and the date derivation was exercised for zero-padded and unpadded month/day.

… bundle by arch Three defects in the Flatpak path, all of which only show up in a shipped artifact rather than at build time. 1. THE BUILD REPORTED 0.0.0. The committed manifest carries no -Dapp_version, so meson falls back to its dev sentinel. That is not cosmetic here: the Flatpak is the ONLY artifact that installs the AppStream metainfo (packaging/lib/common.sh's assemble_daemon_root() whitelist excludes usr/share/metainfo, and make-appimage.sh does not package it), and that file is what GNOME Software, KDE Discover and the Flathub page read. A 0.0.0 there is valid AppStream, so nothing rejects it -- it just appears on the store page. The script now stamps -Dapp_version into a COPY of the manifest before the build, leaving the developer's working tree untouched, and refuses to continue if the config-opts anchor it keys off has moved rather than silently building an unstamped bundle. It is done here rather than in the release workflow so that a local `--install` and a CI build produce the same version. 2. NO -Dsdk_arch. flatpak-builder builds for the machine it runs on, so the value is derived from `uname -m` and stamped alongside the version; overridable with ARCH= for the rare cross case. 3. BOTH ARCHITECTURES WROTE THE SAME BUNDLE FILENAME. `URnetwork-<version>.flatpak` carries no arch, so the amd64 and arm64 legs collide and one silently overwrites the other wherever the artifacts are collected. The bundle is now `URnetwork-<version>-<arch>.flatpak`, matching what every other artifact in packaging/ already does: the build script names its own output. Also documents the manifest header accordingly -- go through make-flatpak.sh rather than calling flatpak-builder directly -- and adds the third Flathub prerequisite: Flathub builds the manifest on its own infrastructure where this script never runs, so -Dapp_version has to be written into config-opts before submission or the listing shows 0.0.0. The `urnetwork` launcher script gains the Flatpak as its last fallback. It is last on purpose: the Flatpak exports its own desktop entry under the same app id, so on a Flatpak machine this launcher normally loses on XDG precedence and is never invoked. It is reached only when that export is missing or shadowed -- and in exactly that case the old behaviour was to tell the user to download a GUI they already had installed.

Ryanmello07 · 2026-08-21T06:20:25Z

Stacked PR — depends on #5, #7 and #9 (metainfo).
Opened against main because a cross-fork PR needs its base branch to exist in
this repo, so the diff below currently includes its parent's changes too.
Review after its parent lands.

Three defects in the Flatpak path. All three only show up in a shipped artifact,
never at build time.

1. Every build reported 0.0.0

The committed manifest carries no -Dapp_version, so meson falls back to its dev
sentinel. That is not cosmetic here: the Flatpak is the only artifact that
installs the AppStream metainfo — packaging/lib/common.sh's
assemble_daemon_root() whitelist excludes usr/share/metainfo, and
make-appimage.sh does not package it either — and that file is what GNOME
Software, KDE Discover and the Flathub page read. A 0.0.0 there is valid
AppStream, so nothing rejects it; it just appears on the store page.

make-flatpak.sh now stamps -Dapp_version into a copy of the manifest
before the build, leaving the developer's working tree untouched, and refuses
to continue if the config-opts anchor it keys off has moved — rather than
silently building an unstamped bundle. It is done in the script rather than in
the release workflow so a local --install and a CI build produce the same
version.

2. No `-Dsdk_arch`

flatpak-builder builds for the machine it runs on, so the value is derived from
uname -m and stamped alongside the version. Overridable with ARCH= for the
rare cross case, with an explicit error on an unrecognised machine.

3. Both architectures wrote the same bundle filename

URnetwork-<version>.flatpak carries no arch, so the amd64 and arm64 legs
collide and one silently overwrites the other wherever the artifacts are
collected. The bundle is now URnetwork-<version>-<arch>.flatpak, matching what
every other script in packaging/ already does: the build script names its own
output rather than leaving a workflow to rename it.

Manifest header

Updated to say "go through make-flatpak.sh", and to add the third Flathub
prerequisite alongside the two already documented: Flathub builds this manifest
on its own infrastructure, where make-flatpak.sh never runs, so
-Dapp_version has to be written into config-opts before submission or the
listing shows 0.0.0.

The launcher gains a Flatpak fallback

app/packaging/urnetwork-launcher now falls back to flatpak run com.bringyour.network as its last candidate. Last on purpose: the Flatpak
exports its own desktop entry under the same app id, so on a Flatpak machine this
launcher normally loses on XDG precedence and is never invoked at all. It is
reached only when that export is missing or shadowed — and in exactly that case
the old behaviour was to tell the user to download a GUI they already had
installed.

Verified

bash -n on the script and the launcher (also sh -n, since the launcher is
POSIX sh); the manifest parses as YAML before and after the stamping sed is
applied for real, and the stamped config-opts land in the right module.

Why this is split this way

This is the Flatpak's build plumbing, which is a different review than "what
does the store listing say" (PR 4) or "what is the app id" (PR 2). The launcher
change rides along because it is the same question from the other side — how a
machine that has the Flatpak finds it.

The Android and Apple clients ship under `com.bringyour.network`. Linux was the only platform on a different reverse-DNS id, and every place the id is written down had to be told which one to use. This makes Linux match, and it has to be done in one change because the id is a join key: the GTK application id, the .desktop basename, the AppStream component id, the polkit action namespace, the icon-theme name and the Flatpak app id must all agree or the desktop stops recognising the app. WHAT MOVES, AND WHY IT IS ALL ONE COMMIT main.cpp Gtk::Application::create() -- the GApplication id *.desktop filename, Icon=, StartupWMClass= metainfo.xml filename, <id>, <launchable> polkit .policy filename + all four action ids, matched in ControlProtocol.hpp so the daemon asks about the actions the file actually declares icons hicolor basenames; Flatpak refuses to export an icon whose name is not the app id flatpak manifest filename + id + the desktop-file-edit paths deb/rpm/tarball/ the installed paths, the conffile entries, and the AppImage/snap uninstaller's stale-path list Splitting these would leave an intermediate commit where, for example, the .desktop names an icon that does not exist, or the daemon checks polkit actions the shipped .policy does not declare -- both of which fail silently at runtime rather than at build time. TWO THINGS THAT ARE NOT PURE SEARCH-AND-REPLACE 1. `UrTheme::kAppIconName`. The icon name was spelled as a literal in two places -- the by-path load in UrTheme.cpp and the by-name fallback in MainWindow.cpp. Renaming the packaging alone left both lookups pointing at a file that no longer existed, and `set_from_icon_name()` renders a blank image without raising anything, so the title-bar logo simply went empty. It is now one constant that the packaging and both call sites share. 2. The libsecret keyring attribute in SecretServiceRpcSessionStore.cpp moves with the id. This is deliberately NOT dual-read: an entry written by an older build is no longer found, the app falls back to a fresh RPC session (the same one-time cost as the Flatpak data path moving), and the previous app identity is not left holding live key material in the user's keyring with nothing to clean it up. No behaviour changes beyond those two. `network.ur.urnetwork` no longer appears anywhere in the tree.

Two separate problems with the shipped icon, both visible on a normal desktop. TRANSPARENCY. The old artwork had an opaque background baked in, so the icon rendered as a square tile wherever the shell composites over its own surface -- the GNOME dash, the app grid, and the window's own title bar. The replacements are RGBA with a real alpha channel. SIZES. Only 48 and 256 were installed. The desktop asks for 64 in the app grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the nearest size it has, so those lookups were served an upscale. This installs 48, 64, 128, 256 and 512. All five are downscales of a single 1024x1024 master, taken from the same AppIcon artwork the Apple client ships, so they cannot drift apart the way separately-drawn assets do. The master is committed at packaging/icons/com.bringyour.network-master-1024.png for regenerating them. 512 IS THE CEILING, DELIBERATELY. Installing the 1024 breaks the Flatpak build outright: `flatpak build-export` refuses it with "Image too large (1024x1024). Max. size 512x512" and fails the whole build at export time. Nothing downstream wants a larger one -- Flathub renders the store page at up to 512 -- so the master is kept in the tree but not installed. app/meson.build (the Flatpak's installer) and packaging/lib/common.sh (the staging tree the .deb, .rpm and tarball are all built from) now list the same five sizes, and the tarball uninstaller removes all five; a size installed by one and forgotten by the other is a file left behind on uninstall.

…validate it Three things the AppStream metadata needed before it could be submitted anywhere, and one reason nothing caught them. 1. THE RELEASE VERSION WAS HARDCODED, so it was wrong. Nothing wrote it, so the file said whatever was typed into it last while the pipeline shipped a different version. This element is not decoration: GNOME Software, KDE Discover and the Flathub page all read <release version=...> and show it. The file becomes a configure_file() template. app/meson.build derives both attributes from -Dapp_version, which the pipeline already passes and which both binaries already compile in as UR_APP_VERSION, so there is now exactly one place the release version is written down. The FULL version is stamped, suffix and all. appstreamcli accepts it, and truncating would advertise a version matching no artifact -- every other consumer of $VERSION (both binaries, every package filename, the release-asset gates) uses the whole string -- and would collapse every build of the same UTC day into one indistinguishable release element. Only the date is derived, from the leading <YYYY>.<M>.<D>. When -Dapp_version is not passed, meson warns loudly. That branch cannot be caught any other way: a document saying version="0.0.0" is perfectly valid AppStream, so no validator objects -- it just appears on the store page. 2. NO SCREENSHOT. Flathub requires at least one, and it is the single largest thing a store listing is judged on. Added as a committed PNG plus the raw URL Flathub mirrors from; a repo-relative path does not work, because the mirror step runs on a build host with only the URL. The declared width and height match the file exactly, which Flathub's linter checks. 3. NOTHING VALIDATED THE FILE. That is how (1) survived. appstreamcli is the validator Flathub gates submissions on, so it now runs in two places against the GENERATED file rather than the template: as a meson test (optional -- not every build host has appstreamcli) and as a CI step in the gui job, which is the one that always has it. Verified: `appstreamcli validate --no-net --pedantic` passes on the stamped output for a real release version and for the 0.0.0 sentinel, and the date derivation was exercised for zero-padded and unpadded month/day.

… bundle by arch Three defects in the Flatpak path, all of which only show up in a shipped artifact rather than at build time. 1. THE BUILD REPORTED 0.0.0. The committed manifest carries no -Dapp_version, so meson falls back to its dev sentinel. That is not cosmetic here: the Flatpak is the ONLY artifact that installs the AppStream metainfo (packaging/lib/common.sh's assemble_daemon_root() whitelist excludes usr/share/metainfo, and make-appimage.sh does not package it), and that file is what GNOME Software, KDE Discover and the Flathub page read. A 0.0.0 there is valid AppStream, so nothing rejects it -- it just appears on the store page. The script now stamps -Dapp_version into a COPY of the manifest before the build, leaving the developer's working tree untouched, and refuses to continue if the config-opts anchor it keys off has moved rather than silently building an unstamped bundle. It is done here rather than in the release workflow so that a local `--install` and a CI build produce the same version. 2. NO -Dsdk_arch. flatpak-builder builds for the machine it runs on, so the value is derived from `uname -m` and stamped alongside the version; overridable with ARCH= for the rare cross case. 3. BOTH ARCHITECTURES WROTE THE SAME BUNDLE FILENAME. `URnetwork-<version>.flatpak` carries no arch, so the amd64 and arm64 legs collide and one silently overwrites the other wherever the artifacts are collected. The bundle is now `URnetwork-<version>-<arch>.flatpak`, matching what every other artifact in packaging/ already does: the build script names its own output. Also documents the manifest header accordingly -- go through make-flatpak.sh rather than calling flatpak-builder directly -- and adds the third Flathub prerequisite: Flathub builds the manifest on its own infrastructure where this script never runs, so -Dapp_version has to be written into config-opts before submission or the listing shows 0.0.0. The `urnetwork` launcher script gains the Flatpak as its last fallback. It is last on purpose: the Flatpak exports its own desktop entry under the same app id, so on a Flatpak machine this launcher normally loses on XDG precedence and is never invoked. It is reached only when that export is missing or shadowed -- and in exactly that case the old behaviour was to tell the user to download a GUI they already had installed.

Ryanmello07 · 2026-08-21T06:20:25Z

Stacked PR — depends on #5, #7 and #9 (metainfo).
Opened against main because a cross-fork PR needs its base branch to exist in
this repo, so the diff below currently includes its parent's changes too.
Review after its parent lands.

Three defects in the Flatpak path. All three only show up in a shipped artifact,
never at build time.

1. Every build reported 0.0.0

The committed manifest carries no -Dapp_version, so meson falls back to its dev
sentinel. That is not cosmetic here: the Flatpak is the only artifact that
installs the AppStream metainfo — packaging/lib/common.sh's
assemble_daemon_root() whitelist excludes usr/share/metainfo, and
make-appimage.sh does not package it either — and that file is what GNOME
Software, KDE Discover and the Flathub page read. A 0.0.0 there is valid
AppStream, so nothing rejects it; it just appears on the store page.

make-flatpak.sh now stamps -Dapp_version into a copy of the manifest
before the build, leaving the developer's working tree untouched, and refuses
to continue if the config-opts anchor it keys off has moved — rather than
silently building an unstamped bundle. It is done in the script rather than in
the release workflow so a local --install and a CI build produce the same
version.

2. No `-Dsdk_arch`

flatpak-builder builds for the machine it runs on, so the value is derived from
uname -m and stamped alongside the version. Overridable with ARCH= for the
rare cross case, with an explicit error on an unrecognised machine.

3. Both architectures wrote the same bundle filename

URnetwork-<version>.flatpak carries no arch, so the amd64 and arm64 legs
collide and one silently overwrites the other wherever the artifacts are
collected. The bundle is now URnetwork-<version>-<arch>.flatpak, matching what
every other script in packaging/ already does: the build script names its own
output rather than leaving a workflow to rename it.

Manifest header

Updated to say "go through make-flatpak.sh", and to add the third Flathub
prerequisite alongside the two already documented: Flathub builds this manifest
on its own infrastructure, where make-flatpak.sh never runs, so
-Dapp_version has to be written into config-opts before submission or the
listing shows 0.0.0.

The launcher gains a Flatpak fallback

app/packaging/urnetwork-launcher now falls back to flatpak run com.bringyour.network as its last candidate. Last on purpose: the Flatpak
exports its own desktop entry under the same app id, so on a Flatpak machine this
launcher normally loses on XDG precedence and is never invoked at all. It is
reached only when that export is missing or shadowed — and in exactly that case
the old behaviour was to tell the user to download a GUI they already had
installed.

Verified

bash -n on the script and the launcher (also sh -n, since the launcher is
POSIX sh); the manifest parses as YAML before and after the stamping sed is
applied for real, and the stamped config-opts land in the right module.

Why this is split this way

This is the Flatpak's build plumbing, which is a different review than "what
does the store listing say" (PR 4) or "what is the app id" (PR 2). The launcher
change rides along because it is the same question from the other side — how a
machine that has the Flatpak finds it.

The Android and Apple clients ship under `com.bringyour.network`. Linux was the only platform on a different reverse-DNS id, and every place the id is written down had to be told which one to use. This makes Linux match, and it has to be done in one change because the id is a join key: the GTK application id, the .desktop basename, the AppStream component id, the polkit action namespace, the icon-theme name and the Flatpak app id must all agree or the desktop stops recognising the app. WHAT MOVES, AND WHY IT IS ALL ONE COMMIT main.cpp Gtk::Application::create() -- the GApplication id *.desktop filename, Icon=, StartupWMClass= metainfo.xml filename, <id>, <launchable> polkit .policy filename + all four action ids, matched in ControlProtocol.hpp so the daemon asks about the actions the file actually declares icons hicolor basenames; Flatpak refuses to export an icon whose name is not the app id flatpak manifest filename + id + the desktop-file-edit paths deb/rpm/tarball/ the installed paths, the conffile entries, and the AppImage/snap uninstaller's stale-path list Splitting these would leave an intermediate commit where, for example, the .desktop names an icon that does not exist, or the daemon checks polkit actions the shipped .policy does not declare -- both of which fail silently at runtime rather than at build time. TWO THINGS THAT ARE NOT PURE SEARCH-AND-REPLACE 1. `UrTheme::kAppIconName`. The icon name was spelled as a literal in two places -- the by-path load in UrTheme.cpp and the by-name fallback in MainWindow.cpp. Renaming the packaging alone left both lookups pointing at a file that no longer existed, and `set_from_icon_name()` renders a blank image without raising anything, so the title-bar logo simply went empty. It is now one constant that the packaging and both call sites share. 2. The libsecret keyring attribute in SecretServiceRpcSessionStore.cpp moves with the id. This is deliberately NOT dual-read: an entry written by an older build is no longer found, the app falls back to a fresh RPC session (the same one-time cost as the Flatpak data path moving), and the previous app identity is not left holding live key material in the user's keyring with nothing to clean it up. No behaviour changes beyond those two. `network.ur.urnetwork` no longer appears anywhere in the tree.

Two separate problems with the shipped icon, both visible on a normal desktop. TRANSPARENCY. The old artwork had an opaque background baked in, so the icon rendered as a square tile wherever the shell composites over its own surface -- the GNOME dash, the app grid, and the window's own title bar. The replacements are RGBA with a real alpha channel. SIZES. Only 48 and 256 were installed. The desktop asks for 64 in the app grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the nearest size it has, so those lookups were served an upscale. This installs 48, 64, 128, 256 and 512. All five are downscales of a single 1024x1024 master, taken from the same AppIcon artwork the Apple client ships, so they cannot drift apart the way separately-drawn assets do. The master is committed at packaging/icons/com.bringyour.network-master-1024.png for regenerating them. 512 IS THE CEILING, DELIBERATELY. Installing the 1024 breaks the Flatpak build outright: `flatpak build-export` refuses it with "Image too large (1024x1024). Max. size 512x512" and fails the whole build at export time. Nothing downstream wants a larger one -- Flathub renders the store page at up to 512 -- so the master is kept in the tree but not installed. app/meson.build (the Flatpak's installer) and packaging/lib/common.sh (the staging tree the .deb, .rpm and tarball are all built from) now list the same five sizes, and the tarball uninstaller removes all five; a size installed by one and forgotten by the other is a file left behind on uninstall.

…validate it Three things the AppStream metadata needed before it could be submitted anywhere, and one reason nothing caught them. 1. THE RELEASE VERSION WAS HARDCODED, so it was wrong. Nothing wrote it, so the file said whatever was typed into it last while the pipeline shipped a different version. This element is not decoration: GNOME Software, KDE Discover and the Flathub page all read <release version=...> and show it. The file becomes a configure_file() template. app/meson.build derives both attributes from -Dapp_version, which the pipeline already passes and which both binaries already compile in as UR_APP_VERSION, so there is now exactly one place the release version is written down. The FULL version is stamped, suffix and all. appstreamcli accepts it, and truncating would advertise a version matching no artifact -- every other consumer of $VERSION (both binaries, every package filename, the release-asset gates) uses the whole string -- and would collapse every build of the same UTC day into one indistinguishable release element. Only the date is derived, from the leading <YYYY>.<M>.<D>. When -Dapp_version is not passed, meson warns loudly. That branch cannot be caught any other way: a document saying version="0.0.0" is perfectly valid AppStream, so no validator objects -- it just appears on the store page. 2. NO SCREENSHOT. Flathub requires at least one, and it is the single largest thing a store listing is judged on. Added as a committed PNG plus the raw URL Flathub mirrors from; a repo-relative path does not work, because the mirror step runs on a build host with only the URL. The declared width and height match the file exactly, which Flathub's linter checks. 3. NOTHING VALIDATED THE FILE. That is how (1) survived. appstreamcli is the validator Flathub gates submissions on, so it now runs in two places against the GENERATED file rather than the template: as a meson test (optional -- not every build host has appstreamcli) and as a CI step in the gui job, which is the one that always has it. Verified: `appstreamcli validate --no-net --pedantic` passes on the stamped output for a real release version and for the 0.0.0 sentinel, and the date derivation was exercised for zero-padded and unpadded month/day.

… bundle by arch Three defects in the Flatpak path, all of which only show up in a shipped artifact rather than at build time. 1. THE BUILD REPORTED 0.0.0. The committed manifest carries no -Dapp_version, so meson falls back to its dev sentinel. That is not cosmetic here: the Flatpak is the ONLY artifact that installs the AppStream metainfo (packaging/lib/common.sh's assemble_daemon_root() whitelist excludes usr/share/metainfo, and make-appimage.sh does not package it), and that file is what GNOME Software, KDE Discover and the Flathub page read. A 0.0.0 there is valid AppStream, so nothing rejects it -- it just appears on the store page. The script now stamps -Dapp_version into a COPY of the manifest before the build, leaving the developer's working tree untouched, and refuses to continue if the config-opts anchor it keys off has moved rather than silently building an unstamped bundle. It is done here rather than in the release workflow so that a local `--install` and a CI build produce the same version. 2. NO -Dsdk_arch. flatpak-builder builds for the machine it runs on, so the value is derived from `uname -m` and stamped alongside the version; overridable with ARCH= for the rare cross case. 3. BOTH ARCHITECTURES WROTE THE SAME BUNDLE FILENAME. `URnetwork-<version>.flatpak` carries no arch, so the amd64 and arm64 legs collide and one silently overwrites the other wherever the artifacts are collected. The bundle is now `URnetwork-<version>-<arch>.flatpak`, matching what every other artifact in packaging/ already does: the build script names its own output. Also documents the manifest header accordingly -- go through make-flatpak.sh rather than calling flatpak-builder directly -- and adds the third Flathub prerequisite: Flathub builds the manifest on its own infrastructure where this script never runs, so -Dapp_version has to be written into config-opts before submission or the listing shows 0.0.0. The `urnetwork` launcher script gains the Flatpak as its last fallback. It is last on purpose: the Flatpak exports its own desktop entry under the same app id, so on a Flatpak machine this launcher normally loses on XDG precedence and is never invoked. It is reached only when that export is missing or shadowed -- and in exactly that case the old behaviour was to tell the user to download a GUI they already had installed.

Ryanmello07 · 2026-08-21T06:20:25Z

Stacked PR — depends on #5, #7 and #9 (metainfo).
Opened against main because a cross-fork PR needs its base branch to exist in
this repo, so the diff below currently includes its parent's changes too.
Review after its parent lands.

Three defects in the Flatpak path. All three only show up in a shipped artifact,
never at build time.

1. Every build reported 0.0.0

The committed manifest carries no -Dapp_version, so meson falls back to its dev
sentinel. That is not cosmetic here: the Flatpak is the only artifact that
installs the AppStream metainfo — packaging/lib/common.sh's
assemble_daemon_root() whitelist excludes usr/share/metainfo, and
make-appimage.sh does not package it either — and that file is what GNOME
Software, KDE Discover and the Flathub page read. A 0.0.0 there is valid
AppStream, so nothing rejects it; it just appears on the store page.

make-flatpak.sh now stamps -Dapp_version into a copy of the manifest
before the build, leaving the developer's working tree untouched, and refuses
to continue if the config-opts anchor it keys off has moved — rather than
silently building an unstamped bundle. It is done in the script rather than in
the release workflow so a local --install and a CI build produce the same
version.

2. No `-Dsdk_arch`

flatpak-builder builds for the machine it runs on, so the value is derived from
uname -m and stamped alongside the version. Overridable with ARCH= for the
rare cross case, with an explicit error on an unrecognised machine.

3. Both architectures wrote the same bundle filename

URnetwork-<version>.flatpak carries no arch, so the amd64 and arm64 legs
collide and one silently overwrites the other wherever the artifacts are
collected. The bundle is now URnetwork-<version>-<arch>.flatpak, matching what
every other script in packaging/ already does: the build script names its own
output rather than leaving a workflow to rename it.

Manifest header

Updated to say "go through make-flatpak.sh", and to add the third Flathub
prerequisite alongside the two already documented: Flathub builds this manifest
on its own infrastructure, where make-flatpak.sh never runs, so
-Dapp_version has to be written into config-opts before submission or the
listing shows 0.0.0.

The launcher gains a Flatpak fallback

app/packaging/urnetwork-launcher now falls back to flatpak run com.bringyour.network as its last candidate. Last on purpose: the Flatpak
exports its own desktop entry under the same app id, so on a Flatpak machine this
launcher normally loses on XDG precedence and is never invoked at all. It is
reached only when that export is missing or shadowed — and in exactly that case
the old behaviour was to tell the user to download a GUI they already had
installed.

Verified

bash -n on the script and the launcher (also sh -n, since the launcher is
POSIX sh); the manifest parses as YAML before and after the stamping sed is
applied for real, and the stamped config-opts land in the right module.

Why this is split this way

This is the Flatpak's build plumbing, which is a different review than "what
does the store listing say" (PR 4) or "what is the app id" (PR 2). The launcher
change rides along because it is the same question from the other side — how a
machine that has the Flatpak finds it.

The Android and Apple clients ship under `com.bringyour.network`. Linux was the only platform on a different reverse-DNS id, and every place the id is written down had to be told which one to use. This makes Linux match, and it has to be done in one change because the id is a join key: the GTK application id, the .desktop basename, the AppStream component id, the polkit action namespace, the icon-theme name and the Flatpak app id must all agree or the desktop stops recognising the app. WHAT MOVES, AND WHY IT IS ALL ONE COMMIT main.cpp Gtk::Application::create() -- the GApplication id *.desktop filename, Icon=, StartupWMClass= metainfo.xml filename, <id>, <launchable> polkit .policy filename + all four action ids, matched in ControlProtocol.hpp so the daemon asks about the actions the file actually declares icons hicolor basenames; Flatpak refuses to export an icon whose name is not the app id flatpak manifest filename + id + the desktop-file-edit paths deb/rpm/tarball/ the installed paths, the conffile entries, and the AppImage/snap uninstaller's stale-path list Splitting these would leave an intermediate commit where, for example, the .desktop names an icon that does not exist, or the daemon checks polkit actions the shipped .policy does not declare -- both of which fail silently at runtime rather than at build time. TWO THINGS THAT ARE NOT PURE SEARCH-AND-REPLACE 1. `UrTheme::kAppIconName`. The icon name was spelled as a literal in two places -- the by-path load in UrTheme.cpp and the by-name fallback in MainWindow.cpp. Renaming the packaging alone left both lookups pointing at a file that no longer existed, and `set_from_icon_name()` renders a blank image without raising anything, so the title-bar logo simply went empty. It is now one constant that the packaging and both call sites share. 2. The libsecret keyring attribute in SecretServiceRpcSessionStore.cpp moves with the id. This is deliberately NOT dual-read: an entry written by an older build is no longer found, the app falls back to a fresh RPC session (the same one-time cost as the Flatpak data path moving), and the previous app identity is not left holding live key material in the user's keyring with nothing to clean it up. No behaviour changes beyond those two. `network.ur.urnetwork` no longer appears anywhere in the tree.

Two separate problems with the shipped icon, both visible on a normal desktop. TRANSPARENCY. The old artwork had an opaque background baked in, so the icon rendered as a square tile wherever the shell composites over its own surface -- the GNOME dash, the app grid, and the window's own title bar. The replacements are RGBA with a real alpha channel. SIZES. Only 48 and 256 were installed. The desktop asks for 64 in the app grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the nearest size it has, so those lookups were served an upscale. This installs 48, 64, 128, 256 and 512. All five are downscales of a single 1024x1024 master, taken from the same AppIcon artwork the Apple client ships, so they cannot drift apart the way separately-drawn assets do. The master is committed at packaging/icons/com.bringyour.network-master-1024.png for regenerating them. 512 IS THE CEILING, DELIBERATELY. Installing the 1024 breaks the Flatpak build outright: `flatpak build-export` refuses it with "Image too large (1024x1024). Max. size 512x512" and fails the whole build at export time. Nothing downstream wants a larger one -- Flathub renders the store page at up to 512 -- so the master is kept in the tree but not installed. app/meson.build (the Flatpak's installer) and packaging/lib/common.sh (the staging tree the .deb, .rpm and tarball are all built from) now list the same five sizes, and the tarball uninstaller removes all five; a size installed by one and forgotten by the other is a file left behind on uninstall.

…validate it Three things the AppStream metadata needed before it could be submitted anywhere, and one reason nothing caught them. 1. THE RELEASE VERSION WAS HARDCODED, so it was wrong. Nothing wrote it, so the file said whatever was typed into it last while the pipeline shipped a different version. This element is not decoration: GNOME Software, KDE Discover and the Flathub page all read <release version=...> and show it. The file becomes a configure_file() template. app/meson.build derives both attributes from -Dapp_version, which the pipeline already passes and which both binaries already compile in as UR_APP_VERSION, so there is now exactly one place the release version is written down. The FULL version is stamped, suffix and all. appstreamcli accepts it, and truncating would advertise a version matching no artifact -- every other consumer of $VERSION (both binaries, every package filename, the release-asset gates) uses the whole string -- and would collapse every build of the same UTC day into one indistinguishable release element. Only the date is derived, from the leading <YYYY>.<M>.<D>. When -Dapp_version is not passed, meson warns loudly. That branch cannot be caught any other way: a document saying version="0.0.0" is perfectly valid AppStream, so no validator objects -- it just appears on the store page. 2. NO SCREENSHOT. Flathub requires at least one, and it is the single largest thing a store listing is judged on. Added as a committed PNG plus the raw URL Flathub mirrors from; a repo-relative path does not work, because the mirror step runs on a build host with only the URL. The declared width and height match the file exactly, which Flathub's linter checks. 3. NOTHING VALIDATED THE FILE. That is how (1) survived. appstreamcli is the validator Flathub gates submissions on, so it now runs in two places against the GENERATED file rather than the template: as a meson test (optional -- not every build host has appstreamcli) and as a CI step in the gui job, which is the one that always has it. Verified: `appstreamcli validate --no-net --pedantic` passes on the stamped output for a real release version and for the 0.0.0 sentinel, and the date derivation was exercised for zero-padded and unpadded month/day.

… bundle by arch Three defects in the Flatpak path, all of which only show up in a shipped artifact rather than at build time. 1. THE BUILD REPORTED 0.0.0. The committed manifest carries no -Dapp_version, so meson falls back to its dev sentinel. That is not cosmetic here: the Flatpak is the ONLY artifact that installs the AppStream metainfo (packaging/lib/common.sh's assemble_daemon_root() whitelist excludes usr/share/metainfo, and make-appimage.sh does not package it), and that file is what GNOME Software, KDE Discover and the Flathub page read. A 0.0.0 there is valid AppStream, so nothing rejects it -- it just appears on the store page. The script now stamps -Dapp_version into a COPY of the manifest before the build, leaving the developer's working tree untouched, and refuses to continue if the config-opts anchor it keys off has moved rather than silently building an unstamped bundle. It is done here rather than in the release workflow so that a local `--install` and a CI build produce the same version. 2. NO -Dsdk_arch. flatpak-builder builds for the machine it runs on, so the value is derived from `uname -m` and stamped alongside the version; overridable with ARCH= for the rare cross case. 3. BOTH ARCHITECTURES WROTE THE SAME BUNDLE FILENAME. `URnetwork-<version>.flatpak` carries no arch, so the amd64 and arm64 legs collide and one silently overwrites the other wherever the artifacts are collected. The bundle is now `URnetwork-<version>-<arch>.flatpak`, matching what every other artifact in packaging/ already does: the build script names its own output. Also documents the manifest header accordingly -- go through make-flatpak.sh rather than calling flatpak-builder directly -- and adds the third Flathub prerequisite: Flathub builds the manifest on its own infrastructure where this script never runs, so -Dapp_version has to be written into config-opts before submission or the listing shows 0.0.0. The `urnetwork` launcher script gains the Flatpak as its last fallback. It is last on purpose: the Flatpak exports its own desktop entry under the same app id, so on a Flatpak machine this launcher normally loses on XDG precedence and is never invoked. It is reached only when that export is missing or shadowed -- and in exactly that case the old behaviour was to tell the user to download a GUI they already had installed.

Ryanmello07 · 2026-08-21T06:20:25Z

Stacked PR — depends on #5, #7 and #9 (metainfo).
Opened against main because a cross-fork PR needs its base branch to exist in
this repo, so the diff below currently includes its parent's changes too.
Review after its parent lands.

Three defects in the Flatpak path. All three only show up in a shipped artifact,
never at build time.

1. Every build reported 0.0.0

The committed manifest carries no -Dapp_version, so meson falls back to its dev
sentinel. That is not cosmetic here: the Flatpak is the only artifact that
installs the AppStream metainfo — packaging/lib/common.sh's
assemble_daemon_root() whitelist excludes usr/share/metainfo, and
make-appimage.sh does not package it either — and that file is what GNOME
Software, KDE Discover and the Flathub page read. A 0.0.0 there is valid
AppStream, so nothing rejects it; it just appears on the store page.

make-flatpak.sh now stamps -Dapp_version into a copy of the manifest
before the build, leaving the developer's working tree untouched, and refuses
to continue if the config-opts anchor it keys off has moved — rather than
silently building an unstamped bundle. It is done in the script rather than in
the release workflow so a local --install and a CI build produce the same
version.

2. No `-Dsdk_arch`

flatpak-builder builds for the machine it runs on, so the value is derived from
uname -m and stamped alongside the version. Overridable with ARCH= for the
rare cross case, with an explicit error on an unrecognised machine.

3. Both architectures wrote the same bundle filename

URnetwork-<version>.flatpak carries no arch, so the amd64 and arm64 legs
collide and one silently overwrites the other wherever the artifacts are
collected. The bundle is now URnetwork-<version>-<arch>.flatpak, matching what
every other script in packaging/ already does: the build script names its own
output rather than leaving a workflow to rename it.

Manifest header

Updated to say "go through make-flatpak.sh", and to add the third Flathub
prerequisite alongside the two already documented: Flathub builds this manifest
on its own infrastructure, where make-flatpak.sh never runs, so
-Dapp_version has to be written into config-opts before submission or the
listing shows 0.0.0.

The launcher gains a Flatpak fallback

app/packaging/urnetwork-launcher now falls back to flatpak run com.bringyour.network as its last candidate. Last on purpose: the Flatpak
exports its own desktop entry under the same app id, so on a Flatpak machine this
launcher normally loses on XDG precedence and is never invoked at all. It is
reached only when that export is missing or shadowed — and in exactly that case
the old behaviour was to tell the user to download a GUI they already had
installed.

Verified

bash -n on the script and the launcher (also sh -n, since the launcher is
POSIX sh); the manifest parses as YAML before and after the stamping sed is
applied for real, and the stamped config-opts land in the right module.

Why this is split this way

This is the Flatpak's build plumbing, which is a different review than "what
does the store listing say" (PR 4) or "what is the app id" (PR 2). The launcher
change rides along because it is the same question from the other side — how a
machine that has the Flatpak finds it.

The Android and Apple clients ship under `com.bringyour.network`. Linux was the only platform on a different reverse-DNS id, and every place the id is written down had to be told which one to use. This makes Linux match, and it has to be done in one change because the id is a join key: the GTK application id, the .desktop basename, the AppStream component id, the polkit action namespace, the icon-theme name and the Flatpak app id must all agree or the desktop stops recognising the app. WHAT MOVES, AND WHY IT IS ALL ONE COMMIT main.cpp Gtk::Application::create() -- the GApplication id *.desktop filename, Icon=, StartupWMClass= metainfo.xml filename, <id>, <launchable> polkit .policy filename + all four action ids, matched in ControlProtocol.hpp so the daemon asks about the actions the file actually declares icons hicolor basenames; Flatpak refuses to export an icon whose name is not the app id flatpak manifest filename + id + the desktop-file-edit paths deb/rpm/tarball/ the installed paths, the conffile entries, and the AppImage/snap uninstaller's stale-path list Splitting these would leave an intermediate commit where, for example, the .desktop names an icon that does not exist, or the daemon checks polkit actions the shipped .policy does not declare -- both of which fail silently at runtime rather than at build time. TWO THINGS THAT ARE NOT PURE SEARCH-AND-REPLACE 1. `UrTheme::kAppIconName`. The icon name was spelled as a literal in two places -- the by-path load in UrTheme.cpp and the by-name fallback in MainWindow.cpp. Renaming the packaging alone left both lookups pointing at a file that no longer existed, and `set_from_icon_name()` renders a blank image without raising anything, so the title-bar logo simply went empty. It is now one constant that the packaging and both call sites share. 2. The libsecret keyring attribute in SecretServiceRpcSessionStore.cpp moves with the id. This is deliberately NOT dual-read: an entry written by an older build is no longer found, the app falls back to a fresh RPC session (the same one-time cost as the Flatpak data path moving), and the previous app identity is not left holding live key material in the user's keyring with nothing to clean it up. No behaviour changes beyond those two. `network.ur.urnetwork` no longer appears anywhere in the tree.

Two separate problems with the shipped icon, both visible on a normal desktop. TRANSPARENCY. The old artwork had an opaque background baked in, so the icon rendered as a square tile wherever the shell composites over its own surface -- the GNOME dash, the app grid, and the window's own title bar. The replacements are RGBA with a real alpha channel. SIZES. Only 48 and 256 were installed. The desktop asks for 64 in the app grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the nearest size it has, so those lookups were served an upscale. This installs 48, 64, 128, 256 and 512. All five are downscales of a single 1024x1024 master, taken from the same AppIcon artwork the Apple client ships, so they cannot drift apart the way separately-drawn assets do. The master is committed at packaging/icons/com.bringyour.network-master-1024.png for regenerating them. 512 IS THE CEILING, DELIBERATELY. Installing the 1024 breaks the Flatpak build outright: `flatpak build-export` refuses it with "Image too large (1024x1024). Max. size 512x512" and fails the whole build at export time. Nothing downstream wants a larger one -- Flathub renders the store page at up to 512 -- so the master is kept in the tree but not installed. app/meson.build (the Flatpak's installer) and packaging/lib/common.sh (the staging tree the .deb, .rpm and tarball are all built from) now list the same five sizes, and the tarball uninstaller removes all five; a size installed by one and forgotten by the other is a file left behind on uninstall.

…validate it Three things the AppStream metadata needed before it could be submitted anywhere, and one reason nothing caught them. 1. THE RELEASE VERSION WAS HARDCODED, so it was wrong. Nothing wrote it, so the file said whatever was typed into it last while the pipeline shipped a different version. This element is not decoration: GNOME Software, KDE Discover and the Flathub page all read <release version=...> and show it. The file becomes a configure_file() template. app/meson.build derives both attributes from -Dapp_version, which the pipeline already passes and which both binaries already compile in as UR_APP_VERSION, so there is now exactly one place the release version is written down. The FULL version is stamped, suffix and all. appstreamcli accepts it, and truncating would advertise a version matching no artifact -- every other consumer of $VERSION (both binaries, every package filename, the release-asset gates) uses the whole string -- and would collapse every build of the same UTC day into one indistinguishable release element. Only the date is derived, from the leading <YYYY>.<M>.<D>. When -Dapp_version is not passed, meson warns loudly. That branch cannot be caught any other way: a document saying version="0.0.0" is perfectly valid AppStream, so no validator objects -- it just appears on the store page. 2. NO SCREENSHOT. Flathub requires at least one, and it is the single largest thing a store listing is judged on. Added as a committed PNG plus the raw URL Flathub mirrors from; a repo-relative path does not work, because the mirror step runs on a build host with only the URL. The declared width and height match the file exactly, which Flathub's linter checks. 3. NOTHING VALIDATED THE FILE. That is how (1) survived. appstreamcli is the validator Flathub gates submissions on, so it now runs in two places against the GENERATED file rather than the template: as a meson test (optional -- not every build host has appstreamcli) and as a CI step in the gui job, which is the one that always has it. Verified: `appstreamcli validate --no-net --pedantic` passes on the stamped output for a real release version and for the 0.0.0 sentinel, and the date derivation was exercised for zero-padded and unpadded month/day.

… bundle by arch Three defects in the Flatpak path, all of which only show up in a shipped artifact rather than at build time. 1. THE BUILD REPORTED 0.0.0. The committed manifest carries no -Dapp_version, so meson falls back to its dev sentinel. That is not cosmetic here: the Flatpak is the ONLY artifact that installs the AppStream metainfo (packaging/lib/common.sh's assemble_daemon_root() whitelist excludes usr/share/metainfo, and make-appimage.sh does not package it), and that file is what GNOME Software, KDE Discover and the Flathub page read. A 0.0.0 there is valid AppStream, so nothing rejects it -- it just appears on the store page. The script now stamps -Dapp_version into a COPY of the manifest before the build, leaving the developer's working tree untouched, and refuses to continue if the config-opts anchor it keys off has moved rather than silently building an unstamped bundle. It is done here rather than in the release workflow so that a local `--install` and a CI build produce the same version. 2. NO -Dsdk_arch. flatpak-builder builds for the machine it runs on, so the value is derived from `uname -m` and stamped alongside the version; overridable with ARCH= for the rare cross case. 3. BOTH ARCHITECTURES WROTE THE SAME BUNDLE FILENAME. `URnetwork-<version>.flatpak` carries no arch, so the amd64 and arm64 legs collide and one silently overwrites the other wherever the artifacts are collected. The bundle is now `URnetwork-<version>-<arch>.flatpak`, matching what every other artifact in packaging/ already does: the build script names its own output. Also documents the manifest header accordingly -- go through make-flatpak.sh rather than calling flatpak-builder directly -- and adds the third Flathub prerequisite: Flathub builds the manifest on its own infrastructure where this script never runs, so -Dapp_version has to be written into config-opts before submission or the listing shows 0.0.0. The `urnetwork` launcher script gains the Flatpak as its last fallback. It is last on purpose: the Flatpak exports its own desktop entry under the same app id, so on a Flatpak machine this launcher normally loses on XDG precedence and is never invoked. It is reached only when that export is missing or shadowed -- and in exactly that case the old behaviour was to tell the user to download a GUI they already had installed.

Ryanmello07 · 2026-08-21T06:20:25Z

Stacked PR — depends on #5, #7 and #9 (metainfo).
Opened against main because a cross-fork PR needs its base branch to exist in
this repo, so the diff below currently includes its parent's changes too.
Review after its parent lands.

Three defects in the Flatpak path. All three only show up in a shipped artifact,
never at build time.

1. Every build reported 0.0.0

The committed manifest carries no -Dapp_version, so meson falls back to its dev
sentinel. That is not cosmetic here: the Flatpak is the only artifact that
installs the AppStream metainfo — packaging/lib/common.sh's
assemble_daemon_root() whitelist excludes usr/share/metainfo, and
make-appimage.sh does not package it either — and that file is what GNOME
Software, KDE Discover and the Flathub page read. A 0.0.0 there is valid
AppStream, so nothing rejects it; it just appears on the store page.

make-flatpak.sh now stamps -Dapp_version into a copy of the manifest
before the build, leaving the developer's working tree untouched, and refuses
to continue if the config-opts anchor it keys off has moved — rather than
silently building an unstamped bundle. It is done in the script rather than in
the release workflow so a local --install and a CI build produce the same
version.

2. No `-Dsdk_arch`

flatpak-builder builds for the machine it runs on, so the value is derived from
uname -m and stamped alongside the version. Overridable with ARCH= for the
rare cross case, with an explicit error on an unrecognised machine.

3. Both architectures wrote the same bundle filename

URnetwork-<version>.flatpak carries no arch, so the amd64 and arm64 legs
collide and one silently overwrites the other wherever the artifacts are
collected. The bundle is now URnetwork-<version>-<arch>.flatpak, matching what
every other script in packaging/ already does: the build script names its own
output rather than leaving a workflow to rename it.

Manifest header

Updated to say "go through make-flatpak.sh", and to add the third Flathub
prerequisite alongside the two already documented: Flathub builds this manifest
on its own infrastructure, where make-flatpak.sh never runs, so
-Dapp_version has to be written into config-opts before submission or the
listing shows 0.0.0.

The launcher gains a Flatpak fallback

app/packaging/urnetwork-launcher now falls back to flatpak run com.bringyour.network as its last candidate. Last on purpose: the Flatpak
exports its own desktop entry under the same app id, so on a Flatpak machine this
launcher normally loses on XDG precedence and is never invoked at all. It is
reached only when that export is missing or shadowed — and in exactly that case
the old behaviour was to tell the user to download a GUI they already had
installed.

Verified

bash -n on the script and the launcher (also sh -n, since the launcher is
POSIX sh); the manifest parses as YAML before and after the stamping sed is
applied for real, and the stamped config-opts land in the right module.

Why this is split this way

This is the Flatpak's build plumbing, which is a different review than "what
does the store listing say" (PR 4) or "what is the app id" (PR 2). The launcher
change rides along because it is the same question from the other side — how a
machine that has the Flatpak finds it.

The Android and Apple clients ship under `com.bringyour.network`. Linux was the only platform on a different reverse-DNS id, and every place the id is written down had to be told which one to use. This makes Linux match, and it has to be done in one change because the id is a join key: the GTK application id, the .desktop basename, the AppStream component id, the polkit action namespace, the icon-theme name and the Flatpak app id must all agree or the desktop stops recognising the app. WHAT MOVES, AND WHY IT IS ALL ONE COMMIT main.cpp Gtk::Application::create() -- the GApplication id *.desktop filename, Icon=, StartupWMClass= metainfo.xml filename, <id>, <launchable> polkit .policy filename + all four action ids, matched in ControlProtocol.hpp so the daemon asks about the actions the file actually declares icons hicolor basenames; Flatpak refuses to export an icon whose name is not the app id flatpak manifest filename + id + the desktop-file-edit paths deb/rpm/tarball/ the installed paths, the conffile entries, and the AppImage/snap uninstaller's stale-path list Splitting these would leave an intermediate commit where, for example, the .desktop names an icon that does not exist, or the daemon checks polkit actions the shipped .policy does not declare -- both of which fail silently at runtime rather than at build time. TWO THINGS THAT ARE NOT PURE SEARCH-AND-REPLACE 1. `UrTheme::kAppIconName`. The icon name was spelled as a literal in two places -- the by-path load in UrTheme.cpp and the by-name fallback in MainWindow.cpp. Renaming the packaging alone left both lookups pointing at a file that no longer existed, and `set_from_icon_name()` renders a blank image without raising anything, so the title-bar logo simply went empty. It is now one constant that the packaging and both call sites share. 2. The libsecret keyring attribute in SecretServiceRpcSessionStore.cpp moves with the id. This is deliberately NOT dual-read: an entry written by an older build is no longer found, the app falls back to a fresh RPC session (the same one-time cost as the Flatpak data path moving), and the previous app identity is not left holding live key material in the user's keyring with nothing to clean it up. No behaviour changes beyond those two. `network.ur.urnetwork` no longer appears anywhere in the tree.

Two separate problems with the shipped icon, both visible on a normal desktop. TRANSPARENCY. The old artwork had an opaque background baked in, so the icon rendered as a square tile wherever the shell composites over its own surface -- the GNOME dash, the app grid, and the window's own title bar. The replacements are RGBA with a real alpha channel. SIZES. Only 48 and 256 were installed. The desktop asks for 64 in the app grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the nearest size it has, so those lookups were served an upscale. This installs 48, 64, 128, 256 and 512. All five are downscales of a single 1024x1024 master, taken from the same AppIcon artwork the Apple client ships, so they cannot drift apart the way separately-drawn assets do. The master is committed at packaging/icons/com.bringyour.network-master-1024.png for regenerating them. 512 IS THE CEILING, DELIBERATELY. Installing the 1024 breaks the Flatpak build outright: `flatpak build-export` refuses it with "Image too large (1024x1024). Max. size 512x512" and fails the whole build at export time. Nothing downstream wants a larger one -- Flathub renders the store page at up to 512 -- so the master is kept in the tree but not installed. app/meson.build (the Flatpak's installer) and packaging/lib/common.sh (the staging tree the .deb, .rpm and tarball are all built from) now list the same five sizes, and the tarball uninstaller removes all five; a size installed by one and forgotten by the other is a file left behind on uninstall.

…validate it Three things the AppStream metadata needed before it could be submitted anywhere, and one reason nothing caught them. 1. THE RELEASE VERSION WAS HARDCODED, so it was wrong. Nothing wrote it, so the file said whatever was typed into it last while the pipeline shipped a different version. This element is not decoration: GNOME Software, KDE Discover and the Flathub page all read <release version=...> and show it. The file becomes a configure_file() template. app/meson.build derives both attributes from -Dapp_version, which the pipeline already passes and which both binaries already compile in as UR_APP_VERSION, so there is now exactly one place the release version is written down. The FULL version is stamped, suffix and all. appstreamcli accepts it, and truncating would advertise a version matching no artifact -- every other consumer of $VERSION (both binaries, every package filename, the release-asset gates) uses the whole string -- and would collapse every build of the same UTC day into one indistinguishable release element. Only the date is derived, from the leading <YYYY>.<M>.<D>. When -Dapp_version is not passed, meson warns loudly. That branch cannot be caught any other way: a document saying version="0.0.0" is perfectly valid AppStream, so no validator objects -- it just appears on the store page. 2. NO SCREENSHOT. Flathub requires at least one, and it is the single largest thing a store listing is judged on. Added as a committed PNG plus the raw URL Flathub mirrors from; a repo-relative path does not work, because the mirror step runs on a build host with only the URL. The declared width and height match the file exactly, which Flathub's linter checks. 3. NOTHING VALIDATED THE FILE. That is how (1) survived. appstreamcli is the validator Flathub gates submissions on, so it now runs in two places against the GENERATED file rather than the template: as a meson test (optional -- not every build host has appstreamcli) and as a CI step in the gui job, which is the one that always has it. Verified: `appstreamcli validate --no-net --pedantic` passes on the stamped output for a real release version and for the 0.0.0 sentinel, and the date derivation was exercised for zero-padded and unpadded month/day.

… bundle by arch Three defects in the Flatpak path, all of which only show up in a shipped artifact rather than at build time. 1. THE BUILD REPORTED 0.0.0. The committed manifest carries no -Dapp_version, so meson falls back to its dev sentinel. That is not cosmetic here: the Flatpak is the ONLY artifact that installs the AppStream metainfo (packaging/lib/common.sh's assemble_daemon_root() whitelist excludes usr/share/metainfo, and make-appimage.sh does not package it), and that file is what GNOME Software, KDE Discover and the Flathub page read. A 0.0.0 there is valid AppStream, so nothing rejects it -- it just appears on the store page. The script now stamps -Dapp_version into a COPY of the manifest before the build, leaving the developer's working tree untouched, and refuses to continue if the config-opts anchor it keys off has moved rather than silently building an unstamped bundle. It is done here rather than in the release workflow so that a local `--install` and a CI build produce the same version. 2. NO -Dsdk_arch. flatpak-builder builds for the machine it runs on, so the value is derived from `uname -m` and stamped alongside the version; overridable with ARCH= for the rare cross case. 3. BOTH ARCHITECTURES WROTE THE SAME BUNDLE FILENAME. `URnetwork-<version>.flatpak` carries no arch, so the amd64 and arm64 legs collide and one silently overwrites the other wherever the artifacts are collected. The bundle is now `URnetwork-<version>-<arch>.flatpak`, matching what every other artifact in packaging/ already does: the build script names its own output. Also documents the manifest header accordingly -- go through make-flatpak.sh rather than calling flatpak-builder directly -- and adds the third Flathub prerequisite: Flathub builds the manifest on its own infrastructure where this script never runs, so -Dapp_version has to be written into config-opts before submission or the listing shows 0.0.0. The `urnetwork` launcher script gains the Flatpak as its last fallback. It is last on purpose: the Flatpak exports its own desktop entry under the same app id, so on a Flatpak machine this launcher normally loses on XDG precedence and is never invoked. It is reached only when that export is missing or shadowed -- and in exactly that case the old behaviour was to tell the user to download a GUI they already had installed.

Ryanmello07 · 2026-08-21T06:20:25Z

Stacked PR — depends on #5, #7 and #9 (metainfo).
Opened against main because a cross-fork PR needs its base branch to exist in
this repo, so the diff below currently includes its parent's changes too.
Review after its parent lands.

Three defects in the Flatpak path. All three only show up in a shipped artifact,
never at build time.

1. Every build reported 0.0.0

The committed manifest carries no -Dapp_version, so meson falls back to its dev
sentinel. That is not cosmetic here: the Flatpak is the only artifact that
installs the AppStream metainfo — packaging/lib/common.sh's
assemble_daemon_root() whitelist excludes usr/share/metainfo, and
make-appimage.sh does not package it either — and that file is what GNOME
Software, KDE Discover and the Flathub page read. A 0.0.0 there is valid
AppStream, so nothing rejects it; it just appears on the store page.

make-flatpak.sh now stamps -Dapp_version into a copy of the manifest
before the build, leaving the developer's working tree untouched, and refuses
to continue if the config-opts anchor it keys off has moved — rather than
silently building an unstamped bundle. It is done in the script rather than in
the release workflow so a local --install and a CI build produce the same
version.

2. No `-Dsdk_arch`

flatpak-builder builds for the machine it runs on, so the value is derived from
uname -m and stamped alongside the version. Overridable with ARCH= for the
rare cross case, with an explicit error on an unrecognised machine.

3. Both architectures wrote the same bundle filename

URnetwork-<version>.flatpak carries no arch, so the amd64 and arm64 legs
collide and one silently overwrites the other wherever the artifacts are
collected. The bundle is now URnetwork-<version>-<arch>.flatpak, matching what
every other script in packaging/ already does: the build script names its own
output rather than leaving a workflow to rename it.

Manifest header

Updated to say "go through make-flatpak.sh", and to add the third Flathub
prerequisite alongside the two already documented: Flathub builds this manifest
on its own infrastructure, where make-flatpak.sh never runs, so
-Dapp_version has to be written into config-opts before submission or the
listing shows 0.0.0.

The launcher gains a Flatpak fallback

app/packaging/urnetwork-launcher now falls back to flatpak run com.bringyour.network as its last candidate. Last on purpose: the Flatpak
exports its own desktop entry under the same app id, so on a Flatpak machine this
launcher normally loses on XDG precedence and is never invoked at all. It is
reached only when that export is missing or shadowed — and in exactly that case
the old behaviour was to tell the user to download a GUI they already had
installed.

Verified

bash -n on the script and the launcher (also sh -n, since the launcher is
POSIX sh); the manifest parses as YAML before and after the stamping sed is
applied for real, and the stamped config-opts land in the right module.

Why this is split this way

This is the Flatpak's build plumbing, which is a different review than "what
does the store listing say" (PR 4) or "what is the app id" (PR 2). The launcher
change rides along because it is the same question from the other side — how a
machine that has the Flatpak finds it.

The Android and Apple clients ship under `com.bringyour.network`. Linux was the only platform on a different reverse-DNS id, and every place the id is written down had to be told which one to use. This makes Linux match, and it has to be done in one change because the id is a join key: the GTK application id, the .desktop basename, the AppStream component id, the polkit action namespace, the icon-theme name and the Flatpak app id must all agree or the desktop stops recognising the app. WHAT MOVES, AND WHY IT IS ALL ONE COMMIT main.cpp Gtk::Application::create() -- the GApplication id *.desktop filename, Icon=, StartupWMClass= metainfo.xml filename, <id>, <launchable> polkit .policy filename + all four action ids, matched in ControlProtocol.hpp so the daemon asks about the actions the file actually declares icons hicolor basenames; Flatpak refuses to export an icon whose name is not the app id flatpak manifest filename + id + the desktop-file-edit paths deb/rpm/tarball/ the installed paths, the conffile entries, and the AppImage/snap uninstaller's stale-path list Splitting these would leave an intermediate commit where, for example, the .desktop names an icon that does not exist, or the daemon checks polkit actions the shipped .policy does not declare -- both of which fail silently at runtime rather than at build time. TWO THINGS THAT ARE NOT PURE SEARCH-AND-REPLACE 1. `UrTheme::kAppIconName`. The icon name was spelled as a literal in two places -- the by-path load in UrTheme.cpp and the by-name fallback in MainWindow.cpp. Renaming the packaging alone left both lookups pointing at a file that no longer existed, and `set_from_icon_name()` renders a blank image without raising anything, so the title-bar logo simply went empty. It is now one constant that the packaging and both call sites share. 2. The libsecret keyring attribute in SecretServiceRpcSessionStore.cpp moves with the id. This is deliberately NOT dual-read: an entry written by an older build is no longer found, the app falls back to a fresh RPC session (the same one-time cost as the Flatpak data path moving), and the previous app identity is not left holding live key material in the user's keyring with nothing to clean it up. No behaviour changes beyond those two. `network.ur.urnetwork` no longer appears anywhere in the tree.

Two separate problems with the shipped icon, both visible on a normal desktop. TRANSPARENCY. The old artwork had an opaque background baked in, so the icon rendered as a square tile wherever the shell composites over its own surface -- the GNOME dash, the app grid, and the window's own title bar. The replacements are RGBA with a real alpha channel. SIZES. Only 48 and 256 were installed. The desktop asks for 64 in the app grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the nearest size it has, so those lookups were served an upscale. This installs 48, 64, 128, 256 and 512. All five are downscales of a single 1024x1024 master, taken from the same AppIcon artwork the Apple client ships, so they cannot drift apart the way separately-drawn assets do. The master is committed at packaging/icons/com.bringyour.network-master-1024.png for regenerating them. 512 IS THE CEILING, DELIBERATELY. Installing the 1024 breaks the Flatpak build outright: `flatpak build-export` refuses it with "Image too large (1024x1024). Max. size 512x512" and fails the whole build at export time. Nothing downstream wants a larger one -- Flathub renders the store page at up to 512 -- so the master is kept in the tree but not installed. app/meson.build (the Flatpak's installer) and packaging/lib/common.sh (the staging tree the .deb, .rpm and tarball are all built from) now list the same five sizes, and the tarball uninstaller removes all five; a size installed by one and forgotten by the other is a file left behind on uninstall.

…validate it Three things the AppStream metadata needed before it could be submitted anywhere, and one reason nothing caught them. 1. THE RELEASE VERSION WAS HARDCODED, so it was wrong. Nothing wrote it, so the file said whatever was typed into it last while the pipeline shipped a different version. This element is not decoration: GNOME Software, KDE Discover and the Flathub page all read <release version=...> and show it. The file becomes a configure_file() template. app/meson.build derives both attributes from -Dapp_version, which the pipeline already passes and which both binaries already compile in as UR_APP_VERSION, so there is now exactly one place the release version is written down. The FULL version is stamped, suffix and all. appstreamcli accepts it, and truncating would advertise a version matching no artifact -- every other consumer of $VERSION (both binaries, every package filename, the release-asset gates) uses the whole string -- and would collapse every build of the same UTC day into one indistinguishable release element. Only the date is derived, from the leading <YYYY>.<M>.<D>. When -Dapp_version is not passed, meson warns loudly. That branch cannot be caught any other way: a document saying version="0.0.0" is perfectly valid AppStream, so no validator objects -- it just appears on the store page. 2. NO SCREENSHOT. Flathub requires at least one, and it is the single largest thing a store listing is judged on. Added as a committed PNG plus the raw URL Flathub mirrors from; a repo-relative path does not work, because the mirror step runs on a build host with only the URL. The declared width and height match the file exactly, which Flathub's linter checks. 3. NOTHING VALIDATED THE FILE. That is how (1) survived. appstreamcli is the validator Flathub gates submissions on, so it now runs in two places against the GENERATED file rather than the template: as a meson test (optional -- not every build host has appstreamcli) and as a CI step in the gui job, which is the one that always has it. Verified: `appstreamcli validate --no-net --pedantic` passes on the stamped output for a real release version and for the 0.0.0 sentinel, and the date derivation was exercised for zero-padded and unpadded month/day.

… bundle by arch Three defects in the Flatpak path, all of which only show up in a shipped artifact rather than at build time. 1. THE BUILD REPORTED 0.0.0. The committed manifest carries no -Dapp_version, so meson falls back to its dev sentinel. That is not cosmetic here: the Flatpak is the ONLY artifact that installs the AppStream metainfo (packaging/lib/common.sh's assemble_daemon_root() whitelist excludes usr/share/metainfo, and make-appimage.sh does not package it), and that file is what GNOME Software, KDE Discover and the Flathub page read. A 0.0.0 there is valid AppStream, so nothing rejects it -- it just appears on the store page. The script now stamps -Dapp_version into a COPY of the manifest before the build, leaving the developer's working tree untouched, and refuses to continue if the config-opts anchor it keys off has moved rather than silently building an unstamped bundle. It is done here rather than in the release workflow so that a local `--install` and a CI build produce the same version. 2. NO -Dsdk_arch. flatpak-builder builds for the machine it runs on, so the value is derived from `uname -m` and stamped alongside the version; overridable with ARCH= for the rare cross case. 3. BOTH ARCHITECTURES WROTE THE SAME BUNDLE FILENAME. `URnetwork-<version>.flatpak` carries no arch, so the amd64 and arm64 legs collide and one silently overwrites the other wherever the artifacts are collected. The bundle is now `URnetwork-<version>-<arch>.flatpak`, matching what every other artifact in packaging/ already does: the build script names its own output. Also documents the manifest header accordingly -- go through make-flatpak.sh rather than calling flatpak-builder directly -- and adds the third Flathub prerequisite: Flathub builds the manifest on its own infrastructure where this script never runs, so -Dapp_version has to be written into config-opts before submission or the listing shows 0.0.0. The `urnetwork` launcher script gains the Flatpak as its last fallback. It is last on purpose: the Flatpak exports its own desktop entry under the same app id, so on a Flatpak machine this launcher normally loses on XDG precedence and is never invoked. It is reached only when that export is missing or shadowed -- and in exactly that case the old behaviour was to tell the user to download a GUI they already had installed.

Ryanmello07 · 2026-08-21T06:20:25Z

Stacked PR — depends on #5, #7 and #9 (metainfo).
Opened against main because a cross-fork PR needs its base branch to exist in
this repo, so the diff below currently includes its parent's changes too.
Review after its parent lands.

Three defects in the Flatpak path. All three only show up in a shipped artifact,
never at build time.

1. Every build reported 0.0.0

The committed manifest carries no -Dapp_version, so meson falls back to its dev
sentinel. That is not cosmetic here: the Flatpak is the only artifact that
installs the AppStream metainfo — packaging/lib/common.sh's
assemble_daemon_root() whitelist excludes usr/share/metainfo, and
make-appimage.sh does not package it either — and that file is what GNOME
Software, KDE Discover and the Flathub page read. A 0.0.0 there is valid
AppStream, so nothing rejects it; it just appears on the store page.

make-flatpak.sh now stamps -Dapp_version into a copy of the manifest
before the build, leaving the developer's working tree untouched, and refuses
to continue if the config-opts anchor it keys off has moved — rather than
silently building an unstamped bundle. It is done in the script rather than in
the release workflow so a local --install and a CI build produce the same
version.

2. No `-Dsdk_arch`

flatpak-builder builds for the machine it runs on, so the value is derived from
uname -m and stamped alongside the version. Overridable with ARCH= for the
rare cross case, with an explicit error on an unrecognised machine.

3. Both architectures wrote the same bundle filename

URnetwork-<version>.flatpak carries no arch, so the amd64 and arm64 legs
collide and one silently overwrites the other wherever the artifacts are
collected. The bundle is now URnetwork-<version>-<arch>.flatpak, matching what
every other script in packaging/ already does: the build script names its own
output rather than leaving a workflow to rename it.

Manifest header

Updated to say "go through make-flatpak.sh", and to add the third Flathub
prerequisite alongside the two already documented: Flathub builds this manifest
on its own infrastructure, where make-flatpak.sh never runs, so
-Dapp_version has to be written into config-opts before submission or the
listing shows 0.0.0.

The launcher gains a Flatpak fallback

app/packaging/urnetwork-launcher now falls back to flatpak run com.bringyour.network as its last candidate. Last on purpose: the Flatpak
exports its own desktop entry under the same app id, so on a Flatpak machine this
launcher normally loses on XDG precedence and is never invoked at all. It is
reached only when that export is missing or shadowed — and in exactly that case
the old behaviour was to tell the user to download a GUI they already had
installed.

Verified

bash -n on the script and the launcher (also sh -n, since the launcher is
POSIX sh); the manifest parses as YAML before and after the stamping sed is
applied for real, and the stamped config-opts land in the right module.

Why this is split this way

This is the Flatpak's build plumbing, which is a different review than "what
does the store listing say" (PR 4) or "what is the app id" (PR 2). The launcher
change rides along because it is the same question from the other side — how a
machine that has the Flatpak finds it.

The Android and Apple clients ship under `com.bringyour.network`. Linux was the only platform on a different reverse-DNS id, and every place the id is written down had to be told which one to use. This makes Linux match, and it has to be done in one change because the id is a join key: the GTK application id, the .desktop basename, the AppStream component id, the polkit action namespace, the icon-theme name and the Flatpak app id must all agree or the desktop stops recognising the app. WHAT MOVES, AND WHY IT IS ALL ONE COMMIT main.cpp Gtk::Application::create() -- the GApplication id *.desktop filename, Icon=, StartupWMClass= metainfo.xml filename, <id>, <launchable> polkit .policy filename + all four action ids, matched in ControlProtocol.hpp so the daemon asks about the actions the file actually declares icons hicolor basenames; Flatpak refuses to export an icon whose name is not the app id flatpak manifest filename + id + the desktop-file-edit paths deb/rpm/tarball/ the installed paths, the conffile entries, and the AppImage/snap uninstaller's stale-path list Splitting these would leave an intermediate commit where, for example, the .desktop names an icon that does not exist, or the daemon checks polkit actions the shipped .policy does not declare -- both of which fail silently at runtime rather than at build time. TWO THINGS THAT ARE NOT PURE SEARCH-AND-REPLACE 1. `UrTheme::kAppIconName`. The icon name was spelled as a literal in two places -- the by-path load in UrTheme.cpp and the by-name fallback in MainWindow.cpp. Renaming the packaging alone left both lookups pointing at a file that no longer existed, and `set_from_icon_name()` renders a blank image without raising anything, so the title-bar logo simply went empty. It is now one constant that the packaging and both call sites share. 2. The libsecret keyring attribute in SecretServiceRpcSessionStore.cpp moves with the id. This is deliberately NOT dual-read: an entry written by an older build is no longer found, the app falls back to a fresh RPC session (the same one-time cost as the Flatpak data path moving), and the previous app identity is not left holding live key material in the user's keyring with nothing to clean it up. No behaviour changes beyond those two. `network.ur.urnetwork` no longer appears anywhere in the tree.

Two separate problems with the shipped icon, both visible on a normal desktop. TRANSPARENCY. The old artwork had an opaque background baked in, so the icon rendered as a square tile wherever the shell composites over its own surface -- the GNOME dash, the app grid, and the window's own title bar. The replacements are RGBA with a real alpha channel. SIZES. Only 48 and 256 were installed. The desktop asks for 64 in the app grid and 128/256 on a HiDPI display, and hicolor's fallback is to scale the nearest size it has, so those lookups were served an upscale. This installs 48, 64, 128, 256 and 512. All five are downscales of a single 1024x1024 master, taken from the same AppIcon artwork the Apple client ships, so they cannot drift apart the way separately-drawn assets do. The master is committed at packaging/icons/com.bringyour.network-master-1024.png for regenerating them. 512 IS THE CEILING, DELIBERATELY. Installing the 1024 breaks the Flatpak build outright: `flatpak build-export` refuses it with "Image too large (1024x1024). Max. size 512x512" and fails the whole build at export time. Nothing downstream wants a larger one -- Flathub renders the store page at up to 512 -- so the master is kept in the tree but not installed. app/meson.build (the Flatpak's installer) and packaging/lib/common.sh (the staging tree the .deb, .rpm and tarball are all built from) now list the same five sizes, and the tarball uninstaller removes all five; a size installed by one and forgotten by the other is a file left behind on uninstall.

…validate it Three things the AppStream metadata needed before it could be submitted anywhere, and one reason nothing caught them. 1. THE RELEASE VERSION WAS HARDCODED, so it was wrong. Nothing wrote it, so the file said whatever was typed into it last while the pipeline shipped a different version. This element is not decoration: GNOME Software, KDE Discover and the Flathub page all read <release version=...> and show it. The file becomes a configure_file() template. app/meson.build derives both attributes from -Dapp_version, which the pipeline already passes and which both binaries already compile in as UR_APP_VERSION, so there is now exactly one place the release version is written down. The FULL version is stamped, suffix and all. appstreamcli accepts it, and truncating would advertise a version matching no artifact -- every other consumer of $VERSION (both binaries, every package filename, the release-asset gates) uses the whole string -- and would collapse every build of the same UTC day into one indistinguishable release element. Only the date is derived, from the leading <YYYY>.<M>.<D>. When -Dapp_version is not passed, meson warns loudly. That branch cannot be caught any other way: a document saying version="0.0.0" is perfectly valid AppStream, so no validator objects -- it just appears on the store page. 2. NO SCREENSHOT. Flathub requires at least one, and it is the single largest thing a store listing is judged on. Added as a committed PNG plus the raw URL Flathub mirrors from; a repo-relative path does not work, because the mirror step runs on a build host with only the URL. The declared width and height match the file exactly, which Flathub's linter checks. 3. NOTHING VALIDATED THE FILE. That is how (1) survived. appstreamcli is the validator Flathub gates submissions on, so it now runs in two places against the GENERATED file rather than the template: as a meson test (optional -- not every build host has appstreamcli) and as a CI step in the gui job, which is the one that always has it. Verified: `appstreamcli validate --no-net --pedantic` passes on the stamped output for a real release version and for the 0.0.0 sentinel, and the date derivation was exercised for zero-padded and unpadded month/day.

… bundle by arch Three defects in the Flatpak path, all of which only show up in a shipped artifact rather than at build time. 1. THE BUILD REPORTED 0.0.0. The committed manifest carries no -Dapp_version, so meson falls back to its dev sentinel. That is not cosmetic here: the Flatpak is the ONLY artifact that installs the AppStream metainfo (packaging/lib/common.sh's assemble_daemon_root() whitelist excludes usr/share/metainfo, and make-appimage.sh does not package it), and that file is what GNOME Software, KDE Discover and the Flathub page read. A 0.0.0 there is valid AppStream, so nothing rejects it -- it just appears on the store page. The script now stamps -Dapp_version into a COPY of the manifest before the build, leaving the developer's working tree untouched, and refuses to continue if the config-opts anchor it keys off has moved rather than silently building an unstamped bundle. It is done here rather than in the release workflow so that a local `--install` and a CI build produce the same version. 2. NO -Dsdk_arch. flatpak-builder builds for the machine it runs on, so the value is derived from `uname -m` and stamped alongside the version; overridable with ARCH= for the rare cross case. 3. BOTH ARCHITECTURES WROTE THE SAME BUNDLE FILENAME. `URnetwork-<version>.flatpak` carries no arch, so the amd64 and arm64 legs collide and one silently overwrites the other wherever the artifacts are collected. The bundle is now `URnetwork-<version>-<arch>.flatpak`, matching what every other artifact in packaging/ already does: the build script names its own output. Also documents the manifest header accordingly -- go through make-flatpak.sh rather than calling flatpak-builder directly -- and adds the third Flathub prerequisite: Flathub builds the manifest on its own infrastructure where this script never runs, so -Dapp_version has to be written into config-opts before submission or the listing shows 0.0.0. The `urnetwork` launcher script gains the Flatpak as its last fallback. It is last on purpose: the Flatpak exports its own desktop entry under the same app id, so on a Flatpak machine this launcher normally loses on XDG precedence and is never invoked. It is reached only when that export is missing or shadowed -- and in exactly that case the old behaviour was to tell the user to download a GUI they already had installed.