[Bug] F-Droid can't build

[licaon-kter]

ref: https://monitor.f-droid.org/builds/log/com.w2sv.filenavigator/5#site-footer

so looks like you tagged https://github.com/w2sv/FileNavigator/releases/tag/0.1.0 from https://github.com/w2sv/FileNavigator/commit/d1602474ec5f5f3439777f1e8384a9eac75b0079

but the APK was built from 3ffc571250e85f39cce517c3d8d337083f3c85c8

yet if I build from that

==== detail begin ====
verification of APK with copied signature failed
Comparing reference APK to APK with copied signature...
Unexpected diff output:
Binary files /tmp/tmp1hkqq9hy/unsigned_binaries_com.w2sv.filenavigator_5.binary/content/assets/dexopt/baseline.prof and /tmp/tmp1hkqq9hy/_tmp_tmp1hkqq9hy_sigcp_com.w2sv.filenavigator_5/content/assets/dexopt/baseline.prof differ
Binary files /tmp/tmp1hkqq9hy/unsigned_binaries_com.w2sv.filenavigator_5.binary/content/classes.dex and /tmp/tmp1hkqq9hy/_tmp_tmp1hkqq9hy_sigcp_com.w2sv.filenavigator_5/content/classes.dex differ
==== detail end ====

/LE: fyi https://gitlab.com/fdroid/fdroiddata/-/commit/e83b9f17de7b787ce3877c07794e8014012e9483

[w2sv]

I think it was the other way around, I built the APK from d160247, then my Make publishing routine threw an error during the upload to the playstore, because the release notes were too long, so I changed them and thereupon tagged the release from 3ffc571. I don't know how that could possibly impact the generated baseline profile or the dex classes, though.

[w2sv]

I could simply create a new release, I have one at the ready anyways. Would that be a valid workaround? :D

[licaon-kter]

Please do

[w2sv]

Done: https://github.com/w2sv/FileNavigator/releases/tag/0.1.1

[licaon-kter]

you tagged https://github.com/w2sv/FileNavigator/releases/tag/0.1.1 from 8ee0e8060c30075c4cefb66a16330c6594fa0758

but you built from 6f5a0ab3fafb0979f39a2e26ae00a1606cc2e799

diff -r /tmp/tmprxk9qcuj/unsigned_binaries_com.w2sv.filenavigator_6.binary/content/META-INF/version-control-info.textproto /tmp/tmprxk9qcuj/_tmp_tmprxk9qcuj_sigcp_com.w2sv.filenavigator_6/content/META-INF/version-control-info.textproto
4c4
<   revision: "6f5a0ab3fafb0979f39a2e26ae00a1606cc2e799"
---
>   revision: "8ee0e8060c30075c4cefb66a16330c6594fa0758"

[w2sv]

Uff...

[w2sv]

Next try I guess: https://github.com/w2sv/FileNavigator/releases/tag/0.1.2

Sorry...

[licaon-kter]

thanks https://gitlab.com/fdroid/fdroiddata/-/commit/f6dac050273af7328b94b34a5fd0febb96602c27

[w2sv]

Thank you.

[licaon-kter]

you tagged https://github.com/w2sv/FileNavigator/releases/tag/0.3.0 from https://github.com/w2sv/FileNavigator/commit/32b9e610931c343e8a9bf719b5c48de71df3cefd

but the APK was built from a newer commit c7552b4d267c5b3df2b9765a6e8e54dd4e12571c ? I see this in https://gitlab.com/fdroid/checkupdates-bot-fdroiddata/-/jobs/10001578356#L637

