mirror of
https://github.com/floccusaddon/floccus.git
synced 2026-04-25 14:16:12 +03:00
[GH-ISSUE #1699] Reproducible Builds (for IzzyOnDroid) #1130
Labels
No labels
browser-specific
bug
correctness issues
enhancement
feature: Google Drive
feature: Linkwarden
feature: git
feature: nextcloud-bookmarks
feature: tabs
feature: webdav
help wanted
native-app
priority: high
priority: low
priority: medium
pull-request
question
question
stale
upstream
waiting for more information
wontfix
🙁 Not following issue template
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/floccus#1130
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @obfusk on GitHub (Aug 19, 2024).
Original GitHub issue: https://github.com/floccusaddon/floccus/issues/1699
Describe the feature you'd like to request
At IzzyOnDroid we support Reproducible Builds (see: Reproducible Builds, special client support and more in our repo).
Your app used to be reproducible but recent versions aren't because there is an extra file in the APKs attached to your releases that is missing when building from source (and doesn't seem to be in the repository):
assets/public/icons/logo_128_white.png.We'd appreciate if you could help making your build reproducible. We've prepared some hints on Reproducible Builds.
Thank you!
cc @IzzySoft
Describe the solution you'd like
Either adding the missing file to the repo so it is included in our builds from source as well, or not including it in your release builds, should make your app reproducible again :)
Describe alternatives you've considered
N/A
@github-actions[bot] commented on GitHub (Aug 19, 2024):
Hello 👋
Thank you for taking the time to open this issue with floccus. I know it's frustrating when software
causes problems. You have made the right choice to come here and open an issue to make sure your problem gets looked at
and if possible solved.
I'm Marcel and I created floccus and have been maintaining it ever since.
I currently work for Nextcloud which leaves me with less time for side projects like this one
than I used to have.
I still try to answer all issues and if possible fix all bugs here, but it sometimes takes a while until I get to it.
Until then, please be patient.
Note also that GitHub is a place where people meet to make software better together. Nobody here is under any obligation
to help you, solve your problems or deliver on any expectations or demands you may have, but if enough people come together we can
collaborate to make this software better. For everyone.
Thus, if you can, you could also have a look at other issues to see whether you can help other people with your knowledge
and experience. If you have coding experience it would also be awesome if you could step up to dive into the code and
try to fix the odd bug yourself. Everyone will be thankful for extra helping hands!
One last word: If you feel, at any point, like you need to vent, this is not the place for it; you can go to the forum,
to twitter or somewhere else. But this is a technical issue tracker, so please make sure to
focus on the tech and keep your opinions to yourself.
I look forward to working with you on this issue
Cheers 💙
@marcelklehr commented on GitHub (Aug 19, 2024):
Oh, I didn't notice that file wasn't checked in. It's great to hear that floccus is already reproducible 🎉
@marcelklehr commented on GitHub (Aug 19, 2024):
Thank you for all your work on this 💙
@obfusk commented on GitHub (Aug 19, 2024):
Thanks for the quick fix :)
@obfusk commented on GitHub (Sep 3, 2024):
As expected, today's v5.2.7 is confirmed reproducible again and will show up with a green shield at IzzyOnDroid :)
@IzzySoft commented on GitHub (Nov 11, 2024):
@marcelklehr unfortunately, 5.3.3 no longer is RB. Diff of the APKs:
Profile differing is to be expected here as
classes.dexdiffers – and the diff in Dex is a little bigger. Are you sure you've built from a clean tree at the commit? And (as your Github workflow files state) with Node-20 and JDK-17?Diff of classes.dex
VISIBILITY_SYSTEM Ldalvik/annotation/MethodParameters; accessFlags={ 4096 4096 0 } names={ null null null }
VISIBILITY_SYSTEM Ldalvik/annotation/Signature; value={ "(" "Ljava/lang/String;" ")V" }
VISIBILITY_SYSTEM Ldalvik/annotation/MethodParameters; accessFlags={ 32768 } names={ null }
Class descriptor : 'Lcom/getcapacitor/plugin/util/MimeType;'
Access flags : 0x4010 (FINAL ENUM)
@@ -797049,7 +797104,6 @@
VISIBILITY_SYSTEM Ldalvik/annotation/EnclosingMethod; value=authenticate
VISIBILITY_SYSTEM Ldalvik/annotation/InnerClass; accessFlags=0 name=null
VISIBILITY_SYSTEM Ldalvik/annotation/MethodParameters; accessFlags={ 32784 4112 } names={ null null }
VISIBILITY_SYSTEM Ldalvik/annotation/Signature; value={ "()V" }
Class descriptor : 'Lcom/byteowls/capacitor/oauth2/OAuth2ClientPlugin$1;'
@@ -798776,7 +798830,6 @@
VISIBILITY_SYSTEM Ldalvik/annotation/EnclosingMethod; value=load
VISIBILITY_SYSTEM Ldalvik/annotation/InnerClass; accessFlags=0 name=null
VISIBILITY_SYSTEM Ldalvik/annotation/MethodParameters; accessFlags={ 32784 0 } names={ null null }
Class descriptor : 'Lcom/capacitorjs/plugins/app/AppPlugin$1;'
Access flags : 0x0000 ()
@@ -799533,7 +799586,6 @@
VISIBILITY_SYSTEM Ldalvik/annotation/EnclosingClass; value=Lcom/capacitorjs/plugins/browser/Browser;
VISIBILITY_SYSTEM Ldalvik/annotation/InnerClass; accessFlags=0 name=null
VISIBILITY_SYSTEM Ldalvik/annotation/MethodParameters; accessFlags={ 32784 } names={ null }
Class descriptor : 'Lcom/capacitorjs/plugins/browser/Browser$1;'
Access flags : 0x0000 ()
@@ -799612,7 +799664,6 @@
VISIBILITY_SYSTEM Ldalvik/annotation/EnclosingMethod; value=getCustomTabsSession
VISIBILITY_SYSTEM Ldalvik/annotation/InnerClass; accessFlags=0 name=null
VISIBILITY_SYSTEM Ldalvik/annotation/MethodParameters; accessFlags={ 32784 } names={ null }
Class descriptor : 'Lcom/capacitorjs/plugins/browser/Browser$2;'
Access flags : 0x0000 ()
@@ -800381,7 +800432,6 @@
VISIBILITY_SYSTEM Ldalvik/annotation/EnclosingMethod; value=downloadFile
VISIBILITY_SYSTEM Ldalvik/annotation/InnerClass; accessFlags=0 name=null
VISIBILITY_SYSTEM Ldalvik/annotation/MethodParameters; accessFlags={ 32784 4112 } names={ null null }
Class descriptor : 'Lcom/capacitorjs/plugins/filesystem/Filesystem$1;'
Access flags : 0x0000 ()
@@ -803437,7 +803487,6 @@
VISIBILITY_SYSTEM Ldalvik/annotation/EnclosingMethod; value=show
VISIBILITY_SYSTEM Ldalvik/annotation/InnerClass; accessFlags=0 name=null
VISIBILITY_SYSTEM Ldalvik/annotation/MethodParameters; accessFlags={ 32784 4112 } names={ null null }
VISIBILITY_SYSTEM Ldalvik/annotation/Signature; value={ "()V" }
Class descriptor : 'Lcom/capacitorjs/plugins/splashscreen/SplashScreenPlugin$1;'
@@ -804697,7 +804746,6 @@
VISIBILITY_SYSTEM Ldalvik/annotation/EnclosingMethod; value=createHostingDetails
VISIBILITY_SYSTEM Ldalvik/annotation/InnerClass; accessFlags=0 name=null
VISIBILITY_SYSTEM Ldalvik/annotation/MethodParameters; accessFlags={ 32784 4112 } names={ null null }
Class descriptor : 'Lcom/getcapacitor/WebViewLocalServer$1;'
Access flags : 0x0000 ()
@marcelklehr commented on GitHub (Nov 11, 2024):
Hey @IzzySoft Thank you for reaching out!
@marcelklehr commented on GitHub (Nov 11, 2024):
I did reinstall my computer in the meantime, so it's possible something changed. I'm not sure which JDK Android studio uses by default, on my system I have JDK 21, so I will try and rebuild using 17 and check back with you.
@IzzySoft commented on GitHub (Nov 11, 2024):
Thanks @marcelklehr! As the release is already out, I can try with 21 against that and see, give me a few minutes…
@IzzySoft commented on GitHub (Nov 11, 2024):
Eh, I feel so stupid… That was an easy solution Marcel: switching from JDK-17 on debian:bookworm to JDK-21 on ubuntu:jammy made the RB succeed! So simply stick with that, all fine here again – and following releases will run with jammy/21 automatically (as their recipes will be based on the latest previous one).
Oh, and for the books: node-22 used here, went fine.
@marcelklehr commented on GitHub (Nov 13, 2024):
Ah, that's great, thank you!
@IzzySoft commented on GitHub (Nov 30, 2024):
@marcelklehr for v5.4.0, RB failed again. Seems like you've added some Sentry debug ids which are generated at build time. APK diff:
Diff of
832.js:(lines truncated, but you already see the IDs differ)
As those
*.jsfiles are generated dynamically, I'm not sure if the same is valid for thosesentryDebugIds. If so, it is non-deterministic so Floccus won't be RB anymore unless this is removed again. If on the other hand that ID is injected via some secret, we'd need to do that on our end as well to get it RB again.I'm just trying to find out. On the way there, I notice in the logs:
Maybe set that to
false? 😉OK, build completed. Fixing up the IDs post-build worked, but the result was still not RB –
832.jswas fine then, but88.jsstill not:I've no idea what causes the additional "lines" in my build. I can wait the next run (tomorrow around 6 pm UTC) if you have an idea how to fix it on my end, but if it cannot be fixed here we'll have to let v5.4.0 fail RB and hope we get the next release RB again.
@marcelklehr commented on GitHub (Dec 1, 2024):
Hi @IzzySoft
Damn this is tough! Thanks for reaching out! I'll look into this!
@obfusk commented on GitHub (Dec 1, 2024):
That diff looks a lot like this commit made to develop after the tag:
github.com/floccusaddon/floccus@f0d82c4885@obfusk commented on GitHub (Dec 1, 2024):
Looking closer at the hex dump it looks like this commit, which I'm guessing was merged after the APK was built, causing both the diff and the ID, which is a hash of inputs, to change:
github.com/floccusaddon/floccus@3ec547802b@IzzySoft commented on GitHub (Dec 1, 2024):
Thanks @obfusk – that indeed looks like the diff from above. I've just tried to build from the commit before that, but that then results in an even much larger diff. So not RB, and I'll now have to publish it such (cannot hold back forever, especially if the chances to get it fixed are that low).
@marcelklehr what I wonder about is what you did about versionInfo (
META-INF/version-control-info.textproto) that it just says "generate_error_reason: NO_SUPPORTED_VCS_FOUND" – even for our build, which happens within the git tree. Having the commit hash in there would be quite helpful with issues like this.@IzzySoft commented on GitHub (Dec 1, 2024):
OK, found the culprit and fixed it™ – err, Fay found the culprit and let me fix it 😉
before building (to get rid of that diff), then
with a
sedfor the 2*.jsfiles. Floccus v5.4.0 is now marked RB. I forgot to put a note into the recipe as we might need to revert those changes for the next release; waiting for what @marcelklehr comes up on the sentry part (and hopefully does not build from a dirty tree again 😜).@obfusk commented on GitHub (Dec 1, 2024):
messages.jsonthey should have been identical again so theseds didn't actually modify anything.NO_SUPPORTED_VCS_FOUNDis because it only checks for.git/HEADin the root project dir, which is not the root dir of the repo in this case.@IzzySoft commented on GitHub (Dec 8, 2024):
Oof. Afraid v5.4.1 cannot even be built now:
@obfusk commented on GitHub (Dec 8, 2024):
Bad timing, probably: npm was having some issues and returning 404s during scheduled maintenance today https://status.npmjs.org/incidents/px35z3dmcjgm
@IzzySoft commented on GitHub (Dec 9, 2024):
Oof, indeed. Just tried again and…
Thanks Fay! Guess we can close this issue then?
@marcelklehr commented on GitHub (Dec 9, 2024):
Thanks folks!
@github-actions[bot] commented on GitHub (Dec 10, 2025):
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.