Reproducible Build for v0.9.9 failed

[IzzySoft]

Not sure what the APK was built from – but seems it was neither from the tagged commit – nor from the one that followed, but seems to have been between the two. Your APK contains a

<action android:name="ACTION_COMPLETE"/>

which was only added with the commit following the tagged one – but building from that commit, failed entirely:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':react-native-alarm-notification:compileReleaseJavaWithJavac'.
> Compilation failed; see the compiler output below.
  Note: Recompile with -Xlint:deprecation for details.
  /home/runner/work/Mindwtr/Mindwtr/apps/mobile/node_modules/react-native-alarm-notification/android/src/main/java/com/emekalites/react/alarm/notification/AlarmReceiver.java:95: error: cannot find symbol
                              NotificationOpenPayloadStore.cache(pendingPayload);
                              ^
    symbol:   variable NotificationOpenPayloadStore
    location: class AlarmReceiver
  Note: Some input files use or override a deprecated API.
  /home/runner/work/Mindwtr/Mindwtr/apps/mobile/node_modules/react-native-alarm-notification/android/src/main/java/com/emekalites/react/alarm/notification/AlarmReceiver.java:14: error: package tech.dongdongbh.mindwtr.notificationopenintents does not exist
  import tech.dongdongbh.mindwtr.notificationopenintents.NotificationOpenPayloadStore;
                                                        ^
  2 errors

So we have to declare this release "failed" at IzzyOndroid, sorry. Please make sure to always build from a clean tree at the tagged commit.

I still wonder how such a thing can happen when using a GitHub Action, which should always make a clean checkout at a commit – and the embedded path in your APK seems to indicate it indeed WAS built using a GHA. But differences are quite a few between our builds of this release… Did something change in the build recipe? A quick check:

• NodeJS was updated at our end to v24.16.0 meanwhile – but that should not be the cause
• you seem to have an additional Resolve versions step in your GHA

But that seems to be mostly it. As whenever you change your GHA, we have to adjust – maybe you'd consider putting your embedded scripts into *.sh files to be executed, so we could call those? Then any changes you apply to those scripts, would also automatically be reflected at our side.

So please let us know if we have to adjust our build recipe – ideally before the next release fails as well.

Thanks in advance!

---

Ah, there we go. The release build must have been made by this action, which was run on commit 0a56f35 – while the release points to 857233d (but then, there were changes to your GHA, so no need that I try that again).

OK, I hold back the results for 24h in the hope you can tell us what to update in our recipe to match your build:

        build:
          - git checkout 0a56f351fb007545378f80c012c3cebb3ce6f5a5
          - wget -q -O /tmp/nodejs-lts.tar.xz -- https://nodejs.org/dist/v24.16.0/node-v24.16.0-linux-x64.tar.xz
          - sha256sum -c <<< 'd804845d34eddc21dc1092b519d643ef40b1f58ec5dec5c22b1f4bd8fabde6c9  /tmp/nodejs-lts.tar.xz'
          - tar xf /tmp/nodejs-lts.tar.xz -C /opt
          - export PATH="${PATH}:/opt/node-v24.16.0-linux-x64/bin"
          - base64 -d > sedo <<< ZXhwb3J0IERST1BCT1hfQVBQX0tFWT0iN29iODJ6ZzBseDBhcmtwIgo=
          - source sedo
          - npm ci --workspaces=false --legacy-peer-deps --no-audit --no-fund --prefix packages/core
          - bash apps/mobile/scripts/fdroid_prep.sh
          - npm ci --workspaces=false --legacy-peer-deps --no-audit --no-fund --prefix apps/mobile
          - FOSS_BUILD=1 SKIP_FDROID_PREP=1 ARCHS=arm64-v8a bash apps/mobile/scripts/android_build.sh

[dongdongbh]

Thanks for catching this. You are right: the v0.9.9 FOSS APK currently attached to the release was not built from the v0.9.9 tag.

I made a mistake after finding that the tagged FOSS build had a crash: I patched the FOSS build on main and uploaded the APK from the successful GitHub Actions run at 0a56f35 onto the existing v0.9.9 release. The v0.9.9 tag itself points at 857233d, so that asset is not reproducible from the tagged source. I should not have replaced a release APK with an artifact from a later commit.

Please skip/mark v0.9.9 as failed for IzzyOnDroid reproducible-build distribution. I will treat v0.9.9 FOSS as superseded and make sure the next public FOSS APK is built from the exact tag it is released under.

No build recipe adjustment is needed for v0.9.9; it should be skipped. Sorry for the trouble, and thanks for holding the result while checking this.

[IzzySoft]

I should not have replaced a release APK with an artifact from a later commit.

Yupp. Correct approach would have been adding a newer maintenance release (with versionCode increased, and versionName reflecting that – e.g. making it v0.9.9.1; though semantic versioning only has major.minor.patch, such a situation justifies a 4th element).

Please skip/mark v0.9.9 as failed for IzzyOnDroid reproducible-build distribution.

As the release was already published, this leaves 2 options then:

• calling it back (removing it again)
• leaving it up, but marking it "RB failed"

Which variant shall we take?

No build recipe adjustment is needed for v0.9.9; it should be skipped.

Good to know! Please let me know in case this should change. Further, it might be a good idea to move those "embedded scripts" into "scripts stored in the git repo", which are then called: from your GitHub action, as well as by our recipe. That way, when you need to make adjustments (then inside the scripts), those adjustments would automatically be reflected by our build. Candidates for this:

