Inclusion in F-Droid

[robinpaulson]

Hi, I'd like to include this in f-droid, the FLOSS repository for Android and derivatives. Before I request its inclusion, I have a question: are there any included pieces of software, libraries or other items which the software requires, which are not free/open, i.e. released under a FLOSS licence?

Cheers

[freshollie]

As far as I know, yes. The only libraries which are used can be found in the build.gradle.

    compile 'com.android.support:appcompat-v7:27.0.2'
    compile 'com.android.support:design:27.0.2'
    compile 'com.android.support:preference-v14:27.0.2'
    compile 'com.android.support:support-vector-drawable:27.0.2'
    compile 'com.android.support:cardview-v7:27.0.2'
    compile 'com.android.support.constraint:constraint-layout:1.0.2'

These libraries are released under the apache licence, I am pretty sure.

[robinpaulson]

Marvellous. I have a couple of minor requests from the f-droid maintainers: could you include the "distributionSha256Sum", in gradle/wrapper/gradle.properties.

More info here: https://docs.gradle.org/current/userguide/gradle_wrapper.html#sec:verification

The request here in more detail: https://gitlab.com/fdroid/rfp/issues/890#note_137878548

Also, could you please match versionName and tag name for your releases? This will make it easier for future releases to be automatically updated. Info here: https://gitlab.com/fdroid/rfp/issues/890#note_137907736

Many thanks, looking forward to using this, I only have a proprietary GPS at the moment.

[freshollie]

Fixed by d44311a0145e54c2f42360e7d41dbafd1ea8c4d4

[robinpaulson]

Hi again Ollie, I forgot all about this for the last 6+ months, then needed it today, when poking around with an external GPS. The app isn't in the F-Droid repo. I think it's because the tag name and version name don't exactly match; looking in the "Releases" page on Github, the two fields are different for the last release:

Tag: v2.2.0 Version: v2.2.0 - Android 8+ notification fixes (major version bump to indicate fix)

From my experience, the title (in this case, "Android 8+ notification fixes (major version bump to indicate fix)" usually goes in the freeform part of the release form, not in the "version" field. For the F-Droid scanner to properly pick it up and import it, it must be identical to the "tag" field.

For an example, take a look at this, a release overview from software I maintain, also in the F-Droid repo: https://github.com/martykan/forecastie/releases/tag/v1.13.5

Do ask if there are any questions, I'm keen to get this on my device.

[freshollie]

Hi @robinpaulson, that's interesting, I assumed the title was just the release title. I have changed to match the tag, not sure if F-Driod will pick this change up.

[robinpaulson]

Yes, that's the style. I honestly don't know if fdroid will pick it up. We'll be able to tell in a day or so, it'll get a listing in here:

https://gitlab.com/fdroid/fdroiddata/blob/master/metadata/

[robinpaulson]

Also, I've been asked to implement Fastlane as a way to provide a description and other metadata for the app in the fdroid repo.

https://gitlab.com/snippets/1895688

I can put together a PR with the appropriate files in, write a description or two and take some screenshots, but I'll need help with some parts.

Edit: the maintainers have suggested doing the fastlane compatibility work first. I'll send a PR within a couple of days.

[robinpaulson]

the maintainers have suggested doing the fastlane compatibility work first. I'll send a PR within a couple of days.

I've mostly done this, am waiting for confirmation that my fork is organised correctly, I'm not sure on how to write and format the version number

https://github.com/robinpaulson/UsbGps4Droid

[IzzySoft]

@freshollie thanks for merging the Fastlane branch @robinpaulson created. As a last step before the packagers can be triggered, that needs to be covered by a tag. I'll describe this examplary for an imaginary new version 2.2.1, assuming you'll create a new tag (though I'm not sure as apart from Fastlane there were no commits since the last release):

• adjust versionName as usual (v2.2.1)
• increase versionCode as usual (199)
• in fastlane, add a 199.txt (<versionCode>.txt) file inside changelogs/, describing what's new
• now add a tag on top: v2.2.1 (corresponding to versionName)

Let us know when it's done, so we can update the RFP and notify the packagers. Thanks!

[freshollie]

@IzzySoft is it required to create a new release for this change? If the fastlane files currently reference the current build, can I move the git tag to the fast lane commit without rebuilding binaries and bumping the version?

[robinpaulson]

[Please take with a pinch of salt/do your own research, this may be incorrect].

You can move tags around as you suggest, but it's generally frowned upon in the git world to not do so. Once you've created a tag, it's considered best to leave it as-is, and to then make another tag and everything which goes along with it.

I don't recall the exact logic, but it's something to do with how those tags propagate to forks of your repo, it causes some minor weirdness I believe.

[robinpaulson]

There's a discussion here, on whether or not to repurpose git tags: https://linux.die.net/man/1/git-tag

The interesting bits starts at "Discussion", about 1/3 down the page.

[freshollie]

I would totally agree robin, but in this case, the actually output of the repo has not changed, so the tag moving is just to signify to F-Droid to package the app. If this repo was larger, I wouldn't consider this, but I'm inclined to be lazy here and I highly doubt it's going to affect anyone.

[IzzySoft]

can I move the git tag to the fast lane commit without rebuilding binaries and bumping the version?

From our point of view (disclosure: I'm one of the F-Droid maintainers), as this is the first release we'd build that's absolutely fine (and you can skip the first 3 steps from my above list). But as Robin pointed out, this should be an exception for several reasons; once your app was build by/for F-Droid, that'd be just another reason on top :wink:

[freshollie]

@IzzySoft @robinpaulson tag moved to fastlane commit. I feel dirty, but as long as F-Droid picked up this release, I won't move the tag from now on.

[IzzySoft]

Thanks Ollie! I fully understand your feeling (what it makes look that ugly is the time span since the original tag). Let me help you out of it by slightly changing the point of view:

You didn't move the tag "up", you just moved the Fastlane "down into" :smile:

Better now? :rofl:

I've updated the RFP and pinged our packagers to pick up. :crossed_fingers: