f-droid

[532910]

Please add the snapdroid to f-droid repository.

[slackline]

Yes, it would be great if this could be automatically pushed to F-droid as the older client was when bundled with snapcast.

[IzzySoft]

As there was no "No" from the dev, I took the freedom to open a Request For Packaging with F-Droid. Until that is processed, you can find the app in my repo.

@badaix Would still be nice to have your "official approval" :innocent:

[badaix]

@IzzySoft approved! :) how does it work? I remember that last time it appeared on f-droid it stucked at version 0.7. Maybe because of the non-straight-forward way the native binaries are built. Will it need a maintainer for f-droid?

[IzzySoft]

Yeah, I just noticed afterwards it was already there but not updated lately. Let me check … Ah yes, seems it is really the "tricky build" behind the issue. There's a 0.10.0 Build configured but disabled with the comment "wip" (looks like the maintainer working on it finally gave up). Not being a dev myself, there's nothing I can do about this, sorry. If you could setup a Build section that works, we could get things going again. Here are the last two sections from F-Droid: the 0.7.0 that worked, and the 0.10.0 we didn't get to work:

Build:0.7.0,6
    commit=v0.7.0
    subdir=android/Snapcast
    submodules=yes
    gradle=yes
    scandelete=android/Snapcast/src/main/assets/bin
    build=pushd ../.. && \
        ndkdir="$PWD/ndk" && \
        sed -i "s@NDK_DIR=.*@NDK_DIR='${ndkdir}'@" client/build_android.sh externals/build_flac_android.sh && \
        pushd $$NDK$$/build/tools && \
        ./make-standalone-toolchain.sh --arch=arm --platform=android-14 --install-dir=${ndkdir} --ndk-dir=$$NDK$$ --system=linux-x86 && \
        popd && \
        pushd externals && \
        sh build_flac_android.sh && \
        pushd ../client && \
        sh build_android.sh

Build:0.10.0,7
    disable=wip
    commit=41be3ade60de166cd8f0bd8b2b66a78537e2599d
    subdir=android/Snapcast
    submodules=yes
    gradle=yes
    scandelete=android/Snapcast/src/main/assets/bin
    build=pushd ../.. && \
        ndkdir="$PWD/ndk" && \
        sed -i "s@NDK_DIR=.*@NDK_DIR='${ndkdir}'@" client/build_android.sh externals/build_externals_android.sh && \
        pushd $$NDK$$/build/tools && \
        ./make_standalone_toolchain.py --arch arm --api 14 --install-dir ${ndkdir} && \
        popd && \
        pushd externals && \
        sh build_externals_android.sh && \
        pushd ../client && \
        sh build_android.sh
    ndk=r13b

No need to fill the gaps for old versions – but hints to a working section for v0.15.0 would be very much appreciated :wink:

[badaix]

so far I didn't find a nice way to cross compile Snapclient for Android. It would be easy to compile with cmake, but you need to compile the dependencies first (FLAC, ogg, ...). I will think about a more F-droid friendly way.

[IzzySoft]

Thanks, @badaix! Please ping me (post a comment here) when I can tell the maintainers to "try again, it's easier now" :innocent:

[IzzySoft]

Any news, @badaix?

[PureTryOut]

I didn't realize there was a separate repository for this, so I made an issue on the main snapcast repo instead (closed it now :wink:). Yes please update the build :smile:

[IzzySoft]

@badaix with that PR you also have German summary/description. Once merged, I'll tell my updater to watch out for future changes you might make, so it pulls them in.

I'm no packager, so unfortunately I cannot help fixing what might be needed to re-activate the app at F-Droid – but at least I can help for better visibility with my repo. The initial Fastlane setup my PR provides was just set up with it and thus become visible with the next sync.

[natrius]

I think i'm going to try Snapcast and therefore it would be awesome if this would be in the main-repo. In the meantime, thanks for your work @IzzySoft :)

Or is this already working without izzy now as i don't see any mention now about Izzys Repo? If yes, this issue could be closed, or am i wrong?

[IzzySoft]

@natrius Snapcast is still in my repo. The PR I've opened for Fastlane is still unmerged. Snapcast is de facto "frozen" to v0.10.0 at F-Droid, with updates disabled – while my repo has it at v0.22.0.0. So if you're going to try it, I'd say take it from my repo – I've no idea if and when the app can be revived at F-Droid.

[IzzySoft]

@badaix merging my PR concerning Fastlane would be helpful for F-Droid as well, btw. That would give me a handle updating your app's metadata there, hopefully bringing it to our packagers awareness.

[badaix]

Hi, sorry, this F-Droid topic is/was kind of annoying. I'm regularly checking the feasibility of a non-tricky "gradle-only" build process (the difficult part in build this app is cross compiling the native Snapclient along with it's dependencies), and have some good news: since 20th of February the Android App build process supports native dependencies as you can read in this announcement and since 4th of November a bug has been fixed that enabled header only native libraries. So I've created aar packages (Android Archive Library) for all native dependencies (boost, flac, oboe, ogg, opus, soxr, tremor) and added Snapcast as external native build to the gradle.build file and now it is actually possible to easily build Snapdroid within Android Studio or on command line with a simple gradlew build call. There is even a GitHub action that builds Snapdroid fully automated and provides a signed APK file for every commit. You can find this in actions

@IzzySoft At the weekend I will google what Fastlane is and check your PR. Sorry for the delay. If there is/was/used to be a F-Droid maintainer for Snapdroid, then there is a good chance that it can be easily integrated into the F-Droid build process. I will not actively drive this F-Droid integration topic.

Edit: the native libs (aar packages) are bundled with the project and imported as "local Maven" packages, they're not in the maven repository (which I would prefer, but didn't spent any effort in (you must register and add some more metainformation and what not)). Everyone who was yelling for F-Droid "support" is highly welcome to support and drive such efforts.

[IzzySoft]

@badaix to save you from big G grabbing your data while you try to get some from them: here's my Fastlane Cheat Sheet for a quick overview (you won't find that even in the Fastlane docs – took me some days to get that together).

In short and for the F-Droid context: it's a place where you maintain your app's description, screenshots etc – and F-Droid grabs it together with each new release it builds. No extra MRs needed whenever you changed the description, added a screenhot, updated the featureGraphic etc.

In short outside the F-Droid context: if in addition to the described structure you also install the Fastlane binaries, those help you generating screenshots as well as deploying to Play and the Apple store, plus some more. For F-Droid (as well as for my repo, where the latest versions of your app currently reside), those binaries are not required.

Looking forward to your merging my fastlane PR this week then, thanks!

As for the AARs: local maven repos are supported by F-Droid. Just AARs (on their own) are not, so make sure to keep the source along in a way they are easily "matched" to the AARs. And yes, trusted maven repos are preferred :wink:

[badaix]

@IzzySoft thanks for the explanation and your patience :) And yes, I'm afraid that the hand crafted AARs might not be trustworthy enough for F-Droid, they are not part of the build process, nor they are signed and could contain anything. The sources are fetched as submodules of the Snapcast submodule, along with some half automated makefile used to cross compile static libs from them. There is also a shell script to build the AAR directory structure, but without populating it with the headers and libs. I've done this manually... So there is a chance to guess that the AARs are somehow related to the submodule sources, but this might not be evident enough (Glauben tut man in der Kirche).

I think that using AARs are the right way to go, and does not need to be part of the App's build process, but should be hosted in some trusted repo. Google oboe is already available in the maven repo, but only as shared lib (Snapclient is linking statically) and they seem to have a similar approach (though a bit more professional) using a shell script prefab_build.sh and the prefab tool to build an AAR from the c++ sources.

[IzzySoft]

thanks for the explanation and your patience :)

Gladly! I try the best I can to help. Like, every journey starts with a single step…

Glauben tut man in der Kirche

Hey, auch in Synagogen und Moscheen! Auch wenn man dort weniger glaubt, dass "mein Schwein pfeift" :laughing: Aber genau das ist ja das problematische: Glauben ist etwas subjektives – und nicht "neutral reproduzierbar".

The sources are fetched as submodules

That should satisfy F-Droid! We've got a lot of apps handling it that way. It's even a solution we recommend. Of course, "build recipes" are always welcome.

I think that using AARs are the right way to go, and does not need to be part of the App's build process, but should be hosted in some trusted repo.

I'm not a packager, so I cannot tell how exactly F-Droid deals with that. We've got a somehow similar way called srclib (difference is that those are hosted at F-Droid's end). They are built once (and only rebuilt if a different version is required), then used by multiple apps. My guess would be that as long as the submodule reference does not change, the same "build result" is reused – but I don't know for sure.

[badaix]

Update: there is a new repo snapcast-deps that does the cross compilation and building of AARs using GitHub Actions and I've tagged the release v0.24.0 with the AARs from the GitHub actions build artifact. I've removed the AARs from the Snapdroid project (they were lately added to the libs directory to enable an automated build) and instead download them before the build step. So this is kind of a lite-version of a package repository. Now everything is versioned and tagged and every build step is reproducible and automated.

[IzzySoft]

and instead download them before the build step.

That won't work for F-Droid either (unless the idea is that the F-Droid build recipe instead builds them from source ("The sources are fetched as submodules"), and only your build process "simply downloads the AARs"). I'm a bit confused now which one you mean, apologies…

[badaix]

The AARs from the snapcast-deps project are now automatically published as GithubPackages by the GitHub actions CI and used in Snapdroid build.gradle:

dependencies {
   ---
    implementation 'com.github.badaix:oboe:1.5.0@aar'
    implementation 'com.github.badaix:boost:1.75.0@aar'
    implementation 'com.github.badaix:flac:1.3.3.2@aar'
    implementation 'com.github.badaix:ogg:1.3.4@aar'
    implementation 'com.github.badaix:opus:1.1.2@aar'
    implementation 'com.github.badaix:soxr:0.1.3.2@aar'
    implementation 'com.github.badaix:tremor:1.0.0@aar'
}

repositories{
    maven {
        name = "GithubPackages"
        url = uri("https://maven.pkg.github.com/badaix/snapcast-deps")
        credentials {
            username = project.findProperty("GITHUB_USER") ?: System.getenv("GITHUB_USER")
            password = project.findProperty("GITHUB_TOKEN") ?: System.getenv("GITHUB_TOKEN")
        }
    }
}

Only drawback is that you need to provide a github user name along with a personal access token with read:packages privileges to be able to fetch packages from the maven.pkg.github.com repository.

This makes the build now as easy as

GITHUB_USER=<user name> GITHUB_TOKEN=<user token> ./gradlew build

[IzzySoft]

So our scanner will yell about an "unknown Maven repo" – and even if we'd whitelist that, it wouldn't work as it's unlikely we can setup the username/token easily (AFAIK that's not implemented with F-Droid's framework – but to answer that we'd need to consult someone who's "in-the-knows"). Maybe open an issue at fdroiddata asking if this is possible? If it's not, it probably would need another issue at fdroidserver asking to implement it, if possible. That's also where the whitelisting would need to happen.

[badaix]

Too bad. I think I'm out for now. My main motivation to have Snapdroid in F-Droid is to remove it from the Play store, avoiding stupid ratings like "Brilliant, but I never give 5 stars: 4 stars", or "Not working: 1 star". At least I have a fully automated build process, thanks to the great GitHub actions, so that it's easy for me to release a new Snapdroid version with every Snapcast release (Snapdroid is often behind and not every version is released currently). And there is still the possibility to get it via F-Droid from the IzzySoft repo.

[IzzySoft]

It is of course welcome to stay at my repo! Still I'd recommend you to ask someone more experienced in the F-Droid server part. I might be totally off the road here: just because I've never seen any app set up that way must not necessarily mean it's impossible. If there's e.g. "verifiable proof" your Maven repo provides the matching source, it might be "white-listable". And as F-Droid does have a GitHub account, it could well be your scheme might be established.

Just direct your questions at fdroidserver (as both needs to happen there). As much as I like your app in my repo, having it listed in the "official one" gives it more prestige, trust etc. It could even be available at both repos if you wish (though that might cause some confusion, there are exceptions) – to avoid those confusions, a flavor could be used to let it have different package names. Those coming from Play could seemlessly switch to my repo, new users go straight to F-Droid. For example.

[badaix]

Good news everyone: Snapdroid is now available at f-droid, you can get it here. Thanks to @IzzySoft and @relan for supporting this effort

[532910]

Awesome. @badaix, @IzzySoft, all other, thank you!

[IzzySoft]

@badaix just to be sure: I shall still keep it in my repo, a) just in case and b) for those migrating from Play? Guess b) would be a strong argument, at least for a "migration phase", as it avoids the "uninstall + reinstall" required with a switch to F-Droid.org because of the signature, so it would be a "seamless switch" for PlayStore users. We can always reconsider later (e.g. a year or so after you took your app down at Play and all users have migrated). Same of course goes the other way round – should you decide to "unlist" from my repo, have users crying, and want me to re-list :rofl:

[badaix]

@IzzySoft yes, I would keep it in the repo, I don't know yet how the update procedure is in F-Droid when I release a new version. Does F-Droid watch for new tags? Do I have to ping the maintainer? I think I should ask @relan how the process is. For the transition phase (say 2 or 3 releases) I would not remove it from any repo. I will add a link in the Readme to the F-Droid repo and maybe also in the PlayStore. Regarding the PlayStore I'm thinking about some in app purchase for donations or unlimited playback or whatever. Maybe I can earn 5€ as reward for the man-month I've spent into Snapcast :smile:

[relan]

Snapcast's recipe is too complex to be updated automatically on F-Droid. Someone has to maintain it.

[IzzySoft]

That's a good argument to keep it in my repo then (fast updates for those who strongly request that) – there are other apps in my repo for the same reason (FairEmail, NetGuard …). I've added a mark in my metadata; with the next sync, a corresponding note will show up in the WebIf of my repo linking here for background.

[seppeel]

The last F-Droid version is "0.24.0.0". I would love to see updated Snapdroid in F-Droid again :)

[natrius]

You probably shold update your fdroid repos :D

[badaix]

Seems to be in the IzzyOnDroid repository

[IzzySoft]

Yupp. Was a good decision to keep it there. Seems that for some reason, auto-updates are disabled at F-Droid:

AutoUpdateMode: None
UpdateCheckMode: None
CurrentVersion: 0.24.0.0
CurrentVersionCode: 2400

So updates would need to happen manually. The YAML gives no reason (usually it has some MaintainerNotes to tell). According to git history, it was archived on 2021-02-15 as it no longer worked and updates failed, then 2 weeks later manually updated to 0.24.0.0 (but auto-updates most likely not re-enabled). If the build recipe has not changed much since then, I could try reviving it. But if I fail I'd need help:

  - versionName: 0.24.0.0
    versionCode: 2400
    commit: v0.24.0
    subdir: Snapcast
    submodules: true
    sudo:
      - apt-get update
      - apt-get install -y libvorbisidec-dev
    output: build/outputs/apk/release/Snapcast-release-unsigned.apk
    srclibs:
      - snapcast-deps@v0.24.0
    rm:
      - Snapcast/Ressources
    prebuild: sed -i -e '/maven {/,/^    }/d' build.gradle
    build:
      - pushd $$snapcast-deps$$
      - wget -q https://dl.bintray.com/boostorg/release/1.75.0/source/boost_1_75_0.tar.bz2
      - tar xjf boost_1_75_0.tar.bz2
      - NDK_DIR=$$NDK$$ ./build_android.sh
      - popd
      - mv $$snapcast-deps$$/build/aar/*.aar libs
      - gradle assembleRelease
    ndk: r22

Is this still valid in all points (e.g. version of snapcast-deps, boost and NDK), or would it need different ones? Maybe you want to include snapcast-deps as git submodule here so the correct version would be ensured without editing the build recipe? And maybe the same could be done for boost?

[relan]

Opened a PR that will simplify maintenance on F-Droid: https://github.com/badaix/snapcast-deps/pull/1