Include in F-Droid

[julianfairfax]

It would be nice if this app was included in F-Droid. I am opening a request for this. Please make it known if you oppose to inclusion.

[julianfairfax]

A license for the app would be useful.

[julianfairfax]

So would Fastlane. https://gitlab.com/fdroid/rfp/-/issues/2263#note_1175157810

[IzzySoft]

@julianfairfax it's MIT, see the badges. But yes, the license file should be added so Github discovers it and marks it more prominently.

Fastlane is present meanwhile btw. I'll trigger a rescan in the RFP. Wait: Fastlane was established 2 weeks ago, so why did the bot not see it? It neither noticed that the app is in my repo, btw. Ouch: package name is __PACKAGE__? Well: no gradle, so I'm out…

[farfromrefug]

@IzzySoft yes we use gradle. But our build process is a bit specific. There was some work done to allow Nativescript apps to be built by fdroid. Not sure where it is at. Will have to check About the license I need to see how to make github pick it up

[IzzySoft]

yes we use gradle

Strange: I didn't see a build.gradle in the root, in app/ or in app/android/ – and I guess those were the places the bot looked for it, too.

There was some work done to allow Nativescript apps to be built by fdroid.

Oh, I see – so there might be another delay then (I'm not familiar with the Native things I have to admit). for now, your app is already listed here in my repo – so if you want you can pick a badge and link there from your Readme.

About the license I need to see how to make github pick it up

Just add the original LICENSE or LICENSE.txt (or whatever it's named – these two names are detected by Github and their contents will be evaluated, works at least with GPL so I guess it will do with MIT as well – just checked with another MIT project: yupp, ' LICENSE` should work) and add it to the root of your project.

[jugendhacker]

@farfromrefug I'm currently looking into F-Droid packaging and it seems like your forgot to commit package-lock.json which is bad practice, because without it, we might end up in a situation where F-Droid tries to rebuild the app with wrong dependencies.

[jugendhacker]

Also NativeScript/nativescript-cli#3444 is a blocker for F-Droid inclusion, as we need unsigned APKs, because the signing happens on a completely different infrastructure than the building and so the buildservers do not even know the signing keys.

[farfromrefug]

@julianfairfax thanks a lot for looking at this. For the lock is it a requirement?

• i dont use npm
• i specificalluy force packages versions (except devs sometimes) exactly for that same reason

I will look at the other issue and try to fix it

[jugendhacker]

@farfromrefug sorry I did not look close enough. As you already pin specific versions of the dependencies this should work without the lock, execpt this one as there is no version pinned.

[farfromrefug]

@jugendhacker yes this one i need to remove the link. If there is a resolution in the package.json (for yarn link) is it an issue? https://classic.yarnpkg.com/lang/en/docs/package-json/#toc-resolutions

[jugendhacker]

If I get this correctly you are overriding the nativescript dependency with your fork checked out locally. The problem is, we could also locally clone your fork during the F-Droid build but will never know what commit of the fork you had checked out during your build. This will introduce quite some nondeterminism and might lead to build problems down the road.

[farfromrefug]

@jugendhacker no what I do is use my Dev version locally. It is just a question of using Dev version of my fork of N which developing. Though fdroid should use the latest version of my fork from npm. I just ask because resolutions are in package.json thus commited...

[jugendhacker]

@farfromrefug I don't exactly know what you mean by "resolution committed" but from what I see here, F-Droid can't tell what version of your fork we need to build the 1.3.2 for example. If we just take the latest master at the time of building, this might lead to problems when we somehow need to restart the build later for example. Then you might already have committed stuff to your fork, which breaks the build of the release. That's why dependencies without specific version constraints and/or lock files is a rather bad practice, when it comes to reproducing builds of open source software.

[farfromrefug]

@jugendhacker I get you don't understand. I'll commit so you see what I mean

[farfromrefug]

@jugendhacker so i pushed the fix to the repo. No more "link" to local in package.json. But you ll see this that yarn uses when i build locally to actually use my local dev version. Hope it wont bother f droid build

[jugendhacker]

@farfromrefug looks like this will work. Now the only thing missing, is building unsigned APKs....

[farfromrefug]

@jugendhacker i think i can make it work using an env variable like UNSIGNED_APK=1 ns build..... Would that be good enough? Also do you already have a script to build a Nativescript App? Would love to see it if you do

[jugendhacker]

@farfromrefug making it possible via an env var should be enough. And no I currently have no complete build script, because without unsinged APKs, it's useless. I'll notify you as soon as I have something ready you could take a look on!

[farfromrefug]

@jugendhacker it is done. Here a script showing how to build unsigned APKs https://github.com/Akylas/oss-weather/blob/master/package.json#L9. As for the nativescript cli not supporting unsigned APKs, here is a PR fixing it https://github.com/NativeScript/nativescript-cli/pull/5706. Now right now even if the cli fails at the end saying there is no APKs, unsigned apks are actually there at ./platforms/android/app/build/outputs/apk/release Let me know if i can help more

[jugendhacker]

@farfromrefug I have a build script now, seems like I already got pretty far in the building, but current it fails with this error. Could you maybe give me some hints what might be wrong? Some additional info: I'm trying to build the latest master of oss-weather, because your F-Droid specific fixes are in no release currently (which needs to be fixed for official F-Droid publishing btw)

[farfromrefug]

@jugendhacker awesome. Was actually a bug on my side! fixed an push. I also changed build.android.production.fdroid.unsigned because it creating split apks. Does f-droid support split apks? If so i ll bring it back, otherwise you are good to go with this. For your output in your script you can use output: platforms/android/app/build/outputs/apk/release/app-release-unsigned.apk

[jugendhacker]

@farfromrefug I got quite some steps further: https://gitlab.com/jugendhacker/fdroiddata/-/jobs/3432652928#L13955 with this buildscript

And F-Droid does support split APKs in a way. But it's quite complicated, as we need seperate build blocks for all ABIs that should be supported. Take a look at the corresponding issue.

[farfromrefug]

@jugendhacker that error is a bit more of a mistery. I really dont know what s happening :s Searching ...

[IzzySoft]

So we're still stuck – or were you lucky enough to find the culprit and just forgot to tell, @farfromrefug?

[farfromrefug]

@IzzySoft sadly no I did not find the solution. Is there any way to reproduce the building process locally?

[IzzySoft]

Maybe @jugendhacker can help you with that – I don't even have a local build environment (not being an Android dev).

[IzzySoft]

Hm, sad. But then, it's at least in my repo – so maybe you want to add that to your Readme, next to the pointer to download it from releases? You can even pick a badge for that if you wish :smiley:

[farfromrefug]

@IzzySoft it is not done. I will eventually push to get it to work in fdroid repo. But the build process for N is not yes 100% compatible with it. And tbh I am not 100% sure I like the fact that fdroid repo needs to rebuild every single dependency. Not really good energy wise. I understand why ecologically does not seems so good. About the badge I thought i did it . will do this week. Thanks again for everything @IzzySoft !

[IzzySoft]

Not really good energy wise.

Ah. That level I addressed a couple of times in the past as well, as on every rebase etc. all the pipelines were running again, and once more after merging. Now we at least have a button to rebase without running the pipelines.

Hard to find an ideal path here. I fully understand the need to rebuild from source – but I also see what that means ecology-wise; but both things are important. I hope we find a good way in the middle (e.g. by bringing some libraries to trusted Maven repos where we then can just pick the "trusted binaries" from, and things like that).

About the badge I thought i did it . will do this week.

I just checked once more to make sure, but I really cannot see it :see_no_evil: So thanks for putting it on your list (again), and let's look forward to "this week" then :smiley:

Thanks again for everything

And to you!

[farfromrefug]

@IzzySoft i added the badge ! Let me know if i can do more to promote your great repo!

[IzzySoft]

Thanks! Maybe link the image to the correct target, so when clicked one does not end up in the larger image but at your app in my repo? :smile: https://apt.izzysoft.de/packages/com.akylas.weather/ should fit that.

[farfromrefug]

@IzzySoft damn copy paste! Thank you

[IzzySoft]

Thank you!

[farfromrefug]

@IzzySoft i just realized izzyondroid was only picking up armv8 builds from my github releases. Shouldn't it pick all apks ? Right it means my app are nor compatible with armv7 devices

[IzzySoft]

No, my repo only supports a single APK per release (and a single variant at that). We decided for arm64 here. I don't remember why, because last November (which was when your app was added) unless explicitly requested otherwise, I was still leaning towards 32bit (to also support older devices; back then the Pixel 7+ was the only 64bit device having dropped 32bit support). But it's like with the Highlander: there can only be one. Pure 32bit devices are getting fewer; in a year or two there are probably only few left running on a relatively recent Android version, so I slowly start preferring 64bit builds (for now I usually default to them when APK size is around 25 MB or higher, as to my experience those don't run smoothly on 32bit anyway; again no idea why I did it with yours, which was clearly below 10 MB then).

[farfromrefug]

OK I thought you supported both as fdroid server was supporting this for a while. I can get your why but to be honest to me it excludes too many devices right now (many devices running android 8). If I add universal build with archs apks would you use this one automatically?

[IzzySoft]

as fdroid server was supporting this for a while

Maybe you read this wrong: fdroidserver only can do that if the APKs of a release have different versionCodes. Naming of the APKs creates a "unique ID": <packageName>_<versionCode>.apk. fdroidserver (and also the clients) use the combination of packageName and versionCode to identify an APK. So no, this wouldn't even work with F-Droid.org.

Now you will ask "but there are apps with per-ABI builds at F-Droid"? Yes, and each APK has its own versionCode and its own build block there.

Next expected question: "so if I use different versionCodes per ABI…" – and my answer is: that would work for F-Droid.org, which then builds them from source accordingly. But it wouldn't work with my framework, which only supports one APK per release. My repo is a one-man-show, so I wouldn't even have the resources to change that. And it runs on my personal space, so the limit of 30 MB per app kicks in as well.

TL;DR: please understand that this is not supported with my repo, sorry.

it excludes too many devices right now

That's my argument for usually going with armeabi. But then not only those with their 64bit-only devices complain, but some of those with 64bit-devices which support 32bit as well. You cannot do it right for everyone.

If I add universal build with archs apks would you use this one automatically?

Not automatically, but with a small adjustment in the config for your app here at my end – but yes, that can be done. Same if you want me to switch to the 32bit build. If the resulting universal APK is not larger than ~15 MB, the universal one would be a good option indeed (still allows me to keep 2 versions, so there's no confusion if someone wants to install your app while it was just updated in my repo while their client still has the last day's index). Beyond that I'd only keep 1 APK, so in the described situation the person trying to install it would get a 404.

[farfromrefug]

@IzzySoft thanks for you explanation. You are right f-droid was not supporting that (i think they are doing it right now). I forgot that i used a modified version of f-droid server where i allowed multi arch apks with same version codes! But i totally understand the per app limit on your repo. Are there really some 64 bit only devices? Did not know that.

I will run some tests related to universal apk size but it wight not work as my apps use Nativescript which has some big so libs :(

Thanks again for your time and always kind and respectful attitude! we are lucky to have you!

[IzzySoft]

i think they are doing it right now

as one of the maintainers, I can tell you: no, we don't.

I forgot that i used a modified version of f-droid server where i allowed multi arch apks with same version codes!

:rofl: OK, that explains. But no, I won't apply such a modification except when coming from "upstream". And even then, the 30 MB limit would be a hurdle: 2 separate APKs with a single ABI take up more space than an universal build having both (up to 99% – depending on the size of native stuff compared to the other; if native makes up less than 10% it's definitely not worth having per-ABI builds at all – if it makes up 50%, that's how much bigger a + b are than a ⋃ b).

Are there really some 64 bit only devices?

Currently the Pixel 7+. Some more on the horizon. Google outlined some (as usual vague) reasons for that: "possibly enhanced security", "up to 20% better performance", "up to 150 MB less RAM used" (due to dropping 32bit support and not loading its libs). Read: "possibly", "up to". I know from a smaller vendor of another reason which I can, for a smaller vendor, definitly understand and follow: less testing efforts before releasing another OTA, as there's only a single ABI to test.

Thanks again for your time and always kind and respectful attitude! we are lucky to have you!

Thanks for your kind words – and for your understanding!

[farfromrefug]

@IzzySoft Sorry to bother you. I just realized my apps latest android update was not picked up by izzydroid. https://github.com/Akylas/oss-weather/releases/tag/android%2Fgithub%2F2.8.1%2F138 Is it because latest is actually the ios version? It was built by CI so i dont control which (of ios/android) is released first on github

[IzzySoft]

Is it because latest is actually the ios version?

Quite possible, let me check…

$ iod repo get com.akylas.weather
com.akylas.weather: looking for 'https://api.github.com/repos/Akylas/oss-weather/releases'
com.akylas.weather: checking tag 'ios/alpha/2.8.1/117'
com.akylas.weather: lastRelNo set to 'ios/alpha/2.8.1/117', checking for files

and then of course: no APK. Yupp. But we can fix that I think, let me try… Hah! Gotcha:

$ iod repo get com.akylas.weather
com.akylas.weather: looking for 'https://api.github.com/repos/Akylas/oss-weather/releases'
com.akylas.weather: checking tag 'ios/alpha/2.8.1/117'
com.akylas.weather: checking tag 'android/github/2.8.1/138'
com.akylas.weather: lastRelNo set to '138', checking for files
com.akylas.weather: Upstream file date (2024-10-23 22:36) is newer than ours (2024-10-10 19:43).
com.akylas.weather: returning ['138','https://github.com/Akylas/oss-weather/releases/download/android/github/2.8.1/138/app-arm64-v8a-release.apk',1729715804]
com.akylas.weather: 137/138, https://github.com/Akylas/oss-weather/releases: https://github.com/Akylas/oss-weather/releases/download/android/github/2.8.1/138/app-arm64-v8a-release.apk
- Grabbing update for com.akylas.weather: OK
- Checking 'repo/com.akylas.weather_138.apk' for libraries and malware …
…

OK, that did the trick. I've told it to only consider tags matching the RegEx pattern ^android/github/[^/]*/%c$, where %c represents an integer compared to the latest versionCode present in the IzzyOnDroid repo (i.e. ensuring it only fetches newer releases). That's the pattern you currently use. So now updates should work regardless of the order you release android/ios, as long as you stick to that tag naming pattern. You will, I hope?

[farfromrefug]

@IzzySoft awesome. Yes will always stick to this tag naming. Could you also apply this to https://github.com/Akylas/OSS-DocumentScanner https://github.com/Akylas/conty

Thanks

[IzzySoft]

Those already have it :smiley: