F-Droid build failed

[linsui]

admin-ch/CovidCertificate-SDK-Android#47 replaced module with jar. How to build the jar from source? When will it be available in Maven Central? Thanks!

[linsui]

CovidCertificate-SDK-Android has remove the jar in master. I guess the submodule will be updated in next version?

[goebelUB]

See the discussion here.
v2.1.1 has the JAR removed since it has landed on Maven in the meantime.
F-Droid can simply disable v2.1.0 (I see that the bot has already picked up v2.1.1. anyway).

[linsui]

2.1.1 still has the jar. Do you mean I can simply remove the jar?

[goebelUB]

Sorry for the delayed response, I was off my keyboard.

You are right, it looks like we removed the dependency on the jar in 2.1.1 but did not bump the submodule to after the commit that removed the jar. Sorry about that.

One could remove the jar and it should build and run fine. However as the F-Droid builds are currently configured to be reproducible, publishing still wouldn't work, would it?

[linsui]

I'm not sure if the reproducible build works with that. I didn't test. But it's likly break the reproducible build. So the next version will build without problem and we can just wait?

[goebelUB]

I will make sure that the JAR is correctly removed before the next release. It should have been in 2.1.1, I'm sorry I didn't catch it. So yes, waiting is likely the easiest option. The next release is scheduled for next Monday (i.e. push to Github and thus F-Droid bot slightly earlier).

[linsui]

2.2.0 build but not verified.

See https://gitlab.com/linsui/fdroiddata/-/jobs/1456033351 and https://gitlab.com/linsui/fdroiddata/-/jobs/1455373609

[goebelUB]

That's annoying, I'll look into it. Here's the diffoscope.txt between the unsigned F-Droid apk and our signed release, in case anybody wants to poke around as well.

[obfusk]

@goebelUB I was just planning to look into that. thx.

Looks like you ran into TeamNewPipe/NewPipe#6486 :(

Maybe you can get Google to fix that.

[obfusk]

@linsui we could let the fdroidserver build the app a few times. There's a reasonable chance it will produce a variant that matches the official release one of those times if it's indeed the same bug.

[linsui]

That will take a long time. We can rerun the CI several times.

[obfusk]

That will take a long time.

Yes :(

We can rerun the CI several times.

That will allow us to confirm a reproducible build is possible, but it won't prevent it from still being able to fail randomly on the actual buildserver.

[linsui]

2300 also failed.

[obfusk]

Getting the coreLibraryDesugaring bug fixed -- assuming that's still the problem (which seems likely, but I haven't checked with diffoscope) -- might take a while.

We could consider switching to "normal" F-Droid builds (signed with our key) instead of publishing the reference binary (when it's reproducible). That would allow users to update to a newer version (though they'd have to reinstall the app).

[obfusk]

The bug may have been fixed, but the r8 -dev version with the fix is only available in google's maven repo for now, which is not acceptable for f-droid (since it's not guaranteed to only contain FOSS).

[obfusk]

It looks like there are 2 bugs (see the issue I linked earlier).

The first one affected 2.2.0 (built but not verified), but no longer seems to affect 2.3.0.
The second one does affect 2.3.0 (but did not affect 2.2.0 apparently).

The second bug seems to be fixed by setting minSdkVersion back to 24.

[obfusk]

The version currently in F-Droid is no longer able to verify certs. Is this b/c it's outdated?

[goebelUB]

A fresh install of v2.0.0 from F-Droid still works for me (modulo certificate light which was added later).

Just FYI: I'm also following the related issues (Google, NewPipe, CCTG). Currently I'd prefer to wait to see if we can get the determinism back, rather than switching to F-Droid signing :/

[obfusk]

A fresh install of v2.0.0 from F-Droid still works for me (modulo certificate light which was added later).

Huh. A fresh install does indeed work. Before that I got "validity could not be determined" (even after clearing storage and re-importing the cert).

Just FYI: I'm also following the related issues (Google, NewPipe, CCTG). Currently I'd prefer to wait to see if we can get the determinism back, rather than switching to F-Droid signing :/

That would be ideal (as long as the current version still works).

[obfusk]

@goebelUB have you tested the latest R8 -dev version as suggested in the Google issue? It seems to have significantly decreased the size of the diff for CCTG. I only tested w/ the most recent published R8 (which does seem to help w/ NewPipe).

[dR3b]

It would be nice if a new version would slowly become available on F-Droid.

[goebelUB]

@obfusk Sorry for the late reply. To update you:
I haven't tested Google's suggestion myself, but @simonroesch has and it seems to have helped. v2.5 now uses the R8 version from Google rather than the local toolchain.

I know this still doesn't fix it for F-Droid since it comes from the other repo, but we included it anyway since reproducibility is a requirement we like to have, independently of F-Droid (e.g. SwissCovid is reproducible but not officially on F-Droid). I'll continue to look for a solution to this, but suggestions are always welcome!

[goebelUB]

Also a sidenote on reproducibility, in case someone comes across a similar issue:
other than the nondeterministic classes.dex, the PNG generation was also sometimes nondeterministic. Just disabling it works, since our minSdk is large enough to just work with vector drawables (f2fcee6).

[goebelUB]

Closing in favour of #260.