• Install core dependencies => scripts/ci/install_core_dependencies.sh
• Install mobile dependencies => scripts/ci/install_mobile_dependencies.sh

Probably also the rather large Sign FOSS APK with release key and the following "Verify FOSS permission cleanup", to make the workflow easier to read – but that would not be something someone else would need to call anyway.

So please let me know if we should "pull out" v0.9.9 – or keep it marked "failed".

[dongdongbh]

Thanks. Please pull out / call back v0.9.9 from IzzyOnDroid if that is possible, rather than keeping it listed as "RB failed".

I have already withdrawn the GitHub FOSS asset: mindwtr-0.9.9-foss.apk has been removed from the v0.9.9 release, and the release notes now mark the Android FOSS asset as withdrawn/superseded with the tag/commit mismatch documented. The regular GitHub release remains for the other platform artifacts, but v0.9.9 should not be distributed through IzzyOnDroid.

If you need to keep an internal failed-RB note for audit/history, that is fine, but the distribution choice should be to pull out/remove v0.9.9.

And yes, a v0.9.9.1-style maintenance release with an increased versionCode would have been the correct way to publish the patched FOSS build. Sorry again for the trouble.

No recipe adjustment is needed for v0.9.9. For the next FOSS release, I will make sure the APK is built from the exact tag. I also agree with the script suggestion; moving the dependency-install steps into versioned repo scripts should make your recipe and GitHub Actions share the same commands and reduce drift.

[dongdongbh]

Follow-up: I moved the two dependency-install blocks into versioned repo scripts in a76589f.

For the next FOSS release, your recipe can replace the two inline npm ci --prefix ... commands with:

bash scripts/ci/install_core_dependencies.sh
bash apps/mobile/scripts/fdroid_prep.sh
bash scripts/ci/install_mobile_dependencies.sh

This does not change anything for v0.9.9, which should still be pulled/skipped. It just makes the next tagged recipe easier to keep aligned with the GitHub Actions workflow.

[IzzySoft]

Please pull out / call back v0.9.9 from IzzyOnDroid if that is possible, rather than keeping it listed as "RB failed".

Thought so. Update running as I write this.

If you need to keep an internal failed-RB note for audit/history, that is fine

Nope, no need. The APK is no longer there, so none of our updater will find it. As the APK was present in our repo, even just for a few ours, it's recorded with our "binary transparency log", though. That can't be helped, as (like our RBs), that log is append-only.

And yes, a v0.9.9.1-style maintenance release with an increased versionCode would have been the correct way to publish the patched FOSS build. Sorry again for the trouble.

We're all constantly learning 😉 So please keep this idea should a comparable situation come up in the future.

No recipe adjustment is needed for v0.9.9.

Nope, as we don't even have it 🙈

For the next FOSS release, I will make sure the APK is built from the exact tag. I also agree with the script suggestion; moving the dependency-install steps into versioned repo scripts should make your recipe and GitHub Actions share the same commands and reduce drift.

🤗

For the next FOSS release, your recipe can replace …

Thanks! I've added a FIXME note to the recipe (that keeps the next build from running automatically, instead it will drop me a note so I can adjust the recipe, avoiding an unnecessary build run).

If you can drop me a note here once that release is up, it would be appreciated 🤗

OK, meanwhile the index update is through, and the sync has started: 0.9.9 will now be replaced by 0.9.8 (until the next release becomes available). … Finished, it's replaced now. Secondary mirrors might take a little longer (they pull at timed events), though – primaries already got it (pushed).

[dongdongbh]

@IzzySoft v0.9.10 is released now: https://github.com/dongdongbh/Mindwtr/releases/tag/v0.9.10

The corrected v0.9.10 tag points at 0d4eca8, and the GitHub Actions Android FOSS build completed successfully from that tag.

For the reproducible-build recipe, please use the versioned repo scripts in this order: bash scripts/ci/install_core_dependencies.sh, bash apps/mobile/scripts/fdroid_prep.sh, then bash scripts/ci/install_mobile_dependencies.sh before running the FOSS Android build. This should keep the downstream recipe aligned with the release workflow instead of copying workflow-local install commands.

[IzzySoft]

So I can put a note to our recipe that the line with these exports can be removed with the next release, as they have been incorporated with the scripts already called? 🤗

[dongdongbh]

@IzzySoft yes. For the next tagged release after e47d485, you can remove the temporary export line from the recipe, as long as the recipe still invokes the FOSS build through:

FOSS_BUILD=1 SKIP_FDROID_PREP=1 ARCHS=arm64-v8a bash apps/mobile/scripts/android_build.sh

Those defaults now live in apps/mobile/scripts/android_build.sh and are exported before npx expo prebuild when FOSS_BUILD=1:

• DONATION_PROMPT_ENABLED=true
• FEEDBACK_ENDPOINT_URL=https://mindwtr-feedback.mindwtr.workers.dev

For v0.9.10 itself, please keep the explicit export because that tag predates the script default. The cleanup applies from the next release onward.

[IzzySoft]

Thanks! FIXME note added for the next release.

Btw, I see the IzzyOnDroid badge is still missing from the Readme. Maybe you want to add it? See Badges & Shields for available options (Download and RB shields are available, too).

[dongdongbh]

Added the IzzyOnDroid badge.

[IzzySoft]

Thanks! 🤗