gokadzev/Musify

[Bug] F-Droid can't build

licaon-kter opened this issue · 46 comments

gokadzev commented

ref: https://gitlab.com/fdroid/fdroiddata/-/jobs/5803659496#L660

Thank you for informing! My bad, I released version which broke things so I had to delete as soon as possible and release new one with additional commits but I forgot to recreate tag so it has previous commit as the latest commit (which was removed with force push)

gokadzev commented

Okay I will re-release 7.1.1 again.

gokadzev commented

@licaon-kter That's it, it shouldn't have any problem anymore.

licaon-kter commented

Let me check...brb

gokadzev commented

@licaon-kter Sorry for the tagging, as its last version is 7.1.2 on F-droid, which was released a month ago. Are there any problems connected with building again?

licaon-kter commented

7.2.0 was still versionCode 77 like 7.1.2 (you forgot to bump it to 78 I guess) hence no new version detected...

gokadzev commented

7.2.0 was still versionCode 77 like 7.1.2 (you forgot to bump it to 78 I guess) hence no new version detected...

Okay, thanks.

gokadzev commented

@licaon-kter Any issue from my side?

2024-01-22 08:48:07,376 DEBUG: ..got package=None, version=None, vercode=None
2024-01-22 08:48:07,376 DEBUG: ...couldn't get autoname
licaon-kter commented 
...
2024-01-25 13:36:04,353 INFO: ...updating to version 7.4.0 (82)
2024-01-25 13:36:04,354 INFO: ...auto-generating build for 7.4.0
...

autoupdate works fine, just have patience :)

  • 👍1
licaon-kter commented

https://gitlab.com/fdroid/fdroiddata/-/jobs/6519094608#L768

oh, we need 17 now, let's add it

fail to repro? https://gitlab.com/fdroid/fdroiddata/-/jobs/6520020801#L694

Binary files libflutter.so and ... differ means that we didn't use the same Flutter version, but I see we extracted 3.19.5 just fine: https://gitlab.com/fdroid/fdroiddata/-/jobs/6520020801#L378 per https://github.com/gokadzev/Musify/blob/2024.3.31/pubspec.yaml#L12

@gokadzev which Flutter version did you use?

gokadzev commented

https://gitlab.com/fdroid/fdroiddata/-/jobs/6519094608#L768

oh, we need 17 now, let's add it

fail to repro? https://gitlab.com/fdroid/fdroiddata/-/jobs/6520020801#L694

Binary files libflutter.so and ... differ means that we didn't use the same Flutter version, but I see we extracted 3.19.5 just fine: https://gitlab.com/fdroid/fdroiddata/-/jobs/6520020801#L378 per https://github.com/gokadzev/Musify/blob/2024.3.31/pubspec.yaml#L12

@gokadzev which Flutter version did you use?

I indeed used 3.19.5, I haven't changed anything than JAVA version which you meant that you have already corrected. I have no idea what's the problem

gokadzev commented

I can try recommit the release commit and trigger the workflow to be updated release apks if you want.

licaon-kter commented

Yes, please

gokadzev commented

Yes, please

Should I change the version too? As I need to recreate the tag.

licaon-kter commented

you can tell us the commit and attach the APK here (rename as ZIP, do not archive), it's enough to test

gokadzev commented

you can tell us the commit and attach the APK here (rename as ZIP, do not archive), it's enough to test

Sorry, I don't get it. The situation is like this:

  • I can't build release apk locally witht the same key as I don't have it, Initially I created the key after creating this repository and configured it for Github workflows so I don't have it anymore.
  • Neither I can run release workflow manually as with my configuration it runs only when commit name includes certain update text.
  • I can undo commits and force-push the last two commits so it will run workflow but the problem will be unmatched commits between tag commit and release apk commit so it will give us error again. That's why I thought about recreating tag.