now, I update the recipe to that commit but still fails... :( https://gitlab.com/fdroid/fdroiddata/-/jobs/10001989501

[w2sv]

Yeah not sure what happened there. I created the release at the end of a long day full of programming, I wasn't at my mentally freshest anymore, sorry 🙃

I guess I'll just create a new release, that should probably fix it. Do I need to increment the version/versionCode for that?

[licaon-kter]

that's up to you

[w2sv]

I created a release 0.3.0.1. Hopefully that fixes it.

[licaon-kter]

difflog: nope :(

com.w2sv.filenavigator_15.log

[linsui]

Can you clean the cache and rebuild the apk?

[IzzySoft]

Though release 0.3.0.1 now is already distributed, so this would need a fresh release to reach everyone (and yes, reproducible build failed at IzzyOnDroid as well, diffs suggest a "dirty build" as @linsui just pointed out (so make sure to run clean before your next release build).

[w2sv]

I used a Makefile routine that does in fact run a clean to build and publish 0.3.0.1, I'm still not sure what might have gone wrong there. In any case, I recently released 0.3.1, maybe that just did the trick?

[IzzySoft]

Unfortunately not. Huge differences in the dex files.

  -rw-r--r--  0.0 unx      120 b-      118 defN 1981-01-01 01:01:02 0137786e META-INF/version-control-info.textproto
- -rw-r--r--  0.0 unx    10126 b-    10126 stor 1981-01-01 01:01:02 41b6ce72 assets/dexopt/baseline.prof
- -rw-r--r--  0.0 unx      432 b-      432 stor 1981-01-01 01:01:02 c704b308 assets/dexopt/baseline.profm
- -rw-r--r--  0.0 unx  1749580 b-  1749580 stor 1981-01-01 01:01:02 074bdd5f classes.dex
- -rw-r--r--  0.0 unx  2029028 b-  2029028 stor 1981-01-01 01:01:02 208efc92 classes2.dex
+ -rw-r--r--  0.0 unx    10127 b-    10127 stor 1981-01-01 01:01:02 a1332523 assets/dexopt/baseline.prof
+ -rw-r--r--  0.0 unx      432 b-      432 stor 1981-01-01 01:01:02 939d440f assets/dexopt/baseline.profm
+ -rw-r--r--  0.0 unx  1749580 b-  1749580 stor 1981-01-01 01:01:02 be0c6e52 classes.dex
+ -rw-r--r--  0.0 unx  2029252 b-  2029252 stor 1981-01-01 01:01:02 aeb080cf classes2.dex
  -rw-r--r--  0.0 unx    10096 b-    10096 stor 1981-01-01 01:01:02 9734baa0 lib/arm64-v8a/libandroidx.graphics.path.so

(the diff of classes.dex is about 200 kB, for classes2.dex it's even 1.3 MB)

But if you indeed used that routine, that should rule out "remaining artifacts from previous builds" – as well as "local changes" if it runs from a Github action – though I do not see a matching one (the only action I could find does a debug build).

I've tried with JDK 17 and 21, results are identical for both builds – but not matching yours. Where do you run your builds, also how many cores (just to rule out it's the "good old" core mismatch)? Would it be an option to build using a Github action (no need to sign the APK here, that can be done locally then)? This would then give us results from a "known environment".

[w2sv]

First off thank you very much for the time you're investing in helping me @IzzySoft, I appreciate that.

I'm building on my local machine that is equipped with a Intel® Core™ i7-13850HX, which seems to have 20 cores and 28 threads. I'm indeed not building/releasing via a Github action, but I can certainly set up one to do that. I'll get back to you.

[IzzySoft]

which seems to have 20 cores and 28 threads

Urn… Afraid we cannot match that on a machine with 16 cores…

I'm indeed not building/releasing via a Github action, but I can certainly set up one to do that.

That'd be great! That environment we mostly can match.

[w2sv]

Alright I got it: https://github.com/w2sv/FileNavigator/releases/tag/0.3.1.1 Here is the workflow that created the release.

Fingers crossed for it to work 🤞

[licaon-kter]

the APK in https://github.com/w2sv/FileNavigator/releases/tag/0.3.1.1 appears unsigned 🤷

[IzzySoft]

And has the same versionCode as 0.3.1 already had, so:

repo/com.w2sv.filenavigator_16.apk already exists; ignoring update for com.w2sv.filenavigator, versionCode 16 already present

🤷‍♂

[IzzySoft]

@w2sv ^^ we'll demote your app to monthly update checks now, else the APK is pulled in each day just to be thrown away again. Might have to disable updates altogether if you cannot fix it 🙈

[IzzySoft]

@w2sv any chance for this to be addressed – or should we disable update check altogether? Do you still maintain this app? No offense meant, just asking for orientation.

[w2sv]

@IzzySoft Yes I'm absolutely still maintaining it, I was just dedicating my rather limited dev time to other projects. I'll try to create a new release from Github actions over the course of the week. Sorry for the ghosting!

[IzzySoft]

Thanks @w2sv! Please give us a ping here when that new release is available.