search

benibela / videlibri

:books: Cross-platform library client to automate any OPAC and library catalog from your local device, e.g. for renewing of borrowed books or searching for books available in the library in automated scripts.
https://www.videlibri.de/
GNU General Public License v3.0
36 stars 5 forks source link

Publish on F-Droid #3

Closed linsui closed 2 years ago

linsui commented 3 years ago

Hi, I'm a contributor of F-Drdoid and I'm working on build your app with F-Droid's toolchain and publish it. There is a metadata in F-Droid'repo but it doesn't work. Since it's submitted to F-Droid long ago and never built, I don\t know if you support the inclusion.

So hereby I want to ask for your permission. And if you support the inclusion, could you please help me build it? Thanks!

benibela commented 3 years ago

So hereby I want to ask for your permission. And if you support the inclusion,

Yes. I had submitted it there myself. But I was told, it could not be included, because it depended on Lazarus, and that is too big for the build server

So meanwhile, I have changed it to not depend on Lazarus anymore, although I had no time to update the build script

could you please help me build it?

You can follow the Travis script and line 101. The hardest part is perhaps installing FreePascal like that.

And the log contains the params for calling FreePascal for arm, line 30267ff

linsui commented 3 years ago

Thanks! I'll have a try.

benibela commented 3 years ago

How is it going?

linsui commented 3 years ago

Sorry, I didn't make it work and haven't found time to try it again.

benibela commented 3 years ago

well, if anyone wants to try again, here are tutorials on how to set up FreePascal:

https://wiki.freepascal.org/Android

https://wiki.freepascal.org/Android_Build_APK (videlibri does not need the aapl/javac steps)

https://wiki.freepascal.org/LAMW_on_Linux (videlibri does not need the lazarus steps)

https://wiki.freepascal.org/fpcupdeluxe (GUI installer)

IzzySoft commented 2 years ago

If you could provide the APK file (ideally attached to its tag at releases/) and it's not beyond the size of 30M, I could offer to take the app into my repo until the listing at F-Droid.org succeeds.

benibela commented 2 years ago

I always upload the apk on Sourceforge: https://sourceforge.net/projects/videlibri/files/VideLibri/

Over the last weeks I have set up automated building on Github Actions. Now there is always an (unsigned) apk for the most recent commit, like https://github.com/benibela/videlibri/actions/runs/2523765414

IzzySoft commented 2 years ago

Hm, I'd need a signed APK. And my updater doesn't work with SF; it only supports Codeberg, GitLab and Github.

benibela commented 2 years ago

now it is signed

IzzySoft commented 2 years ago

Thanks, but still only via SF, right? As pointed out, my framework does not support SF so I cannot pick it from there automatically – which means updates will be missed or at best much delayed if I'd have to check manually – apart from the fact that I lack the time for "manual hunting". Is there a chance you can make it available here, as described above?

benibela commented 2 years ago

It is in the Github Action artifacts.

It should be copied to the releases automatically. Probably it happens on the next tagging

IzzySoft commented 2 years ago

Ah, I see. Can you send me a ping when that happens? Then I can see if I can pick it up.

jugendhacker commented 2 years ago

@benibela could you please confirm, I still need FreePascal to build the whole app right?

benibela commented 2 years ago

could you please confirm, I still need FreePascal to build the whole app right?

yes. not just FreePascal, but FreePascal 3.2.3.

benibela commented 2 years ago

Ah, I see. Can you send me a ping when that happens? Then I can see if I can pick it up.

@IzzySoft now it is there

IzzySoft commented 2 years ago

Ah, that was a close call – managed to integrate it seconds before the update process started :smile: So in about half an hour, your app will become available here.

Please leave this issue open: my repo is just a "pre-stage". All looks fine going by my scanner's results – so once the building issues have been solved, inclusion at F-Droid can be tackled. When that's done and your app is listed at F-Droid.org, I usually remove it from my repo again about 10 days later – unless being asked explicitly to keep it (for whatever reason). So just let me know in time if you want it to stay there. Should you need some background, you can find it in this FAQ.

IzzySoft commented 2 years ago