or we just can skip this version and add next version (In case of need, that's not a problem for me)

gokadzev commented

@licaon-kter Hi, I just remembered that I could re-run an already existing action (From the workflow run history), so it rebuilds the app with the same commit.(0dfbcbc)

gokadzev commented

Unfortunately, I tried to figure out what's the difference between fdroid workflow and github fdroid workflow, but I found nothing. Neither I can run fdroid workflow to check if the problem is solved so I guess I can nothing to do without your help.

These are the only changes I made after v2024.3.24: 2024.3.24...2024.4.5

gokadzev commented

Hi @IzzySoft, Sorry for tagging. Could you help me fix this problem?

IzzySoft commented

Sorry, but I'm no Android developer – so no. If Licaon has no clue there why a build fails, I'm even less likely to know.

But wait, it's not the build itself that fails, it's the RB check. And it's a Flutter app, plus the errors reported are in libs. That's usually either due to the embedded paths (Flutter embeds the full path into libs, and if directory structures are different thus the binaries are, too) or to different Flutter versions. I cannot tell you how to fix that, though. You two have consulted HOWTO: diff & fix APKs for Reproducible Builds already, haven't you?

gokadzev commented

Sorry, but I'm no Android developer – so no. If Licaon has no clue there why a build fails, I'm even less likely to know.

But wait, it's not the build itself that fails, it's the RB check. And it's a Flutter app, plus the errors reported are in libs.

I'm aware of it, I thought it would be more workflow problem than code itself. I'll check again by myself what happens then.

IzzySoft commented

No, no workflow issue. It's producing the APK alright, but it's not identical to yours (differences in those *.so files). Someone more familiar with reproducible builds than I am could probably get more details of it, by taking both APKs and comparing those *.so files.

@licaon-kter you or linsui were using diffoscope, that should help you with that.

gokadzev commented

Sorry, but I'm no Android developer – so no. If Licaon has no clue there why a build fails, I'm even less likely to know.

But wait, it's not the build itself that fails, it's the RB check. And it's a Flutter app, plus the errors reported are in libs. That's usually either due to the embedded paths (Flutter embeds the full path into libs, and if directory structures are different thus the binaries are, too) or to different Flutter versions. I cannot tell you how to fix that, though. You two have consulted HOWTO: diff & fix APKs for Reproducible Builds already, haven't you?

Idk if I'll be able to do it but how to get fdroid release apk to check difference

licaon-kter commented

@gokadzev we can check or you can open a MR updating the recipe and the CI will do it for you 😉

Are you ready? Which commit and where's the APK? 😛

gokadzev commented

@gokadzev we can check or you can open a MR updating the recipe and the CI will do it for you 😉

Are you ready? Which commit and where's the APK? 😛

This one, it's the latest one that failed. https://github.com/gokadzev/Musify/releases/tag/2024.4.5

@licaon-kter I'm sure flutter version is the same, I doubt about ndk version change but I'm not sure if it matters for fdroid workflow. So if it's possible please tell me how to obtain additional information about differences between above mentioned release and that one fdroid built from source

gokadzev commented

I hope I understood correctly what you've asked.

licaon-kter commented

Will test asap

One advantage of the MR is that the CI gives you an APK so you can just apktool d then diffoscope it vs yours.

gokadzev commented

@licaon-kter

Will test asap

One advantage of the MR is that the CI gives you an APK so you can just apktool d then diffoscope it vs yours.

I tried diffoscope, nothing useful.

I'd like to ask you if we can add ndk version in the fdroid workflow, I highly suspect it's the cause of fails and I changed it because one of the plugins require it to be minimum:

android {
  ndkVersion "25.1.8937393"
  ...
}
licaon-kter commented

We can add NDKs as needed yes

I've just wrote https://gitlab.com/fdroid/fdroidserver/-/issues/1207#note_1881935461 so maybe it helps too

gokadzev commented

We can add NDKs as needed yes

I've just wrote https://gitlab.com/fdroid/fdroidserver/-/issues/1207#note_1881935461 so maybe it helps too

So anything from my side that I can do?

licaon-kter commented

Added the NDK, still fails:

==== detail begin ====
verification of APK with copied signature failed
Comparing reference APK to APK with copied signature...
Unexpected diff output:
Binary files /tmp/tmp88s4me_0/unsigned_binaries_com.gokadzev.musify.fdroid_91.binary/content/lib/arm64-v8a/libapp.so and /tmp/tmp88s4me_0/_tmp_tmp88s4me_0_sigcp_com.gokadzev.musify.fdroid_91/content/lib/arm64-v8a/libapp.so differ
Binary files /tmp/tmp88s4me_0/unsigned_binaries_com.gokadzev.musify.fdroid_91.binary/content/lib/arm64-v8a/libflutter.so and /tmp/tmp88s4me_0/_tmp_tmp88s4me_0_sigcp_com.gokadzev.musify.fdroid_91/content/lib/arm64-v8a/libflutter.so differ
Binary files /tmp/tmp88s4me_0/unsigned_binaries_com.gokadzev.musify.fdroid_91.binary/content/lib/armeabi-v7a/libapp.so and /tmp/tmp88s4me_0/_tmp_tmp88s4me_0_sigcp_com.gokadzev.musify.fdroid_91/content/lib/armeabi-v7a/libapp.so differ
Binary files /tmp/tmp88s4me_0/unsigned_binaries_com.gokadzev.musify.fdroid_91.binary/content/lib/armeabi-v7a/libflutter.so and /tmp/tmp88s4me_0/_tmp_tmp88s4me_0_sigcp_com.gokadzev.musify.fdroid_91/content/lib/armeabi-v7a/libflutter.so differ
Binary files /tmp/tmp88s4me_0/unsigned_binaries_com.gokadzev.musify.fdroid_91.binary/content/lib/x86_64/libapp.so and /tmp/tmp88s4me_0/_tmp_tmp88s4me_0_sigcp_com.gokadzev.musify.fdroid_91/content/lib/x86_64/libapp.so differ
Binary files /tmp/tmp88s4me_0/unsigned_binaries_com.gokadzev.musify.fdroid_91.binary/content/lib/x86_64/libflutter.so and /tmp/tmp88s4me_0/_tmp_tmp88s4me_0_sigcp_com.gokadzev.musify.fdroid_91/content/lib/x86_64/libflutter.so differ
==== detail end ====

... libflutter.so differ means we didn't use the same Flutter version

can you share the output of running flutter doctor -v ?

gokadzev commented

Added the NDK, still fails:

==== detail begin ====
verification of APK with copied signature failed
Comparing reference APK to APK with copied signature...
Unexpected diff output:
Binary files /tmp/tmp88s4me_0/unsigned_binaries_com.gokadzev.musify.fdroid_91.binary/content/lib/arm64-v8a/libapp.so and /tmp/tmp88s4me_0/_tmp_tmp88s4me_0_sigcp_com.gokadzev.musify.fdroid_91/content/lib/arm64-v8a/libapp.so differ
Binary files /tmp/tmp88s4me_0/unsigned_binaries_com.gokadzev.musify.fdroid_91.binary/content/lib/arm64-v8a/libflutter.so and /tmp/tmp88s4me_0/_tmp_tmp88s4me_0_sigcp_com.gokadzev.musify.fdroid_91/content/lib/arm64-v8a/libflutter.so differ
Binary files /tmp/tmp88s4me_0/unsigned_binaries_com.gokadzev.musify.fdroid_91.binary/content/lib/armeabi-v7a/libapp.so and /tmp/tmp88s4me_0/_tmp_tmp88s4me_0_sigcp_com.gokadzev.musify.fdroid_91/content/lib/armeabi-v7a/libapp.so differ
Binary files /tmp/tmp88s4me_0/unsigned_binaries_com.gokadzev.musify.fdroid_91.binary/content/lib/armeabi-v7a/libflutter.so and /tmp/tmp88s4me_0/_tmp_tmp88s4me_0_sigcp_com.gokadzev.musify.fdroid_91/content/lib/armeabi-v7a/libflutter.so differ
Binary files /tmp/tmp88s4me_0/unsigned_binaries_com.gokadzev.musify.fdroid_91.binary/content/lib/x86_64/libapp.so and /tmp/tmp88s4me_0/_tmp_tmp88s4me_0_sigcp_com.gokadzev.musify.fdroid_91/content/lib/x86_64/libapp.so differ
Binary files /tmp/tmp88s4me_0/unsigned_binaries_com.gokadzev.musify.fdroid_91.binary/content/lib/x86_64/libflutter.so and /tmp/tmp88s4me_0/_tmp_tmp88s4me_0_sigcp_com.gokadzev.musify.fdroid_91/content/lib/x86_64/libflutter.so differ
==== detail end ====

... libflutter.so differ means we didn't use the same Flutter version

can you share the output of running flutter doctor -v ?

run: https://github.com/gokadzev/Musify/actions/runs/8568008460/job/23480973634

image

IzzySoft commented

... libflutter.so differ means we didn't use the same Flutter version

If you've ruled out Flutter's embedded build path that is, see here.

licaon-kter commented

@IzzySoft the paths are in the built libapp.so files, and we take care of the paths too: https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/com.gokadzev.musify.fdroid.yml#L1011-L1015

now, of course there's the possibility that @gokadzev changed their local paths, but, I want to see libflutter.so being fixed first

@gokadzev wow, so same Flutter version indeed :(

gokadzev commented

@licaon-kter I reverted one commit (which provided native support for splitting per ABI). I can't check today if it will match the F-Droid build (the one it will generate in the future), right? Since it synchronizes after a few days.

licaon-kter commented

We can test, if we know the exact commit and have an APK built from that commit to compare against

licaon-kter commented

Was just published, yes ;)

gokadzev commented

Was just published, yes ;)

This time, F-Droid updated the workflow file, but CI has never run for V8.

gokadzev commented

@gokadzev I can see the CI here: https://gitlab.com/fdroid/fdroiddata/-/jobs/6784392431

and its artefacts: https://gitlab.com/fdroid/fdroiddata/-/jobs/6784392431/artifacts/browse/tmp/

what do you mean?

Neither I wasn't able to find CI nor its update on Fdroid so I thought it was skipped.

licaon-kter commented

Checkupdate job batches multiple apps, so if one app that should build before your app fails then the pipeline is stopped and your app is not tried. It's a possibility. :)

gokadzev commented

Checkupdate job batches multiple apps, so if one app that should build before your app fails then the pipeline is stopped and your app is not tried. It's a possibility. :)

In this case my app was built correctly, I didn't get your point.

licaon-kter commented

I just informed you that, even if in this case it was ok, sometimes it might not