[Request] Add SAI to the F-Droid repository about sai HOT 23 CLOSED

@Aefyr, you did all the heavy lifting, with the build flavor adjustments. The rest of us just worked out the ancillaries. So, thank you! 🙇🏾‍♂️

from sai.

Perhaps as a step toward this, @IzzySoft's repo now includes this. However, several initial steps need to be done before full repo addition:

• I don't see an open RFP (super easy if 1 chooses the right template), so anyone can do that Done here.
• As part of that, explicit permission to attempt inclusion is required from @Aefyr
• A clear FOSS license is required.
• @IzzySoft does mention some concerns that need to/should be handled before F-Droid may accept

from sai.

@IzzySoft, @Aefyr: I've filed the RFP, & updated my checklist above. N.B.: There's a FOSS license needed posthaste‼️

from sai.

Added license.

the bot suggests you secure your gradle

I think using TLS is good enough

@Aefyr you might wish to add Fastlane structures to provide screenshots

Do I just add metadata folder to the project root and put images/phoneScreenshots directory there with .png files in it?

from sai.

@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.

from sai.

Thanks! And thanks for all the help, @IzzySoft and @TPS

from sai.

Ok, I'll try creating a build flavor without Firebase/Google Services for F-Droid

from sai.

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.

from sai.

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 F-Droid.apk, so my updater picks the correct one.

@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).

from sai.

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!

from sai.

Thanks @Aefyr – but that tree still has some culprits inside, going by its app/build.gradle:

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'

count($NoGos) = 4 – all of those are proprietary components not meeting F-Droid's inclusion policy. They are best removed before applying for inclusion. Ideally, you'd use a separate build flavor for this, as F-Droid has no easy way to build from a branch (if I'm informed correctly).

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. sed (that could be done in an F-Droid recipe then).

from sai.

@IzzySoft,

Ideally, you'd use a separate build flavor for this

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
app-fdroid-release.zip

from sai.

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.

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 packageId in there directly instead?)

Those "normalImplementation" entries only apply for the "normal" flavor.

🤔 Ah, got it, thanks! Not sure I remember it next time, though 😆

I don't know what to do about "apply plugin" entries however

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 😄

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.

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.

Here's an APK built with "fdroid" flavor

If you could attach that as plain APK (not .zip) to a release (e.g. as SAI-fdroid.apk), and it had the same package name as the one already attached, I could simply put it into my repo and see what happens. Your app is already there – so I'd expect my framework to alert me I can drop some AntiFeatures then.

from sai.

can you define the packageId in there directly instead?

Like this?

If you could attach that as plain APK (not .zip) to a release (e.g. as SAI-fdroid.apk), and it had the same package name as the one already attached

Sorry, I don't wanna mix up normal and F-Droid variants package names

from sai.

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).

from sai.

I made a release with both APKs https://github.com/Aefyr/SAI/releases/tag/1.27

from sai.

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.

from sai.

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).

from sai.

Does this look fine?

from sai.

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).

from sai.

Added screenshots and moved the tag

from sai.

Thanks! I've setup metadata and marked the RFP ready for packaging. Now lets wait for a packager to pick it up.

from sai.

@Aefyr I dunno if you're on GitLab, but @Bubu (a packager, among other roles) has just raised a concern @ the RFP, which is an outright stopper for F-Droid until it's resolved.

from sai.