solar
solar copied to clipboard
satoshipay
F-Droid
I'm sorry that I opened this issue by mistake. I was going to submit this issue in Vault, but somehow I submitted it here...😂
Lol. Just out of curiosity... Does F-Droid come without the Google Play Store or why was your question F-Droid-specific?
@andywer F-Droid is an alternative to Play store and only includes FOSS apps. Learn more about it here if you are interested in this.
@yushijinhun Why close this issue? Is no work needed on the author's side for getting Solar on F-Droid? Do you have a link to the issue submitted in Vault? I could not find Solar at https://gitlab.com/fdroid/rfp/issues.
My phone runs SailfishOS and while it does not come with Google Play, it does support Android and I have installed F-Droid. Would be great to have Solar available there!
Hey guys! What needs to be done here?
We are happy to get Solar on F-Droid if you can help us with that 👍
I'm not sure what needs to be done. I noticed there's a package request for Solar open at https://gitlab.com/fdroid/fdroiddata/issues/1778 (not sure why there's package requests at two different repositories), but it hasn't received any feedback since 3 months.
Hi, F-Droid maintainer here. It would be great if you could establish Fastlane file structure in your repo, so you can maintain summary/description without the need of merge requests for each change – and have means to provide screenshots to be shown along with your app description in the F-Droid client and on the website. Can that be done?
For reference: A RFP (Request For Packaging) was opened with us to include your app :wink: The other one you saw wasn't processed as it lacked details (I will close that now as duplicate).
@IzzySoft Thanks for looking into it!
@ebma What do you think? Can also talk about it in person.
Thanks for adding Fastlane! Can you please send me another ping once that has been tagged? F-Droid only picks it up from the tag – so once it's there we can proceed above mentioned RFP.
@IzzySoft I will try to remember pinging you, but you can also watch the repo and choose "releases only" 😉
@andywer apologies that I don't, but I'm already drowning in tasks and my mailbox is flooded enough… Maybe keep this issue open as reminder, and simply close it then? :wink:
Thanks! I've updated the RFP. I'm not familiar with Cordova/Electron, so I could not figure how to find e.g. versionCode. Hope that gap will be fixed by the packager picking it up. Marked it ready for processing after setting up initial metadata.
We generate the Android version code via a script when we create a build. We just use the current unix timestamp for it, like 1583750314.
That information is not committed to the GitHub repo, though (wouldn't make much sense either)…
That would mean we have to switch of auto-update then, and someone has to open an MR for each new release, unfortunately. Reason is that the updater wants to check that e.g. VC was updated before starting a build (else we might end up with two APKs of the same VC, which is not valid) – and then compare that with the real one after the build (to make sure it built the right thing, AFAIK).
Not being a packager (and neither an Android dev), I don't know if and how that could be worked around – other than with manual updates, unfortunately.
Is the version code so important? Otherwise you could just watch the repo for new releases/tags.
Seems like. As I wrote, I'm neither dev nor packager. Yes, tags are used to identify the commit. But then versionName and versionCode are also checked before building, as described. I cannot explain details on that for the reason given (lack of knowledge) – feel free to drop into IRC (Freenode, channels #fdroid and #fdroid-dev) and ask.
And it's not me, it's the F-Droid build job. I have no hands in that.
No worries, I totally understand. You just seem to have more of a clue about F-Droid packaging than I do, developer or not, so I thought I just ask and see 🙂
The Fdroid packages ask for this: (It would help if they could provide the generated Android project.) See https://gitlab.com/fdroid/rfp/-/issues/1240 Could you provide that?
Hey @swedebugia, while we could upload the files of the android project we decided not to do so because all of them can be generated automatically and it does not add much benefit besides bloating the repository.
@ebma The reason the Android project is requested appears to be because Pierre Rudloff is having a hard time setting up a working build recipe due to the amount of NPM dependencies making the build take very long (see https://gitlab.com/fdroid/rfp/-/issues/1240#note_377921872). I'm not sure why it would help to provide the generated Android project, but if you can't do that is there maybe some other way you could assist with this build recipe?
Hey guys. Uploading the APK on GitHub, too, wasn't our first choice. I can, however, see the need and the difficulty setting up the build pipeline.
I would be ok to upload the APK as part of the GitHub release if that works for you. As @ebma already said, putting the APK in the repository would be a questionable way to go, but if us attaching the APK to the GitHub release would do the trick, then let's try that 🙂
I guess that would not suffice because IIRC the idea of F Droid is to build and sign apks from scratch to ensure integrity (?)
We would upload a signed APK, so you can be sure it's been built by us. To be fair, maybe they don't trust us either 😅
@andywer Nobody asked for the apk files since indeed F-Droid builds those themselves to avoid the need to trust the developers: somebody installing an F-Droid package can be sure it was built from the published source. The request was whether the Android project files could be added, which would apparently help with setting up the build recipe.
@swedebugia I guess it's worth asking the person working on the F-Droid build recipe what other help he could use in case the Android project can't be provided?
Nobody asked for the apk files
… yet :wink: I see they'd be well in the limit to be taken into my repo – at least until an F-Droid build can be established. My updater could pick the APK when attached to a release.
putting the APK in the repository would be a questionable way to go
That's correct, I'd discourage that (APKs then would be part of every fork/clone, which is a waste of space & bandwidth). Attaching to releases OTOH would not affect that, and hence be perfectly fine.