[Bug]: F-Droid can't build

[licaon-kter]

在使用的时候发生了什么 Bug ？

Binary files /tmp/tmplkk02w5i/tmp_binaries_com.predidit.kazumi_105072.binary/content/lib/arm64-v8a/libflutter.so and /tmp/tmplkk02w5i/_tmp_tmplkk02w5i_sigcp_com.predidit.kazumi_105072/content/lib/arm64-v8a/libflutter.so differ

sounds like the Flutter version used to build your APK does not match the one in the submodule

ref: https://gitlab.com/fdroid/checkupdates-bot-fdroiddata/-/jobs/9137318111#L6266

您在使用哪个操作系统？

Android

请具体提供设备、版本号等信息。

（选填）一些与 Bug 相关的硬件信息。

No response

日志信息

-

提交前确认

• issue 列表中，没有我发现的这个 Bug
• 我正在使用最新版本的 Kazumi

[Predidit]

This issue is very strange. We indeed synchronized the git submodules before releasing the new version. Currently, flutter is at commit 35c388afb57ef061d06a39b537336c87e0e3d1b1, which is the same as the stable branch in the official flutter repository. Our build script outputs the SDK version during the build, and both Gitlab CI and GitHub Actions report version 3.29.0.

@ErBWs

What do you think about this issue? Should we try using srclib instead?

[ErBWs]

I really don't know how this happened. Since commit id is the same I don't think using srclib can solve this problem, there should be some other reasons

[Predidit]

@licaon-kter

Seems that 1.5.6 build failed too. I can't find it on F-Droid.

Could we get the build logs for version 1.5.6? That way, we can see what happened and whether it's related to the current error.

[licaon-kter]

1.5.6 built fine, will be published soon: https://monitor.f-droid.org/builds/log/com.predidit.kazumi/105062#site-footer

and the CI at update time: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/19393/pipelines

[Predidit]

@ErBWs

I think maybe it's related to flutter monorepo.

Seems that flutter don't have independent flutter/engine repo any more since 3.28 beta.

Let's try using srclib as part of our debugging process.

[ErBWs]

https://gitlab.com/fdroid/fdroiddata/-/jobs/9141863246#L6313

@Predidit I think this is a flutter side issue

[licaon-kter]

from a chat with @linsui

how about we use submodules BUT instead of using the CI provided Flutter you use the submodule Flutter to build too?

[licaon-kter]

here: https://github.com/Predidit/Kazumi/blob/main/.github/workflows/release.yaml#L52

use: run: fastlane/.flutter/flutter build apk --split-per-abi or something

[Predidit]

I don't think this approach is appropriate, as it contradicts the purpose of the fastlane folder. In my view, the files in fastlane should only affect Android builds, and this could lead to discrepancies between GitHub CI and our development environment. I am trying to track down the origin of libflutter.so—it appears to be a prebuilt binary from Google.

[ErBWs]

I've suggested this operation here.

#587 (comment)

but we've tried using submodule and srclib in metadata and both failed, I think it will not make any difference

[linsui]

When we run flutter from the flutter repo, it should automatically fetch the flutter package with corresponding version. But it fetches a wrong version for flutter 3.29.0. I'm not sure why this happens yet.

[Predidit]

We should be able to retrieve detailed information about the Flutter version currently in use within GitLab CI, just like this.

1896673

https://github.com/Predidit/Kazumi/actions/runs/13331237800/job/37235617435

[licaon-kter]

as it contradicts the purpose of the fastlane folder.

who forces you to put something in the fastlane folder? not sure I follow 😄

as said, we need both CIs, yours and ours, to run with the same Flutter, and the best way is to run from the folder that you control

not F-Droid srclib, nor Github image random version

[ErBWs]

In flutter repo, branch stable's commit was completely changed when 3.29.0 is released. I cannot simply use git pull to update my local environment. Don't know what happened to it. Though I think it's not the reason.

[linsui]

The problem is that running flutter from https://github.com/flutter/flutter somehow doesn't get the correct version. I doubt that google messed up it somehow. And I just found that the file used to keep the version of the engine was added to gitignore in flutter/flutter@721b47e. Not sure if this is related.

[ErBWs]

We checkout to 3.29.0 here https://gitlab.com/fdroid/fdroiddata/-/jobs/9141863246#L756

Github action also checkout repo in this script
https://github.com/subosito/flutter-action/blob/ce3cf2160d822f73fcb0cf0a8fb549a85e464eab/setup.sh#L222

And this is the 3.29.0 tag

Just weird.

[linsui]

I thought this is an upstream bug so I created flutter/flutter#163308.

[Predidit]

I will migrate to submodules in Github Actions.

But I think it's an error from flutter team. Maybe we can open a issue.

[ErBWs]

https://github.com/Predidit/Kazumi/actions/runs/13331237800/job/37235617435#step:7:14

https://gitlab.com/fdroid/fdroiddata/-/jobs/9141863246#L771

Looks like flutter engine diffs

[Predidit]

We checkout to 3.29.0 here https://gitlab.com/fdroid/fdroiddata/-/jobs/9141863246#L756

Github action also checkout repo in this script
https://github.com/subosito/flutter-action/blob/ce3cf2160d822f73fcb0cf0a8fb549a85e464eab/setup.sh#L222

And this is the 3.29.0 tag

Just weird.

subosito/flutter-action only checkout to 3.29.0 tag when channel has been set to master

https://github.com/subosito/flutter-action/blob/ce3cf2160d822f73fcb0cf0a8fb549a85e464eab/setup.sh#L218

I think it makes difference. subosito/flutter-action using stable branch rather than tag 3.29.0 on master branch.

[ErBWs]

Looks like flutter team messed up something when cherry_picking, just take a look at the commit history in branch stable.

And we were using this action in a wrong way all the time.

[Predidit]

I don't think we are using the action in wrong way.

Indeed, branch stable has the same binary with our local environment, and newer flutter engine.

Tag 3.29.0 on branch stable should same with branch master. But seems that Google broken that.

If we migrate to tag 3.29.0, we will get outdated flutter engine in github actions.

[ErBWs]

no, I mean we used channel and flutter-version-file options at the same time, apparently it conflicts and flutter-version-file is not used

with channel: stable option, we download sdk from archive instead of git source

and I need to draw another PR to fix subosito/flutter-action#334

update: yes you are right, flutter-version-file is taking effect, it is used here https://github.com/subosito/flutter-action/blob/ce3cf2160d822f73fcb0cf0a8fb549a85e464eab/setup.sh#L153

[ErBWs]

flutter/flutter#163198 (comment)

It seems that checkout to flutter/flutter@f73bfc4 can be a workaround.

but I don't know how to achieve this right now since we have pushed some commits to repo that will break libapp.so

[Predidit]

In my view, if we want to fix 1.5.7 build. We need srclib and check out to correct commit. (of course, we will migrate back to submodules in kazumi 1.5.8)

Tag 1.5.7 on kazumi repo has pin flutter submodules to wrong commit. I think flutter team may re-tag 3.29.0 on branch master.

If they do that. We need update git submodules, and it will not affect tag 1.5.7 on kazumi repo. I really don't want to re-tag 1.5.7. We have serval commits since 1.5.7.

[linsui]

We can skip 1.5.7 and wait for the flutter fix. :)

[licaon-kter]

Will follow the Flutter fix