Put app in F-Droid.

[landry314]

The old QuickDic was in F-Droid... it would be nice to put this new app in F-Droid too!

[rdoeffinger]

As much as I like F-Droid, I completely failed to understand how I could easily create, test and submit an app to it (especially how to test a metadata file seems not to be explained anywhere at all).
I think you'll have to find someone on their side to do it, or provide a vastly simplified step-by-step description of how to do it.

[yourealwaysbe]

I'm willing to give this a go, but i'm having trouble compiling at the moment. My main error is that i don't have the com.hughes.util package. Where should i get this from? (If i set fdroid to use QuickDicUtils, i get stuck with a username/password request for code.google.com)

Perhaps the gitlab page on contributing has some more helpful instructions on testing metadata files.

[rdoeffinger]

On 2 November 2015 21:05:42 WET, yourealwaysbe notifications@github.com wrote:

I'm willing to give this a go, but i'm having trouble compiling at the
moment. My main error is that i don't have the com.hughes.util
package. Where should i get this from?

You should just need to get the rdoeffinger/Util repository in addition.
I think that's all that's necessary.

[yourealwaysbe]

Apologies, i think i'm going to need a lot more help. How should i go about building this?

I can get rdeoffinger/Util, but i don't know what to do with it as there is no obvious build file. Should i be copying it somewhere into the Dictionary project?

Moreover, the build tends to fail for the simple reason that the build/ directory does not exist. I can manually create this and things get a bit further, but unfortunately the fdroid assembly step automatically deletes it and i can't find a good way of creating it again.

[yourealwaysbe]

Ok, i think i've managed to get it to a state where it could get into fdroid, but there are a couple of issues it would probably be better to fix first:

• add to mksmallicu.sh the line
  mkdir "$(dirname "$DST")"
  before the first cp command.
• change something so that ../Util/src is not needed as a source location for the build. It might be better perhaps to include Util as a git submodule. That way the build.gradle can refer only to its own subdirectories rather than external projects.

For the fdroid build i'm currently working around the issues with prebuild commands. The first by using sed to insert the needed line, the second by copying Util/src into Dictionary/src. Neither of which are ideal.

[rdoeffinger]

The mkdir solution is questionable (at least needs to use -p), as is my use of hard-coded "build/", as the build path could be at a completely different location.
I rewrote that code in a way that it provides proper dependencies (I hope).
I had to work around bug GRADLE-2638 though...

As for submodules, I read up on them and they are still as broken as they used to be, e.g. not handling git checkout correctly.
I haven't read up on the alternatives like git subtree but from what others say, they are basically all crap, just in different ways (yay for developing 3 broken solutions instead of one that actually works).
Why can't F-Droid check out multiple source repositories? I mean to copy Util/src into Dictionary/src you must have checked out Util already, why is it not working from there? Or is the issue something specific about using ".."?

[rdoeffinger]

More specifically, would it help to change that to "Util/src" and have Util checked out into Dictionary/Util?
If anything else is a pain I can just use a submodule of course, I just lean towards preferring not to at the moment.

[yourealwaysbe]

I rewrote that code in a way that it provides proper dependencies (I hope).

Cool -- i'll try it with fdroid in the next couple of days.

Or is the issue something specific about using ".."?

Having external libraries is fine with fdroid, but i'm just not sure exactly where it puts them :) -- certainly ../Util/src does not point to the right place. You can reference the library directory in the metadata via a variable, so if the gradle build could take the location as an argument via the commandline (or some other configuration e.g. file) that would work. (To copy the Util directory i was doing something like "cp $utildir$ src/".)

I don't know enough about gradle to know how you could do that though.

[rdoeffinger]

Gradle knows variables as well so it might "just work" if you replace ".." with "$utildir"?
If it's an environment variable (which it is if your cp is a commandline command?), "$System.env.utildir" should do it instead.
Obviously a proper solution would need a fallback so it works if it isn't set, but that should be doable (I assume) once we know how it would work.

[yourealwaysbe]

It's not quite an environment variable, but i think it's easy to make it one. I will have a play next time i'm free and let you know what works.

[yourealwaysbe]

I had a play. mksmallicu.sh no longer fails, thanks.

For the util directory, i couldn't figure out how to get environment variables to make their way through. An alternative is to use gradle.properties. I changed build.gradle to contain

def utildir = hasProperty("quickdicUtilDir") ? quickdicUtilDir : "../Util"

android {
    ...
    sourceSets {
        main {
            manifest.srcFile 'AndroidManifest.xml'
            java.srcDirs = ['src', utildir + "/src"]

Then it will use ../Util/src by default, but if you create a file gradle.properties

quickdicUtilDir=<path to util>

it will use the new path.

I can then set up fdroid to create the properties file before the build.

Let me know if this sounds reasonable.

(It's weird, fdroid has a "srclib" feature for libraries containing only source code, but beyond giving you the directory where they're stored, i can't find a canonical way of dealing with them in the build.)

(Ah, these slides seem to go for echoing the directories into a properties file also.)

[rdoeffinger]

If that seems like a reasonable solution to you I am fine with it.
Should I hack it in (at some point soonish) or do you want to sent a pull request of a tested version?

[yourealwaysbe]

I was being a bit lazy thinking you could just copy-paste the code in, but on reflection it would be better if i put in a pull request for a tested version. I will do that in the next few days.

Are you ok with me tying the f-droid version to the tags you've been using? That way, each time you add a new tag, f-droid will automatically add a new version. It can also be done via version information in the AndroidManifest.xml if you'd prefer.

[rdoeffinger]

If you asked me to, I'd just copy-paste it in. I'd also accept copy-pasted diffs. A pull request is just the most reliable way :).
I prefer tags over the AndroidManifest.xml, as I will change that for e.g. testing as well.
But I don't know how the tag-based system works.
I need to be able to still create tags that don't trigger a build (e.g. because they are for some special feature/debug/whatever) and I also need tags for beta versions - whether they get build as F-Droid beta versions or not at all I don't mind, but they should not appear as full releases.
I can commit to (almost) whatever naming scheme for the tags that would enable this most easily.

[yourealwaysbe]

I attempted a pull request for the change, hopefully it came through ok.

For the tags, i can specify a regex in the metadata so that fdroid only checks tags of a certain format. I've gone for

    v[0-9]*\.[0-9]*\.[0-9]*

for now. If this is ok, and the util location patch can be put with some tag, hopefully we can get it into fdroid :)

[rdoeffinger]

Is that regexp full-match?
I mean, does it end up matching v1.2.3-testing?
If yes, it maybe should be put in-between ^$.
Is there a need/desire for tags on Util or are we fine with assuming latest will always work (I don't plan changes to it, so likely to work for the time being, but worth a thought still)?
I might set a new tag for a new release during this weekend.

[rdoeffinger]

Possibly it was a bad idea, but as your patch was a build-system-only change I moved the v5.1.3 tag to include it.
So you may be able to test with that already now.

[yourealwaysbe]

If yes, it maybe should be put in-between ^$.

A good point! -- i'll make it a full match.

I'm not sure how the tagging works with Util, so we can leave it as latest for now. If it changes just let me know and i'll change the fdroid entry.

Hopefully i can test and submit tomorrow evening!

[yourealwaysbe]

Submitted -- will hopefully appear soon!

[landry314]

awesome! :-)

[yourealwaysbe]

Would you be happy with the following regex for releases

^v[0-9.]*$

I.e. an arbitrary number of levels (v5.1.1.1, v5, v5.1 &c).

[rdoeffinger]

Would you be happy with the following regex for releases

^v[0-9.]*$

I.e. an arbitrary number of levels (v5.1.1.1, v5, v5.1 &c).

Seems fine to me, too.
Though I do expect to stick to the major.minor.micro scheme.

[yourealwaysbe]

It is arrived :)

[rdoeffinger]

Should we close this then?
If everything works, it should pick up the next release soon.
One other thing: Is it easily possible to add signature verification for the tags?
While I sometimes forget to sign them, it would be slightly nicer if not anyone with access to the github repo (e.g. all github server admins, anyone breaking into my github account...) could make releases.

[yourealwaysbe]

Cool -- i'll look out for the new release.

I'm not sure about signing. I can't see anything in the manual that appears to support it. I can make an issue on their gitlab page if it's important.

[rdoeffinger]

About checking tag signature: As we'd still use the latest version of Util without any checking it's kind of pointless for us for the moment.
It would be a fairly good idea to at least have support for it in principle, so raising it as a "nice to have" feature request would probably make sense regardless.
But it's not important really I'd say.

[landry314]

was it not possible to put the new version in the same entry on f-droid? now there are two when you search... and someone with the old version will not be notified that a new version exists.

[yourealwaysbe]

On the technical side, i think this would require changing the app ID back to the ID of the original. I figured, as there's no official handover and a different ID, i'd treat it as a fork. Though i agree it would be good to link it to the old, i'm not sure how.

[ghost]

I think that one here can be closed. The old version got a link/note to the new forked version and the old version probably will be archived on f-droid: https://gitlab.com/fdroid/fdroiddata/merge_requests/1081#note_2879087

[rdoeffinger]

I'll close it then, feel free it reopen if there's a need.
Note that I got the official ok from the original developer to take over (though a bit after I started the fork), but that doesn't change much from the play store side: The account and the signing key are different, so using the same app ID would (as far as I know) cause serious issues.
I can't say whether it would be possible for F-Droid to handle this differently, but I guess it might be best to leave it this way for consistency anyway.

[rdoeffinger]

The 5.2.1 version failed to build.
Going by the messages, Utils is stuck at an old version instead of being updated to latest.
From https://gitlab.com/fdroid/fdroiddata/blob/master/metadata/de.reimardoeffinger.quickdic.txt:
srclibs=QuickdicUtilsRestored@d57bfc6bcf5b
Can you take a look?

[yourealwaysbe]

Ah -- that's annoying. I don't recall adding the commit ID to the srclib. I
will look into this later today/tomorrow morning.

Best,

Matt

On Fri, Dec 18, 2015 at 09:38:04am -0800, Reimar Döffinger wrote:

The 5.2.1 version failed to build.
Going by the messages, Utils is stuck at an old version instead of
being updated to latest.
From
[1]https://gitlab.com/fdroid/fdroiddata/blob/master/metadata/de.reimard
oeffinger.quickdic.txt:
srclibs=QuickdicUtilsRestored@d57bfc6bcf5b
Can you take a look?

—
Reply to this email directly or [2]view it on GitHub.

References

1. https://gitlab.com/fdroid/fdroiddata/blob/master/metadata/de.reimardoeffinger.quickdic.txt
2. Put app in F-Droid. #5 (comment)

[rdoeffinger]

No hurry, and thanks.

[pizzamaker]

It would be great to see this happening :)

[ghost]

@pizzamaker The app is available at f-droid since a few months:

https://f-droid.org/repository/browse/?fdid=de.reimardoeffinger.quickdic

[pizzamaker]

Oh nice! Thanks