Gedsh
Pin more deps versions
...in https://github.com/Gedsh/InviZible/blob/master/tordnscrypt/libs/prebuild#L5-L18
as you seem to update to specific versions like https://github.com/Gedsh/InviZible/commit/1a537f122a95e00f3895863dbd3206e04d65a763 but the prebuild file has generic master braches mentioned
All master, prod, etc branches are from my forks so InviZible can use the latest fixes. Sometimes it takes months to wait for a tag. The exact same versions are used in my beta and stable versions, so everything is properly tested. I can use specific tags only for f-droid builds, but that means the f-droid version won't use the latest fixes. I've had cases where this has caused problems before, so I keep the f-droid version as identical as possible to other versions.
I mean if https://github.com/Gedsh/InviZible/commit/1a537f122a95e00f3895863dbd3206e04d65a763 says 2.1.8 why isn't https://github.com/Gedsh/InviZible/blob/v7.1.0-stable/tordnscrypt/libs/prebuild#L6 2.1.8 too?
or why isn't dnscryptproxy setup as a submodule too?
it's an odd mix of submodules and prebuilt binaries that make tracking the exact version hard 🤷
eg. 7.1.0 was built with an older version of dnscryptproxy as that was bumped in our recipe in the past and we were not aware of its update: https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/pan.alexander.tordnscrypt.stable.yml#L1119
I mean if https://github.com/Gedsh/InviZible/commit/1a537f122a95e00f3895863dbd3206e04d65a763 says 2.1.8 why isn't https://github.com/Gedsh/InviZible/blob/v7.1.0-stable/tordnscrypt/libs/prebuild#L6 2.1.8 too?
This means that the actual commit will be after version 2.1.8, but before 2.1.9 if it exists. I don't think this is a problem, and it's unnecessary details for users. The developer can easily find out the actual commit.
why isn't dnscryptproxy setup as a submodule too?
Check what the submodules actually are. They are just scripts to build Tor and I2P on gitlab servers. Other submodules are UI lib and nflog developed by me, written in go. Other binaries I build locally on my PC for non f-droid versions. That's how things have worked out historically.
mix of submodules and prebuilt binaries
Why do you use prebuilt binaries? You should build everything from scratch.
tracking the exact version
I still don't understand why you need this? You have scripts to build everything from scratch. Just use the branches and versions from the prebuild script. https://github.com/Gedsh/InviZible/blob/master/tordnscrypt/libs/prebuild
7.1.0 was built with an older version of dnscryptproxy as that was bumped in our recipe in the past and we were not aware of its update
You should not use any pinned commits. You should use branches as specified in the prebuild script.
InviZible is a complex app consisting of many open source projects, so it's not easy to build it from scratch. And first of all, I made everything to make it easy to develop, as I'm just one person and can't spread bureaucracy in my project. I really don't have free time for that. If you have any idea how we can simplify the build of the f-droid version without complicating the development process, I'd be happy to help you with this.
You should not use any pinned commits. You should use branches as specified in the prebuild script.
right
@linsui so I guess in the next release we should remove
- cd libs/dnscrypt-proxy
- git checkout de75b7933a5cb2be5bc5af57fad4899d75876616
from the recipe
@licaon-kter I have specified all the branches and commit hashes that should be used to build the correct versions of dependencies. I hope this will solve the problem with the DNSCrypt version. https://github.com/Gedsh/InviZible/commit/d89570cf6b7307a914c7b88248854e4fcc1049f8