Submit to F-Droid - Githubissues

simison commented 9 years ago

Please. :-)

dg0yt commented 9 years ago

I would be glad to see Mapper on F-droid. But Mapper isn't a simple Android app. As a native app, it has a quite heavy dependency on the Qt framework. So far I haven't found other apps which could serve as a guide, nor sufficient documentation. This would take away time from other issues.

But it is a nice isolated task for volunteers...

rugk commented 8 years ago

:+1: for this. And I think the Qt dependency should not be a problem as long as the apk is buildable from source. :smiley:

BTW here is a HowTo: https://f-droid.org/wiki/page/Inclusion_How-To

dg0yt commented 8 years ago

:+1: from me, too.

There is no lack of How-To. There is lack of people contributing time and results. Building for F-Droid is perfectly separate task.

rugk commented 8 years ago

What about a "good volunteer task" label or something similar? :smiley:

dg0yt commented 8 years ago

We had such a label... But I didn't find it 5 minutes ago...

rugk commented 8 years ago

Probably just the default "help wanted"?

bagage commented 7 years ago

I am almost done with this, but I'd like one bug to be fixed before submitting it to F-droid. Currently if you build mapper using the following (which is basically what Fdroid robot will do):

export Qt5_android=$QT_PATH/android_armv7
$Qt5_android/bin/qmake
make

You end up with the following doxygen error:

CMake Error at cmake_install.cmake:42 (file):
  file INSTALL cannot find
  "/tmp/mapper/doc/manual/manual/html/graph_legend.png".

Currently I'm "fixing" it by running make || cp doc/manual/manual/html/tab_a.png doc/manual/manual/html/graph_legend.png && make, which is not very proper. But I cannot find what is generating this manual and from where graph_legend.png should come from… Any help would be welcome :).

dg0yt commented 7 years ago

graph_legend.png sounds like a file coming with doxygen. Check the doxygen version, check the scripts in doc/manual/

bagage commented 7 years ago

OK, this is a problem with doxygen packaging on Debian then. I am forcing the build of doxygen for fdroid.

Application submitted here.

bagage commented 7 years ago

Application is now available.

rugk commented 7 years ago

Awesome, so I think this issue an be closed.

dg0yt commented 7 years ago

Nice. There are some issue to be solved or documented:

The Mapper license is GPL-3. This needs to be fixed ASAP.
The F-Droid build uses Qt 5.7. This has not been tested much with Mapper.
The F-Droid build is signed with a different key than our APKs. This can result in the loss of data files when replacing the APK from one source with that from the other source. This could be mitigated by giving the F-Droid app a different identity, but this might also require some adjustments in the documentation with regard to storage paths. (We could add F-Droid sections to the documentation and activate them by special build parameters.)
And of course someone has to take care of pushing new releases to F-Droid.

bagage commented 7 years ago

Oops, will fix
Yes, but there is no way to use Qt5.6 so… have to deal with it. At least it starts :). Not tested it much though, because I cannot open my map (cf #802).
Nothing we can do here - it's by design how F-Droid works. Of course we could use another identifier, but what would be the point? You should use either one or the other of these methods, not both.
It is done automatically by a f-droid bot - each new tag will automatically generate a new Fdroid version as well (which is nice to have an automatic updated version on the phone).

dg0yt commented 7 years ago

BTW I'm not convinced that F-Droid properly provides the corresponding sources as required by GPL... It provides the Mapper sources, but not those of third party components which end up in the APK (Qt etc.).

Another thing is that I am about to remove the 3rd-party superbuild from the Mapper repository (moving it to a dedicated superbuild project). This means that the current approach won't work any longer. Perhaps one could pull the superbuild like we pull individual 3rd-party component builds now. But I will probably not work on that - In my setup, it is the superbuild which delivers the release APKs.

bagage commented 7 years ago

I don't see any issue with sources distribution: they can provide anyone third party components if needed.

When superbuild comes in, some one will have to adapt the fdroid build but it should be just fine (pulling superbuild repository instead). I don't see any major issue here; it would be great to announce it some time before actually merging it so that one can adopt the build setup.

dg0yt commented 7 years ago

The F-Droid APK has no translations, manual, proj data in the assets folder. I'm not maintaining this package, so I don't want to see this as an issue reported here.

bagage commented 7 years ago

Regarding incomplete APK, it's the best I could do regarding my inexperience with QT - lack of translations is probably the biggest (and only one for me) issue. But at least having Mapper on one app market so that it can be automatically updated to newest versions etc. is what I needed so I'm fine with the missing features. And still, anyone can submit changes to improve the application on f-droid.

dg0yt commented 7 years ago

IMO the lack of proj data is the biggest issue: It means that georeferencing is likely to be completely broken, affecting templates and GPS. And you want both.

sikmir commented 7 years ago

It is done automatically by a f-droid bot - each new tag will automatically generate a new Fdroid version as well (which is nice to have an automatic updated version on the phone).

@bagage It's not like that, 0.7.0 is not available.

UPD: as wiki stated:

We can't build this version: The build for this version was manually disabled. Reason: patches do not apply

sikmir commented 7 years ago

@bagage Is it feasible for this package to be listed on repology.org? For now, it says openorienteering-mapper is absent in F-Droid repository.

jmacura commented 4 years ago

@bagage Hi! If I understand it correctly, the last version available in F-Droid is currently still v0.6.8. Is there any chance to update the build process there and allow automated releases again?

bagage commented 4 years ago

Sorry guys I don't plan to work on that anymore, it's too much time invested for almost nothing. Cheers!

dg0yt commented 4 years ago

Sorry guys I don't plan to work on that anymore, it's too much time invested for almost nothing. Cheers!

@bagage Thanks for your work and for the clarification! It is sadly true that users underestimate the amount of work which needs to be put in proper packaging alone, especially with all the dependencies which come with Qt and GDAL. Mapper itself is just the tip of the packaging iceberg.

Is there a way to remove the outdated version from F-Droid?

rugk commented 4 years ago

Is there a way to remove the outdated version from F-Droid?

They automatically move it into an archive if it doe snot get updates for a long time IIRC.

ghost commented 4 years ago

JFTR, As workaround for F-Droid users, it would be cool if @IzzySoft would add official Mapper APK-builds in his repo — then official OpenOrienteering-Mapper-*-Android-*.apk builds & updates would be accessible directly throw F-Droid client with enabled IzzyOnDroid Android App Repository:

https://apt.izzysoft.de/fdroid/index/info

IzzySoft commented 4 years ago

Well, I could do that for the armeabi package (link will show real data in about 20h, after the next sync has been completed) – all others are beyond the current limits (30M per app). Would be nice if there were some screenshots available; ideally you could setup Fastlane file structures and also include (short) per-release changelogs :wink:

dg0yt commented 4 years ago

Thank you @IzzySoft.

Just for my understanding: The IzzyOnDroid repository deploys our APKs without modifications?

armeabi is a good start. But at least the arm64 package is most important now (and still very close to 30 MB): geodata might make good use 64 bit. Most of the size is related to the Qt and GDAL libraries. With some configuration tweaks, I can probably achieve a small reduction for the next release.

Note that only vX.Y.Z marks official releases. The master and dev releases are for testing and use different app IDs so that they can be installed in parallel to the official releases. They don't have to be in F-Droid.

IzzySoft commented 4 years ago

The IzzyOnDroid repository deploys our APKs without modifications?

Exactly. The very ones provided by the project's developer(s), usually attached to the corresponding releases/ at Github/GitLab/Codeberg.

But at least the arm64 package is most important now

Sorry. In cases of multi-arch I generally take the "smallest common denominator", which is armeabi (usually v7). This is understood by all "higher" archs (v8, arm64). And it's often the smallest package and thus the one less likely to strike the limit. I run on personal resources here, so resources are limited. Also, to my knowledge, most devices are still 32bit. Further, the 64bit APK is already on the limit (30M) – and future releases tend not to get smaller (going backwards, both packages grew by 500k, 200k, 8M, 0, 0, 0, 200k – never anything got smaller, in the best case it kept the size).

With some configuration tweaks, I can probably achieve a small reduction for the next release.

Technically, I can easily switch to that (it's as simple as adjusting the RegEx matching the file name). I'd make that exception if you really feel it that much difference and importance (after all, it will "lock out" many users; I've just checked my device list, only 1 out of 3 is arm64, and that's even the oldest one).

Note that only vX.Y.Z marks official releases.

Thanks, I can pin updates to that (currently they are pinned to "releases", ignoring "pre-releases" – which as-of-now is a 1:1 relation; if you think that changes, I can additionally define the pattern for the tag name, to be on the safe side – done).

dg0yt commented 4 years ago

packages grew by 500k, 200k, 8M, 0, 0, 0, 200k

Sure. In our case, this is mostly due to adding libraries for geospatial vector and raster data formats.

I've just checked my device list, only 1 out of 3 is arm64

Do armeabi installations of F-Droid report the arm64 cabability of the device they are installed on?

But the F-Droid offer is a convenience option anyway, so armeabi is probably good enough for now, until arm64 is really dominant.

dg0yt commented 4 years ago

currently they are pinned to "releases", ignoring "pre-releases"

This should work if I never get the checkmarks wrong :-) This is set to prerelease by default anyway when draft GH releases are created from our Azure Pipelines job.

IzzySoft commented 4 years ago

Do armeabi installations of F-Droid report the arm64 cabability of the device they are installed on?

I doubt that is anything special to F-Droid (or wherever an app is installed from). It's a question of the device (or the ROM on it). Technically, devices announce that via primaryABI and secondaryABI. My only arm64 device announces that as "CPU compatibility: arm64-v8a,armeabi-v7a,armeabi". So the armeabi variant would show up as "compatible".

And as I wrote: should the necessarity arise, I can switch that (and certainly would consider that the day 32bit ARMs are the minority and their 64bit sisters take over). Further, the source is named (even the releases page is linked), so people can follow-up to pick the other variant if they want.

This should work if I never get the checkmarks wrong :-)

Don't worry: I've added the "double-check". It's now set to releases-only with tag name v<versionName>, so we're on the safe side. You'd need to get two things wrong for my updater to pick up what it shouldn't :smile:

jmacura commented 4 years ago

@IzzySoft @dg0yt Thank you very much, I have already updated the Mapper in my tablet via Izzysoft's repo! :rocket:

OpenOrienteering / mapper

Submit to F-Droid #517