For arm64 cross-build, dpkg-checkbuilddeps fails with:
Unmet build dependencies: dotnet-sdk-10.0 (>= 10.0.0)
because it looks for dotnet-sdk-10.0:arm64 (the arm64 build of
the SDK), which we don't install. But we don't need it — the
dotnet publish --runtime linux-arm64 invocation runs natively
on the amd64 host. The Build-Depends entry is only meaningful
for native amd64 builds.
-d skips the build-deps check entirely. Safe for this package:
dh_shlibdeps picks up real runtime deps from the .so files
(libfontconfig, libgtk-3, etc.), so the resulting .deb has
correct Depends: regardless.
The previous commit set up -aarm64 + DEB_HOST_ARCH=arm64
without going through dpkg-architecture. Add a comment
explaining why that's safe for this particular package:
- No C compilation (only dotnet publish --runtime linux-arm64)
- dh_strip disabled (no arch-specific objcopy needed)
- dh_shlibdeps works because we install arm64 libs via multi-arch
This is the standard pattern for mono-managed / Java / Go
Debian packages that cross-build without a C toolchain.
The case ... esac block was split across multiple recipe lines,
and make runs each line in its own shell — so dash saw 'esac'
as a stray keyword and bailed with 'unexpected end of file
(expecting ")")'. Same shell-line gotcha as the earlier
if/then/fi.
Collapse into one line: DPKG_HOST=$(case ... echo arm64 ... esac)
&& DEB_HOST_ARCH=$DPKG_HOST ... dpkg-buildpackage -a$DPKG_HOST.
All in one shell, one set of variable assignments.
The 'dpkg-architecture -c' approach is meant for proper cross
builds, but dpkg-architecture refuses to set up the env when
the CC system type doesn't match the target. For arm64 cross
builds that means CC=aarch64-linux-gnu-gcc is required. We
don't have that — we cross-publish .NET binaries with
`dotnet publish --runtime linux-arm64`, no C compilation.
So skip dpkg-architecture entirely:
- DPKG_HOST = 'arm64' or 'amd64' from a small case (no shell
substitution issues, single line)
- DEB_HOST_ARCH, DEB_BUILD_ARCH, DEB_HOST_GNU_TYPE,
DEB_BUILD_GNU_TYPE set in env directly
- -a$DPKG_HOST passed to dpkg-buildpackage, which now
builds and names the .deb for the target arch
dpkg-buildpackage doesn't actually need arm64 tools if the
rules don't use them: dh_strip is disabled (cross-strip
issues with ARM64 .so), and dh_shlibdeps works with the
multi-arch arm64 libs we install in the runner.
dpkg-architecture -aarm64 sets DEB_HOST_ARCH=arm64 but does
not propagate the env to the calling shell. The 'eval
$(dpkg-architecture $DPKG_ARCH_ARGS)' pattern tried to bridge
that but failed: the command substitution was parsed by make
before bash ever ran, with $DPKG_ARCH_ARGS still empty at make
parse time.
dpkg-architecture's -c flag runs a command with the proper env
set up: 'dpkg-architecture -aarm64 -c "..."' exports all the
DEB_* vars and then execs the command, all in one process.
The 'CC system type mismatch' warning on stderr is informational
(it complains that the C compiler isn't cross, but we don't
compile C — we only cross-publish .NET binaries). Verified
locally: 'dpkg-architecture -aarm64 -c "echo \$DEB_HOST_ARCH"'
prints 'arm64'.
The previous version had $(dpkg-architecture $DPKG_ARCH_ARGS).
make expands $(...) at parse time, BEFORE any bash command runs.
So make called 'dpkg-architecture' (no -a flag, because
$DPKG_ARCH_ARGS is empty at parse time) and substituted the
amd64 DEB_* vars into the recipe line. Bash then ran with the
amd64 vars baked in, regardless of what the runtime DPKG_ARCH_ARGS
ended up being.
Escape both dollars: $$ -> $, so make sees '$$' and passes
'$$' to bash, which sees '$(...)' and evaluates it at runtime
after DPKG_ARCH_ARGS is set on the previous command.
The '&&' between 'eval' and 'dpkg-buildpackage' was eating the
arguments to eval because make's substitution of the
$(dpkg-architecture $DPKG_ARCH_ARGS) command substitution
is visible only at runtime, not in the make pre-processing.
Bash then saw 'eval' followed by '&&' (with the substituted
command becoming a separate statement) and ran eval with no
arguments, leaving DEB_HOST_ARCH unset.
With ';', the three commands are one statement and bash
evaluates them left-to-right: assign DPKG_ARCH_ARGS, eval
the dpkg-architecture output to populate DEB_HOST_ARCH etc.,
then call dpkg-buildpackage which inherits the DEB_* vars.
Verified locally that 'eval $(dpkg-architecture -aarm64)'
sets DEB_HOST_ARCH=arm64 in the current shell.
The previous version put DPKG_ARCH_ARGS on its own logical line
and 'eval ... && dpkg-buildpackage' on the next, but each make
recipe line runs in its own shell. So when 'eval' ran, the
$DPKG_ARCH_ARGS variable from the previous shell was already
gone — 'eval' saw an empty argument and produced no DEB_HOST_ARCH
override, which made dpkg-buildpackage default to amd64.
Collapse everything onto one logical line (one shell invocation),
joining with '&&' so a failure in 'case' or 'dpkg-architecture'
short-circuits before dpkg-buildpackage runs.
make runs each recipe line in its own shell (typically /bin/sh
= dash on Debian). A multi-line case/esac block — same gotcha
as the earlier 'if/then/fi' — gets split across shells, and
the second shell sees 'esac' as a stray keyword and bails:
/bin/sh: 1: Syntax error: end of file unexpected (expecting ")")
Collapse the case into a single line with a command substitution,
then assign the result to DPKG_ARCH_ARGS. Same pattern as the
single-line if/then/fi used later.
dpkg-buildpackage doesn't know about dotnet's --runtime flag.
It uses the host arch by default, so the cross-build for arm64
produced postit_*_amd64.deb (filename mismatch with the actual
arm64 .so content inside).
The Debian-blessed way to do cross-builds is to set DEB_HOST_ARCH
via dpkg-architecture. With -aarm64, dpkg-buildpackage will:
- name the .deb postit_*_arm64.deb
- accept the amd64 host as the build environment
- run debhelper rules with the right DEB_* variables exported
The vars from dpkg-architecture have to be exported into the
same shell as dpkg-buildpackage (each make recipe line runs in
its own shell), so eval and dpkg-buildpackage are chained with
'\\' continuation.
The warning 'GNU system type aarch64-linux-gnu does not match
the CC system type x86_64-linux-gnu' is informational — it just
acknowledges that we're cross-compiling. We don't compile C, so
no CC toolchain is needed.
dpkg-buildpackage -b uses the host architecture for both naming
and packaging, ignoring dotnet's --runtime flag. The cross-build
for arm64 therefore produced postit_*_amd64.deb (with arm64 .so
inside, weird) instead of postit_*_arm64.deb. Worse, the
subsequent arm64 step then saw no arm64 .deb in /src/ and failed
with 'Missing .deb files'.
Pass -aarm64 (or -aamd64) to dpkg-buildpackage so it tags the
.deb with the right Debian architecture. Linux-arm64 dotnet
runtime publishes binaries for arm64 already; we just need the
.deb filename to match.
Caveat: this also tells dpkg-buildpackage that the build is
targeting arm64, which may cause it to look for arm64-specific
tooling. In practice for this packaging the only tool is
objcopy/strip (both disabled for the cross-build) and dpkg-shlibdeps
(which we already enable with multi-arch libc:arm64 etc.).
dpkg-buildpackage -b writes the produced .deb to the parent of
the source directory (/src/_src/.. = /src/, which is
by default). The 'mv ../postit_*.deb $POSTIT_OUT_DIR/' step was
therefore trying to move a file onto itself — every build
exited with 'mv: ... are the same file' and make exited 1.
The earlier 'rm -f ../postit_*.deb' cleanup never had anything
to remove (dpkg-deb hadn't run yet), and even if it had, the
build step would have produced a new .deb at the same path
before the mv had a chance to act.
Drop the mv entirely. Just verify the .deb is there after
dpkg-buildpackage; fail loudly if not.
The 'mv' step after dpkg-buildpackage was failing with
`mv: '../postit_1.0.6-1_amd64.deb' and '/src/_src/../postit_1.0.6-1_amd64.deb' are the same file`
because the amd64 .deb from previous CI runs (or from a partial
arm64 build that copied the leftover amd64 .deb) was still in
the source directory.
Remove any postit_*<TAG>-1*.deb, *.buildinfo, and *.changes files
before invoking dpkg-buildpackage. The fresh build then writes
to ../ without colliding with stale output.
The previous commit put an 'if ... then ... fi' block across
multiple physical lines in the Makefile recipe. make runs each
recipe line in its own shell, so the 'fi' never matched its
'if', and the parser (dash on Debian) reported
`Syntax error: end of file unexpected (expecting "fi")`.
Collapse the if/then/fi into a single line joined with ';',
joined to the surrounding lines with '\\' continuation so make
treats them as one shell command.
The previous 'mv ... || mv ... || true' chain silently masked
real build failures: when dpkg-buildpackage for arm64 aborted,
the fallback 'mv ../postit_*.deb' matched the previous run's
leftover amd64 .deb (same filename prefix 'postit_*-1') and
returned 0. The CI step exited cleanly with no arm64 .deb.
Replace the silent fallback with an explicit check that errors
out if no .deb was produced. Two-stage pattern (specific version
first, any .deb second) keeps the same matching flexibility for
both stable and pre-release tags, but the absence of a .deb now
fails the build step.
- Makefile + debian/rules: POSTIT_GIT_TAG default 1.0.0 → 1.0.6.
- CHANGELOG.md: document the 1.0.6 release (workflow rollout).
- .github/workflows/build-and-release-deb.yml: GitHub Actions workflow
that builds postit_*.deb (matrix amd64+arm64 via cross-RID .NET on
amd64 runners) from a tag pushed to this repo, validates the tag
(semver, patch-parity channel, CHANGELOG section), and publishes a
GitHub Release with both .deb as assets. Refuses to re-tag an
existing release by default (re-tag = le mal); opt-in via
workflow_dispatch + force_republish=true.
Pattern mirrors yavsc/.github/workflows/docker-publish-android.yml.
The previous override_dh_auto_build used 'git clone --branch <tag>'
which only accepts branch names. Feeding it 1.0.1-rc02 (a tag,
not yet pushed to origin) failed with 'La branche distante
1.0.1-rc02 n'a pas ete trouvee' and aborted the package build.
Switch to a 'git init + remote add + fetch --depth=1 origin <ref>
+ checkout FETCH_HEAD' sequence, which works for both branches
and tags, including local-only tags fetched via file:// (the
typical RC-staging workflow: 'git tag' on the local checkout,
then 'make POSTIT_GIT_URL=file:///... POSTIT_GIT_TAG=<tag>'
before pushing).
The fetch error now carries a diagnostic that points the operator
at the file:// override and at the missing 'git push'.
Adds tests/test-fetch-upstream.sh with four cases against the
real pazof/yavsc remote and a synthetic local repo: tag on
GitHub, branch on GitHub, .git reuse, and tag via file://.
Wired into 'make test'.
The .deb was hardcoded to 1.0.0-1 in debian/changelog regardless of
POSTIT_GIT_TAG, so 'make POSTIT_GIT_TAG=1.0.1-rc01' produced a
postit_1.0.0-1_amd64.deb (wrong name) and the trailing mv into
POSTIT_OUT_DIR silently fell back to the same wrong-name glob.
Move the version into a @VERSION@-bearing debian/changelog.in
template and render debian/changelog from it in the Makefile, before
dpkg-buildpackage runs (it reads debian/changelog during
dpkg-source --before-build, before any rule fires). debian/changelog
is .gitignored; the template is the source of truth.
debian/rules re-renders the changelog as a safety net for direct
dpkg-buildpackage invocations and adds it to override_dh_auto_clean
so partial builds leave no stale rendered file behind.
Default stays linux-x64 (the only architecture built today).
Override on the command line to target arm64 (or any other
RID supported by Avalonia 12 on Linux):
make deb POSTIT_RUNTIME=linux-arm64
The Makefile passes POSTIT_RUNTIME through to dpkg-buildpackage,
which propagates it to debian/rules, which threads it into
dotnet publish --runtime.
Note: the .deb is mono-architecture. For a multi-arch .deb,
the build must run twice (once per RID) and the resulting .debs
can be combined with dpkg-gencontrol / Multi-Arch: same.
Update README accordingly.