Just wondering: as you're using ACRA, have you made sure it's explicitly set to opt-in? By default, if not explicitly told otherwise, it will be sending silent reports without asking the users' consent.

benibela commented 2 years ago

Yes, it uses the dialog

IzzySoft commented 2 years ago

Thanks! I hope I read that correctly as "the dialog, only the dialog and nothing but the dialog"? :see_no_evil: Then let me whitelist ACRA for your app.

PS: MaintainerNote added: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11474

benibela commented 2 years ago

I hope I read that correctly as "the dialog, only the dialog and nothing but the dialog"?

of course

PS: MaintainerNote added: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11474

ty. looks like it is now live in the real f-droid.

I have been getting a lot of ACRA reports now. How do I know if they are from fdroid or the google app store version?.

With NDK 21 it does not run on Android older than 6 due to https://github.com/android/ndk/issues/964

Perhaps everything works with NDK 19

IzzySoft commented 2 years ago

ty. looks like it is now live in the real f-droid.

It is. And usually, around 10 days later to give it some overlap, I'd remove it from my repo unless explicitly requested otherwise. That OK with you, or would you prefer I kept it? For some background, see here.

How do I know if they are from fdroid or the google app store version?

Sorry, I cannot tell. You'd need to include some hints if you need to know, e.g. the signature hash. I'm no Android dev, so I cannot really answer this (or the remaining 2 questions).

benibela commented 2 years ago

And usually, around 10 days later to give it some overlap, I'd remove it from my repo unless explicitly requested otherwise. That OK with you, or would you prefer I kept it?

Perhaps let it there to see how stable the github built vesion is. Eventually, I want to replace the app store version with the github version

Sorry, I cannot tell. You'd need to include some hints if you need to know, e.g. the signature hash. I'm no Android dev, so I cannot really answer this (or the remaining 2 questions).

The NDK probably needs ndk: r19c in the yml

IzzySoft commented 2 years ago

Perhaps let it there to see how stable the github built vesion is. Eventually, I want to replace the app store version with the github version

OK, I've set it to stay.

The NDK probably needs ndk: r19c in the yml

You're welcome to try: just open a corresponding MR at fdroiddata and se what results the CI yields. If the build succeeds, there should be an unsigned APK you can pull, self-sign and test it it works as expected. If it does, please include a hint with MaintainerNotes (in the YAML) why the NDK needs to be "lowered".

benibela commented 2 years ago

I tried. An MR apparently needs a fork. I once sent an MR, so I already had a fork, but Gitlab said I cannot edit the file because it is not in my fork (because the fork is too old). So I deleted the fork to make a new one. Now it says, I cannot edit the file, "You are not allowed to push into this branch". I should edit it in my fork, but it says I cannot open the fork because it has been deleted. I should click the fork button to make a new fork, but it only wants to open the old one and then fails because it has been deleted: grafik

perhaps it needs a few hours to sync itself

IzzySoft commented 2 years ago

You are not allowed to push into this branch

master/main is usually protected. But in your own fork, you're the owner and should be able to.

The other part is strange: no, it shouldn't take hours. Does it let you use a different name for your fork? Then you could try that. Apart from this, it's always preferable to use a local clone, gives you much more flexibility (and you avoid running into several issues with GitLab's built-in editor). So say you created a fork benibela/fdroiddata, the next steps would be, locally on your machine:

# clone the fork
git clone git@gitlab.com:benibela/fdroiddata
# add the upstream repo so you can fetch updates
cd fdroiddata
git remote add upstream git@gitlab.com:fdroid/fdroiddata.git
# check out a new branch to work on
git checkout -b videlibre-ndk
# now make the changes
cd metadata
vi de.benibela.videlibri.yml
# and check them in when done
git add de.benibela.videlibri.yml
git commit de.benibela.videlibri.yml
git push origin videlibre-ndk
# the output will now include a link to let you open a merge request.
# ...
# outdated? Simply refresh and (optionally) update your fork at GitLab:
git checkout master
git pull upstream master
git push origin master
# get rid of old branches. If you set them to be deleted when your MR was merged (I usually do), git lets you list obsolete ones:
git fetch --prune origin
git branch -d videlibre-ndk

That way you won't need to create new forks everytime – you can easily refresh your own.