New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Request] Add SAI to the F-Droid repository #6
Comments
Perhaps as a step toward this, @IzzySoft's repo now includes this. However, several initial steps need to be done before full repo addition:
|
Ok, I'll try creating a build flavor without Firebase/Google Services for F-Droid |
So, I did create a branch for F-Droid stuff - https://github.com/Aefyr/SAI/tree/fdroidstuff. However I don't understand some things about F-Droid's policy. Is the fact, that Google Services/Fabric plugins are still applied in build.gradle, but their tasks are cancelled for F-Droid flavor fine with F-Droid's policy? Also I don't understand the point about source-build version of binaries (JARs/AARs). It says to check out some manual, but there's no link. |
Thanks @Aefyr – but that tree still has some culprits inside, going by its apply plugin: 'io.fabric'
//..
normalImplementation 'com.google.firebase:firebase-core:17.0.1'
normalImplementation 'com.crashlytics.sdk.android:crashlytics:2.10.1'
//..
apply plugin: 'com.google.gms.google-services'
I'm not a dev, so I'm not sure if executing the gradle would somehow remove things – or if the build would succeed and result in a working APK if those lines were simply removed using e.g. |
That's exactly what I did, there is a "normal" flavor with google's stuff and a "fdroid" flavor without it. I've created a branch for now cause I'm not sure about committing that code to master yet. Those "normalImplementation" entries only apply for the "normal" flavor. I don't know what to do about "apply plugin" entries however, I couldn't find a way to apply a plugin for a specific flavor only, but I did add code to cancel tasks from those plugins for the "fdroid" flavor (So the build won't fail due to lack of google-services.json). So, if you were to remove those 4 lines you've mentioned, "fdroid" flavor would still build successfully, "normal" flavor would fail though, so I don't really wanna remove them from the project. Here's an APK built with "fdroid" flavor, if you wanna scan it with the tool you've used to create that list of anti-features on your repo (If it wasn't created from sources). Packed into zip since GitHub doesn't support attaching APKs directly |
Ah, I see. OK, I'm not an Android dev, so I might have missed some details. But with the dependencies declared globally, that's what it looked to me. Maybe better have an experienced packager check that. But one thing I'm sure about: our build system at F-Droid has problems with those "suffix"es inside the flavor (again, I'm not familiar with the details). So if you need to use a separate package name for the flavor, it won't work this way (not sure, but can you define the
🤔 Ah, got it, thanks! Not sure I remember it next time, though 😆
Neither do I. If we cannot figure out, but the gradle works for your normal build – I'd say just keep it that way for now, and fix it after our packagers had a look and gave their advice. Shouldn't be a big deal: you tried your best to have it "cleaned up" before, and I am your witness for that 😄
That sounds like a plan! Fine with us, our recipe can address flavors and we can simply ignore the other one. Let's mention that in the RFP then, our packagers should be able to cook it up then in the preBuild section.
If you could attach that as plain APK (not |
Sorry, I don't wanna mix up normal and F-Droid variants package names |
Yes, that looks good. And as for the APKs: understood. If you attach both nevertheless, I could offer to switch to the F-Droid variant in my repo (so you see the scan results). I'll remove the app on my end anyway as soon as it is listed in the official repo (to avoid folks tapping into the "signature mismatch" confusion). |
I made a release with both APKs https://github.com/Aefyr/SAI/releases/tag/1.27 |
That looks great! even lost some weight 😆 I've just replaced it in my repo (will become effective with the next sync tomorrow). So please keep attaching the F-Droid version to your releases, at least until your app is listed in the official repo, as I will stick to that. Also please keep the naming schema, i.e. have the APK end with @TPS will you create the RFP then? I'll add the metadata once the bot confirmed (it's just copy-paste as I have set them up in my repo already). @Aefyr you might wish to add Fastlane structures to provide screenshots (and more, if you wish – see https://f-droid.org/en/docs/All_About_Descriptions_Graphics_and_Screenshots/ for a quick intro and links). At F-Droid we prefer having those in the app's repo, to keep our footprint small. Our build process will pick them up from there (those matching the tag it builds). |
@IzzySoft, @Aefyr: I've filed the RFP, & updated my checklist above. N.B.: There's a FOSS license needed posthaste |
Aw yeah, how could I miss that! @Aefyr any thoughts on this? You can find a list of accepted licenses here; chose one that is marked as "FSF Free/Libre" AND "OSI Approved". Apart from that, the bot suggests you secure your gradle. And then stumbled over its own legs and forgot to scan the repo, stupid tin can… I'd setup metadata as soon as you've decided for a license and added it to the repo here. |
Added license.
I think using TLS is good enough
Do I just add metadata folder to the project root and put images/phoneScreenshots directory there with .png files in it? |
Basically yes: using the directory structure described on the page I've linked you with my previous comment. And as for securing the gradle: as you wish, it's just for the builds you create (not for those on our end). |
Does this look fine? |
That looks great! But what happened to the 4th screenshot (theme selection)? Somehow missing there. Now, for F-Droid to pick this up, it must be covered by a tag. Maybe moving the current 1.27 to the last commit? Then I'd adjust metadata at F-Droid to use it (i.e. remove the "inlined" description/summary so the one from Fastlane is used). |
Added screenshots and moved the tag |
Thanks! I've setup metadata and marked the RFP ready for packaging. Now lets wait for a packager to pick it up. |
@Aefyr, @IzzySoft, & all: Amazing what an RFP & some TLC can do: The data merge request is now active, which IUC means SAI will hit the main F-Droid repo ASAP once it's committed. |
Thanks to all, it's now live in the official directory – and thus will be removed from mine with the next sync in about 2 hours. Congrats, @Aefyr! |
@Aefyr, you did all the heavy lifting, with the build flavor adjustments. The rest of us just worked out the ancillaries. So, thank you! 🙇🏾♂️ |
Hi,
Can you please add SAI to the F-Droid repository ?
God bless you.
The text was updated successfully, but these errors were encountered: