build fails due to missing resources #84
Comments
|
Likely the buildsystem is somewhat borked. Very likely in fact. I did not do a "from scratch" build in ages. I really really should get my build system in order ... 👀 Anyway, one problem is are the "non-free images" I am using from https://www.flaticon.com/ . I cannot add them to this repo according to their license. Therefore, one integral part of getting everything up and running is to get an API key from them so that the builder can download the resources required. I kind of find this important to address and I am feeling down about the Google app store rejecting my breast icons all of a sudden, so you are in luck: I will try to fix this now! |
That will make reproducible builds (see Reproducible Builds, special client support and more at IzzyOnDroid – your app is listed there) impossible then, as builders wouldn't sign up for API keys. Maybe a better approach would be finding free replacements, e.g. at svgrepo.com (those are mostly licensed CC0 as far as I could see)?
I didn't think I'd say "thank you, Google" one day and not meaning it as sarcasm 🤣 So I'll add a "Thank you, Paul" if you don't mind 😉 |
That is very much true. When I created the app, I kind of realized that this was the only non-free aspect of it. On the other hand, I had to realize that creating my own icons or scraping open sources was very time intensive and just did not yield the same quality of results. Flaticon, even though it is non-free has a solid and appealing selection of icons and therefore saved me a lot of time making this app exist in the first place. That said, for the builds, I am planning on creating a separate "source" for images based on a filler-texture. Then I can do full builds but I do not need to hook flaticon/freepik in the build system. This then opens up the possibility for alternative icon packs. Alternative icon packs, however, have their own rats tail attached to them. svgrepo.com seems to be a pretty nice source, but requires CC attributions. Not a problem per-se, just a lot of work. So, getting alternative icon packs, or replacing the current one to get rid of the freepik-license would probably need to become its own issue. There is also a completely different solution on the horizon that I discovered yesterday: The freepik api has changed once again, and it seems that the icon-downloads themselves are no longer hidden behind a api-key. This would be great: The images themselves are still protected by the freepik license itself (meh for an open source project, I know), but at the same time no API-key is needed for downloading them. I can actually investigate that solution before replacing the entire pictogram library. |
And that way, also opens a way to get rid of the NonFreeAssets anti-feature: the app itself could include a libre icon pack – which then can optionally replaced via manual download (on-demand from within the app, or simply by placing them into a specified/configurable location). Feeding three birds with one basket, so to say: no problematic build dependency, the AF dropped, and more flexibility/customization. I'd like that approach 😉
I was just browsing it yesterday as we need some icons "refreshed" here. All the icons I took a closer look at were licensed CC0 (aka "public domain"). Why would those require attribution? Of course YMMV, as other icons might use other licenses – I didn't check all 500k of their collection.
That sounds like a possibility as well – if a "central attribution" (like "icons are ⓒ xxx by freepik") suffices. Though that might still require NonFreeAssets then. For dropping that AF, the "multiple icon packs" approach would be the better fit. But yeah, both would work. |
The process installed NDK v.26.1.10909125 "Side by side". Any dependency I miss? OK, convert resources/help_images/screenshots/help_diaper_logging.png -crop "+0+170" -crop "-0-135" app/src/main/res/drawable/help_diaper_logging.pngI doubt that is deterministic (converting images rarely is, so better use the "final ones" directly). And if it's not, it will make Reproducible Builds impossible (which is the reason I try to build the app myself, see Reproducible Builds, special client support and more at IzzyOnDroid). Ah, and then So at this point, build crashes with And I haven't yet installed what I dug up from the So simply running extra_packages:
- make
- imagemagick
- python3
- pipenv
- python3-urllib3What build process would you advise then? In case it matters: the pod for building your app is using ubuntu:jammy here, with OpenJDK-21. |
|
Hey! Sorry, I got very ill since yesterday. One very quick pointer: https://github.com/babybuddy/babybuddy-for-android/blob/6588135e445aaf8fb3a4b516089b7030c43c1d83/README.md I updated the readme with the required packages list, had to determine the list myself again. I am still running all of this on ubuntu 22.04.5, but annoyingly, some of the Android features rely on JDK 18, not 21, so a custom JDK is required. Rest needs to wait until I am healthy again. |
Oof. That will make it unfit for RB then. We only support long-term JDKs (11, 17, 21 currently – with 17 being the default for now). Features being dropped with later releases are one of the reasons to not use such interim-JDKs for "production". Do you see any chance getting rid of that "unstable dependency", making the app build fine with 21 directly (i.e. not requiring JDK-18)? |
Trying to build the app using
./gradlew assembleReleaseon Debian bookworm with JDK 17 fails, as some resources seem to be missing:Could it be you forgot to check those in to this repo?
The text was updated successfully, but these errors were encountered: