Be in F-Droid

[interfect]

Here's how to get into F-Droid.

We should be able to use most of https://gitlab.com/relan/fennecbuild/ and https://github.com/interfect/fenix/blob/5387b7464ed88051b159d417153d7286229ac7ce/org.mozilla.fenix_fdroid.yml from Mozilla Fenix's packaging and get in.

Someone has to work through the procedure, make sure the local fdroid build bot can build it, make sure it knows to build the right release type (forkRelease for us) and make an MR over on Gitlab.

[TheEvilSkeleton]

I opened an issue in the F-Droid RFP repository. I hope one of them will be able to help you

[TheEvilSkeleton]

Hints to the maintainer:

• make a flavor that comes without proprietary dependencies (here: Firebase)
• make sure to only use trusted maven repos – what's not available from any of those can be established either as git submodule or srclib (check our fdroiddata repo for already existing srclibs to see what's covered)

Thanks for reaching out to us, and best luck in solving the "deal breakers"!

https://gitlab.com/fdroid/rfp/-/issues/1459#note_404173201

[TheEvilSkeleton]

@interfect feel free to talk with the F-Droid maintainers: https://gitlab.com/fdroid/rfp/-/issues/1459

[esmoak]

I know Izzy chimed in on the F-Droid request thread, but I wonder if he might pick this up for his repo:

https://gitlab.com/IzzyOnDroid/repo

[interfect]

I think the F-Droid PR is blocked on getting all the telemetry stuff ripped out.

I want to apply https://gitlab.com/relan/fennecbuild/-/blob/master/fenix-liberate.patch but it's in an AGPL repo, so I opened https://gitlab.com/relan/fennecbuild/-/issues/4 about getting permission to use it in an MPL project without having to AGPL the result.

If that isn't forthcoming, we can duplicate the work using the patch as a guide to what needs to be touched, or else just duplicate the way the patch is applied at build time in the Fenix F-Droid build in whatever build script we use.

[jaytohe]

Any progress on getting this up on F-Droid?

[TheEvilSkeleton]

Any progress on getting this up on F-Droid?

Yes, @interfect applied the Liberate patch in Iceweasel: https://github.com/interfect/fenix/issues/25, but I am not sure if it is actually working: https://github.com/interfect/fenix/issues/60

[TheEvilSkeleton]

@interfect it'd be better if we move the chat to GitLab: https://gitlab.com/fdroid/rfp/-/issues/1459

[goodevilgenius]

In case y'all are unaware, it should be noted that Mozilla is working on this for Fenix Firefox itself: https://github.com/mozilla-mobile/fenix/issues/162

Any changes they make there towards F-Droid compliance should be less work for Iceweasel.

[TheEvilSkeleton]

unknown maven repo should be a hint :)

https://gitlab.com/fdroid/rfp/-/issues/1459#note_407705270

[relan]

Note that you can always run your own F-Droid repository or ask Izzy to grab APKs from the releases page into his repo.

[CharmCityCrab]

In case y'all are unaware, it should be noted that Mozilla is working on this for Fenix Firefox itself: mozilla-mobile#162

Any changes they make there towards F-Droid compliance should be less work for Iceweasel.

This is good news and probably ensures IceWeasel can eventually get in, if there was any doubt to begin with.

However, I do think there is still a first-mover advantage here that IceWeasel can grab by getting into F-Droid first with it's own code.

If IceWeasel can beat Firefox in, any F-Droid enthusiasts who don't use Google Play but who do want a Gecko-based browser that has updates beyond the end of Fennec, are extremely likely to give IceWeasel a chance if it's there when they are looking for it, and then when Firefox hits the stage, so to speak, may stay with IceWeasel because they are happy with it, or switch to Firefox but be very aware of the IceWeasel alternative in the event that they should find themselves dissatisfied with Firefox. Ultimately, this would result in IceWeasel having a much bigger slice of the F-Droid Gecko-based pie than it will have of the overall Android Gecko-pie or on other platforms where Firefox struck first.

Of course, I assume relan's unbranded Fenix-based F-Droid compatible project (Which I understand to be a relatively straight forward clone of Firefox without the Firefox branding, with necessary modifications made to be listed in F-Droid. I could be wrong about those specifics.) will either beat us in or land at a similar time, and that's fair enough. I still think there is an advantage in getting to F-Droid second to his browser relative to being third or beyond after Firefox, which is the real heavy hitter that F-Droid users who search and see at the top of the list may not look beyond in many cases, lands.

I really do view all three projects as important strategic allies in a lot of ways. Relan's code for his fork and help has been very important to IceWeasel's efforts here, as I understand the situation, anyway, and of course we rely heavily on Firefox for code on an on-going basis. The more of these projects, the better. All these browsers are also in the "trying to preserve a non-Chromium web rendering engine option that has good web compatibility" thing together.

Last I checked IceWeasel was using Firefox-Fenix's user agent string, which is probably just to make sure users are being fed the appropriately formatted web pages while browsing, but also may be a way of helping Mozilla out by combining our marketshare the way some outlets measure marketshare, and hoping that gives them the influence to have a say in standards instead of Google just deciding everything by fiat and then getting it rubberstamped later as the official standard after it's already been made the defacto standard. Of course, I wouldn't mind a separate user-agent string for IceWeasel either to help determine this browser's specific following, but I have no strong opinion to that effect (Probably if IceWeasel did adopt it's own UA string, just from a practical perspective, it'd have to have an override in place for sites that lock it out or feed it an incompatible page, where it revert to tell such sites it was Firefox, essentially).

However, I don't view minor strategic considerations like trying to get on F-Droid before Firefox by a decent margin as being not in the spirit of that- we're not slowing done Mozilla's efforts in any way, shape, or form. In fact, they could of course adopt the code developed here under it's open-source licenses and get in the day after us if they really wanted to (I doubt they will, because they seem to prefer to develop their own code, but they could, and they'd have every right to just as IceWeasel has every right to keep using Mozilla's code.).

Later, when and if Firefox becomes compatible, IceWeasel could then evaluate whether it makes more sense to rip out it's own code and use the Mozilla code to stay closer to upstream and make it easier to maintain, or whether it's own code is better overall even with the on-going added maintenance burden taken into consideration (Remember, Firefox is ultimately going to have telemetry, what they'd be doing is getting rid of proprietary telemetry, so anything based on hypothetical Firefox official F-Droid code is still going to have stuff in that IceWeasel is probably going to want to remove or not adopt on general principle, even though it'd comply with F-Droid guidelines in this hypothetical.). Any potential switch from the IC code to FF code after IC has entered FD would simply be an update, invisible to any end-user not reading the update notes or studying the code- it shouldn't make a difference to the browsing experience of the end-user.

Of course, the maintainers/developers are the appropriate ones to figure all this out, not just because they are in charge, but also because it's their time that's being devoted to writing code that may be redundant later. So, they have to decide if that's worthwhile for them or not, which is not a call I can make, both because I don't know how much extra work it is, and because I don't know how highly they value the strategic importance of being first and so on and so forth. I also don't know how far along they already are with this (Obviously, "nearly finished" is a different calculus than "10% down, 90% to go").

However, I did want to jump in here and at least say the words "first-mover advantage" to make sure it was being considered. :)

Once I have brought something to the attention of the people who make the decisions, in some respects, my work is done. ;) They can decide what they want to do based on the information provided and their personal expert knowledge of the coding and technical maintenance side of the equation. :)

[CharmCityCrab]

Also, literally as I was writing the above, relan posted the following over in the Mozilla issue surrounding getting Firefox added to F-Droid:

"Meanwhile, another proprietary library (com.google.android.play:core) was added in 365d101. 😞"

Our devs may want to make sure they exclude that when porting over the latest updates from Mozilla if possible, so we don't set our progress back on this issue.

[bbigam]

Also, literally as I was writing the above, relan posted the following over in the Mozilla issue surrounding getting Firefox added to F-Droid:

"Meanwhile, another proprietary library (com.google.android.play:core) was added in 365d101. disappointed"

Our devs may want to make sure they exclude that when porting over the latest updates from Mozilla if possible, so we don't set our progress back on this issue.

And good relan has already updated the liberate patch to exclude the new dependency! https://gitlab.com/relan/fennecbuild/-/commit/d8a40373afa8c117dd4a10c445617c17fa309b0e

[bbigam]

I'm trying to patch out the new Play Store dependency and do a little more cleanup based on relan's work, but please check my work carefully because it's my first ever PR: https://github.com/fork-maintainers/iceweasel/pull/76

[bbigam]

PR https://github.com/fork-maintainers/iceweasel/pull/76 was merged and now there's no Play Store dependency.

[abhijitvalluri]

Is the current state of this fork acceptable for inclusion in F-droid or should more be done?

[abhijitvalluri]

Also, it looks like the Fennec browser in F-droid uses a recolored version of the official Firefox logo. Is that allowed? If so, we could probably do something similar rather than the IceWeasel logo, which I am not a fan of.

[rugk]

Fennec browser in F-droid uses a recolored version of the official Firefox logo. Is that allowed?

https://www.mozilla.org/en-US/foundation/trademarks/policy/

I'd say, no:

Choose branding, logos, and trademarks that denotes your own unique identity so as to clearly signal to users that there is no affiliation with or endorsement by Mozilla.

(etc.)

[cleanerspam]

@interfect Please make it available on IzzyOnDroid Repo As the creator of repo summarises

it holds open-source-apps that for some reason didn’t make it into the official F-Droid repo or are no longer updated there. Those reasons usually have to do with proprietary dependencies introduced into the apps.
as an F-Droid maintainer put it, it also serves as a **stepping stone for projects wanting to be included in the official repo**, but yet have to solve such dependencies. Once they’re done with that job and listed on the official repo, they’re usually removed from IzzyOnDroid’s again (mostly to avoid confusion due to signature mismatches).
if you know a fitting app that’s neither in this nor in the official repo, you can visit IzzyOnDroid Repo’s Repo at GitLab and let me know, so I can include it if possible.

[interfect]

Is the current state of this fork acceptable for inclusion in F-droid or should more be done?

I think we've gotten all the closed source stuff ripped out, and the fennec-build build scripts seem to be in a state where they can be adapted to work for us pretty easily. (We need them because we depend on a bunch of code, like android-components, not in this repo, and they know how to build all that stuff.)

Someone just has to sit down, figure out how F-Droid really works, set up a build driven by (a version of?) those scripts, test it, and MR it into F-Droid.

[ildar]

Someone just has to sit down, figure out how F-Droid really works

@relan knows this part very well.

[interfect]

OK, I have an F-Droid YAML that is at least starting to work:

https://gitlab.com/interfect/fdroiddata/-/tree/iceraven

To use it you have to:

1. sudo apt-get install -y g++ python-setuptools tcl gyp ninja-build libffi-dev libsqlite3-dev mercurial llvm-6.0
2. Clone this and current master fdroidserver
3. Put frdoidserver repo root on yout PATH
4. fdroid init
5. Make sure $ANDROID_HOME is set
6. ${ANDROID_SDK_ROOT}/cmdline-tools/tools/bin/sdkmanager "ndk;21.3.6528147"
7. Edit config.py and point ndk 21d at $ANDROID_SDK_ROOT/ndk/21.3.6528147
8. fdroid build -v -l io.github.forkmaintainers.iceraven

Currently it gets stuck because the current version of the liberate patch in https://gitlab.com/relan/fennecbuild/-/blob/master/fenix-liberate.patch can't apply on our codebase. The already-applied hunks are not a problem, but some hunks actually become "FAILED". We need to tweak our code so those hunks look already applied, according to patch.

[physkets]

Well, looks like the Fennec will be updated to the new Fenix:
https://forum.f-droid.org/t/welcome-a-new-fennec-f-droid/11113

[hbarsaiyan]

Well, looks like the Fennec will be updated to the new Fenix:
https://forum.f-droid.org/t/welcome-a-new-fennec-f-droid/11113

I guess this puts us in a tough spot in a sense that we need to clear our position on how we differ from Fenix. I mean we do have distinct features like the old tab layout and ability to install more extensions but if in the future firefox incorporates them then we may not be very different from fenix.

[CharmCityCrab]

Well, looks like the Fennec will be updated to the new Fenix: https://forum.f-droid.org/t/welcome-a-new-fennec-f-droid/11113

I guess this puts us in a tough spot in a sense that we need to clear our position on how we differ from Fenix. I mean we do have distinct features like the old tab layout and ability to install more extensions but if in the future firefox incorporates them then we may not be very different from fenix.

We knew this was coming- well, we knew part of it was coming. We didn't know that they were going to specifically going to keep a browser called Fennec, but start basing it on Fenix and update existing Fennec users to it, but we did know that a more straight forward modern Firefox clone was in the works for F-Droid (We just figured it'd get a new name and not be an automatic upgrade for users of the, um, version of Fennec based on Fenix).

Relan is the author of parts of our (Iceraven) patch that in theory eliminates Mozilla's proprietary telemetry. I connected the early Iceraven project with him to try to get that because there was no sense in doing the same work twice (It's open-source code so we technically didn't have to ask, but I did inquire and he gave us his blessing). He didn't write the code intiially for us, though, he wrote it for this, so we knew it was out there.

Your point is well taken, though. We do need to define ourselves distinctively relative to Firefox and Fennec (powered by Fenix). That doesn't mean we can't share code where it makes sense and have good relationships with these other projects- where it makes sense, we should, and of course, technically, we have to at least make the code freely available under it's open-source licenses.

All of that could be very helpful to all three browsers, because they are all, including Firefox, at least a tad understaffed, and some good developers work for each of them.

It does mean that we can't just be a Firefox clone, though, or even a Firefox clone that just makes the minimum changes needed to get into F-Droid. Those markets are both taken- and, actually, an officially branded Mozilla Firefox may be coming to F-Droid, too- there has been an open issue on their GitHub about it for a long time now, it's not a lock until it happens, but it looks likely.

However, I don't think Iceraven was ever just intended to be a Firefox clone the way Fennec-brsnded Fenix is, even though it's a close fork.

Some distinct areas of focus for Iceraven are having as many user-facing options as possible, being as customizable as possible, providing as much extension support as possible, and giving users the ability to see as much and as detailed information as possible about what their browser and the website servers connected to it are doing and making that information as easy to access as possible. What Vivaldi is to desktop Chromium, Iceraven could be to Android Fenix.

Firefox talks about doing some of that stuff, but because there is a strong faction in their camp that wants to compete with Chrome on Chrome's terms and focus on speed and simplicity at the expense of some of those other priorities, it's got to balance some things that Iceraven doesn't. Iceraven can to some degree have the freedom to shrug and always pick user options, customization, and access to knowledge over speed and simplicity, figure it'll inherit enough speed and simplicity from upstream to get by and that users won't mind it being just a tad slower or requires a tad extra thought if it means they get a browser that they can do more and do it the way each user wants to do it.

But of course presenting a different visual look is one aspect of that, which is why when we added pre-Firefox 79 style tabs, I pushed for them as the default for new installs. I don't know if I won that one or not (It's set that way on mine, but I can't remember if it came that way or I had to enable it), but the option is there. Similarly, we also have full URLs including protocol and www available- that one isn't the default for sure, but it's a prominently placed option (I enabled it immediately with gusto. We could consider making it the default for new installs if we wanted another little difference, but I don't think Firefox even has the option).

I've mentioned trying to always open new tabs to the end of the list instead of at the beginning, or at the end of a list of related tab, making the latest tab the one at the bottom, always. That hasn't been implemented, but it's something that could be included as a default or an option. I think it's an open issue.

Someone was talking about a more information packed security certificate page, which would be cool.

We could get better more grandular cookie management integrated.

Export and import bookmarks in HTML.

We could start using that home page thing for things that aren't just collections and blank space (I think Firefox recently added top sites, which Iceraven definitely already has). Make it pick your favorite two categories of a list of things like bookmarks, history, top sites, recently closed tabs, collections, etc.. We definitely push collections a lot less, while still including them for those who want them. Someone has an issue listing for at least filling the page with top sites instead of just two lines, which would at least beat what Firefox does IMO.

There are a lot of things like that which could be explored. If we got a server and someone who can do it, we could consider our own extension repo that people could submit to that Iceraven could use in addition to the stuff on the Mozilla page.

There are things that we can do differently to match what Iceraven has always been intended to be, and sometimes do differently just to do differently.

We did just use the first-mover advantage in getting into F-Droid, though, and we are not on Google Play yet either. I think those might be areas that would be good focuses. I also think, if there was any doubt, the fact that we are likely to be one of three Firefox type browsers on F-Droid should encourage us to make a Google Play listing a strong priority as well (Both open issues).

Now, being open-source, yes, technically, Firefox, and by extension Fennec Fenix-edition (Which is basically a no proprietary telemetry clone), could take all of Iceraven's current and future options (Firefox actually did queue up some code already created for and implemented in Iceraven as the basis for a feature in some future version of Firefox- directly. The dev who did it here was formally invited to submit the patch there if he wanted to.). But they probably won't except in select cases. If Mozilla really wanted to do what we want in totality, the last 15 years of net browser history would have gone very differently (and Fenix would never have been released in the condition it was in, and would have been designed differently from early development on). They can be the browser for people who want what they want, and Iceraven can be the browser for people who want what we want.

If Firefox ever does have all the options Iceraven has, it's a sign that Iceraven needs to add more options. ;)

There is also definitely a case for non-FF defaults to give Iceraven a different out of the box feel right away, though, for sure.

Firefox is going to mature some and offer more than it offers now, which is more than it offered at Fenix launch. Some of it will come straight from Iceraven code, but we rely on their code for a lot more than they rely on our code for. If they take our code under the license it's been issued under, that's just how open-source software works. It's a compliment, really.

In a way, it'd be good to see Firefox be exactly like us in the sense that it they become like Iceraven, Iceraven will have pushed them there, which means it'll have done something good for the entire Gecko ecosystem.

But I would be in favor of an options list like Vivaldi for desktop eventually, where you can just scrolll and scroll and it feels like you'll never reach bottom.

[interfect]

I guess this puts us in a tough spot in a sense that we need to clear our position on how we differ from Fenix. I mean we do have distinct features like the old tab layout and ability to install more extensions but if in the future firefox incorporates them then we may not be very different from fenix.

Being an open-source all-volunteer project, we don't have the same sorts of user-acquisition concerns that Mozilla Firefox does. If people have features they want that Iceraven can provide and Mozilla's product team doesn't want to implement or take, then they can use Iceraven. If they're happy with the decisions Mozilla's product folks make, then they can use Firefox. There's not a scarcity of space in F-Droid for both. If it turns out that by this time next year Fenix Firefox has closed enough of the feature-parity gap with Fennec that everyone is happy with Firefox and nobody wants to maintain Iceraven, then everyone's happy with Firefox.

Articulating exactly what the project mission is is worth doing; we shouldn't take literally any PR Mozilla won't, no matter how terrible. I think we have some text that speaks to that in the README. My understanding is that we're shooting to provide more customization options, less heavy-handed guidance towards Mozilla services, and the ability to turn on things that aren't necessarily safe, advisable, or likely to work, but still be a stable browser by default. I'm also interested in demystifying the process of building and maintaining a browser; I got tired of people on the Firefox subreddit throwing up their hands and saying "whelp that's how it is" every time they didn't like something, instead of wading in like good open source user-contributors. One should be able to produce their own builds without much knowledge of Android or browser development.

[TheEvilSkeleton]

Well, looks like the Fennec will be updated to the new Fenix: https://forum.f-droid.org/t/welcome-a-new-fennec-f-droid/11113

I guess this puts us in a tough spot in a sense that we need to clear our position on how we differ from Fenix. I mean we do have distinct features like the old tab layout and ability to install more extensions but if in the future firefox incorporates them then we may not be very different from fenix.

I don't think it's a big deal. Fennec F-Droid's goal was to deblob Firefox, but Iceraven's goal is to 1. deblob it (which they got a lot of help), and 2. bring more features. Iceraven already differs from Fenix in my opinion.

[interfect]

Instead of fixing our source to let us re-apply the liberate patch, I'm just going to drop the patch application by sed-ing the build script.

Also, apparently to really get the r21d NDK set up right, you need to:

cd $ANDROID_SDK_ROOT/ndk
wget https://dl.google.com/android/repository/android-ndk-r21d-linux-x86_64.zip
unzip android-ndk-r21d-linux-x86_64.zip
mv android-ndk-r21d r21d

Then you set your config.py for F-Droild like this:

ndk_paths = {
    'r21d': "$ANDROID_SDK_ROOT/ndk/",
}

Because F-Droid wants to find the r21d NDK in an r21d folder. See e.g. https://gitlab.com/fdroid/fdroidserver/commit/ddefec33cdeafeee5db41cef965fa568a1d9fb11

[interfect]

We also need r20d via similar steps. And "Android build-tools version 29.0.3", obtained by doing $ANDROID_SDK_ROOT/cmdline-tools/tools/bin/sdkmanager "build-tools;29.0.3"

[interfect]

OK, now the build wants Autoconf 2.13, apparently exactly, and that's very old. Apparently Ubuntu packages this as the autoconf2.13 package, probably because building Gecko needs it. After installing that, I also did sudo ln -s /usr/bin/autoconf2.13 /usr/local/bin/autoconf213 as suggested here.

[interfect]

Now I've got this:

 1:17.84 FAILURE: Build failed with an exception.
 1:17.84 * Where:
 1:17.84 Build file '/z/home/anovak/workspace/fdroiddata/build/srclib/MozFennec/mobile/android/geckoview/build.gradle' line: 5
 1:17.84 * What went wrong:
 1:17.84 A problem occurred evaluating project ':geckoview'.
 1:17.84 > Failed to apply plugin [id 'com.android.library']
 1:17.84    > Minimum supported Gradle version is 5.1.1. Current version is 4.4.1. If using the gradle wrapper, try editing the distributionUrl in /z/home/anovak/.gradle/daemon/4.4.1/gradle/wrapper/gradle-wrapper.properties to gradle-5.1.1-all.zip
 1:17.84 * Try:
 1:17.84 Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
 1:17.84 * Get more help at https://help.gradle.org
 1:17.84 BUILD FAILED in 43s
 1:18.27 Traceback (most recent call last):
 1:18.27   File "/z/home/anovak/workspace/fdroiddata/build/srclib/pyenv/versions/3.8.5/lib/python3.8/runpy.py", line 194, in _run_module_as_main
 1:18.27     return _run_code(code, main_globals, None,
 1:18.27   File "/z/home/anovak/workspace/fdroiddata/build/srclib/pyenv/versions/3.8.5/lib/python3.8/runpy.py", line 87, in _run_code
 1:18.27     exec(code, run_globals)
 1:18.27   File "/z/home/anovak/workspace/fdroiddata/build/srclib/MozFennec/python/mozbuild/mozbuild/action/file_generate.py", line 124, in <module>
 1:18.27     sys.exit(main(sys.argv[1:]))
 1:18.27   File "/z/home/anovak/workspace/fdroiddata/build/srclib/MozFennec/python/mozbuild/mozbuild/action/file_generate.py", line 72, in main
 1:18.27     ret = module.__dict__[method](output, *args.additional_arguments, **kwargs)
 1:18.27   File "/z/home/anovak/workspace/fdroiddata/build/srclib/MozFennec/mobile/android/gradle.py", line 57, in assemble_app
 1:18.27     return android('assemble-app')
 1:18.27   File "/z/home/anovak/workspace/fdroiddata/build/srclib/MozFennec/mobile/android/gradle.py", line 51, in android
 1:18.27     subprocess.check_call(cmd, env=env)
 1:18.27   File "/z/home/anovak/workspace/fdroiddata/build/srclib/pyenv/versions/3.8.5/lib/python3.8/subprocess.py", line 364, in check_call
 1:18.27     raise CalledProcessError(retcode, cmd)
 1:18.28 subprocess.CalledProcessError: Command '['/z/home/anovak/workspace/fdroiddata/build/srclib/MozFennec/obj/_virtualenvs/init_py3/bin/python', '/z/home/anovak/workspace/fdroiddata/build/srclib/MozFennec/mach', 'android', 'assemble-app']' returned non-zero exit status 1.
 1:18.29 backend.mk:812: recipe for target 'mobile/android/base/.deps/android_apks.stub' failed
 1:18.29 make[3]: *** [mobile/android/base/.deps/android_apks.stub] Error 1
 1:18.29 /z/home/anovak/workspace/fdroiddata/build/srclib/MozFennec/config/recurse.mk:32: recipe for target 'export' failed
 1:18.29 make[2]: *** [export] Error 2
 1:18.29 /z/home/anovak/workspace/fdroiddata/build/srclib/MozFennec/config/rules.mk:384: recipe for target 'default' failed
 1:18.29 make[1]: *** [default] Error 2
 1:18.29 client.mk:125: recipe for target 'build' failed
 1:18.29 make: *** [build] Error 2

[hbarsaiyan]

@interfect don't know if it helps but this is what i found https://gitlab.com/fdroid/rfp/-/issues/709#note_99484379

[interfect]

Relan suggested symlinking linking the gradlew-fdroid wrapper from fdroidserver as gradle in your PATH, and that gets the build a lot further by magically choosing the right Gradle version.

Now I get stuck on this:

> Task :glean:generateToolchains FAILED
Toolchain for arch arm version 21 does not exist: checked /scratch/tmp/rust-android-ndk-toolchains/arm-21
/z/home/anovak/workspace/fdroiddata/build/srclib/pyenv/versions/3.8.5/bin/python: can't open file '/scratch/home/anovak/android-sdk/android-sdk-linux/ndk/build/tools/make_standalone_toolchain.py': [Errno 2] No such file or directory

I think that script only comes with very old NDK versions, but we still somehow need it.

EDIT: Actually the script still comes with each NDK, just in the NDK's own directory. I'm now trying a more specific NDK path again:

ndk_paths = {
    'r21d': "$ANDROID_SDK_ROOT/ndk/r21d",
    'r20b': "$ANDROID_SDK_ROOT/ndk/r20b"
}

[interfect]

Then it picked up an old SDKManager that is upset with the current Java. I've tried:

/scratch/home/anovak/android-sdk/android-sdk-linux/cmdline-tools/tools/bin/sdkmanager --update
/scratch/home/anovak/android-sdk/android-sdk-linux/cmdline-tools/tools/bin/sdkmanager 'cmdline-tools;latest'
/scratch/home/anovak/android-sdk/android-sdk-linux/cmdline-tools/tools/bin/sdkmanager --uninstall 'cmdline-tools;1.0'
cp /scratch/home/anovak/android-sdk/android-sdk-linux/cmdline-tools/tools/bin/* /scratch/home/anovak/android-sdk/android-sdk-linux/tools/bin/
cp -R /scratch/home/anovak/android-sdk/android-sdk-linux/cmdline-tools/tools/lib/* /scratch/home/anovak/android-sdk/android-sdk-linux/tools/lib/

[interfect]

Nope. That doesn't work either. I'll try this:

cat >/scratch/home/anovak/android-sdk/android-sdk-linux/tools/bin/sdkmanager <<'EOF'
#!/usr/bin/env bash
echo sdkmanager "$@"
/scratch/home/anovak/android-sdk/android-sdk-linux/cmdline-tools/tools/bin/sdkmanager "$@"
EOF
chmod +x /scratch/home/anovak/android-sdk/android-sdk-linux/tools/bin/sdkmanager

If that doesn't make it build, I'll give up and see if I can get F-Droid to actually test it on their infrastructure instead of OOM-ing as soon as it tries to get the Gecko sources.

[interfect]

I got a bit further:

~/workspace/fdroiddata/build/srclib/MozAppServices
Looks good! Try running the test suite with `cargo test`
Picked up _JAVA_OPTIONS: -Djava.io.tmpdir=/scratch/tmp
sdkmanager ndk;21.3.6528147
Picked up _JAVA_OPTIONS: -Djava.io.tmpdir=/scratch/tmp
[=======================================] 100% Computing updates...             
info: component 'rust-std' for target 'aarch64-linux-android' is up to date
info: component 'rust-std' for target 'armv7-linux-androideabi' is up to date
info: downloading component 'rust-std' for 'i686-linux-android'
info: installing component 'rust-std' for 'i686-linux-android'
info: Defaulting to 500.0 MiB unpack ram
info: downloading component 'rust-std' for 'x86_64-linux-android'
info: installing component 'rust-std' for 'x86_64-linux-android'
Incompatible java version: 11.0. JDK 8 must be installed.
==== detail end ====

But don't we need JDK 11 to actually build the app???

[interfect]

I figured I might have more luck with the Vagrant-based setup where you do your builds in a VM (see https://f-droid.org/en/docs/Build_Server_Setup/ under "Setting up a build server"), so now I'm trying that.

[interfect]

OK, I'm trying a new strategy: making a Vagrant-managed F-Droid build vm with ./makebuildserver from fdroidserver, and then building with --server, so the build runs in the same environment it will on F-Droid's infrastructure. I've had to hack the ./makebuildserver script to get it working in my environment, but it seems to be much happier.

[interfect]

OK, I've given up on trying to test the F-Droid build. The --server and ./makebuildserver setup seems incapable of actually running on my machine (an Ubuntu 18.04 machine with KVM for virtualization and all the data stores moved off the tiny /). I think I'd need to reinstall my system, possibly with straight Debian or whatever the F-Droid folks use.

But, I've squashed and rebased my MR to fdroiddata, and I've claimed it's ready. They claim that they can take PRs that the submitter can't test.

If anyone knows who at F-Droid ought to take a look at it, y'all can let them know it's ready. It can't build on their CI system due to resource constraints, so someone is probably going to have to manually look at it.

[bitsper2nd]

Try asking Relan in gitlab. He is the one that works on Fennec, fdroid's firefox fork.

[hbarsaiyan]

@interfect maybe we can use IzzyOnDroid Repo for the time being

It is an F-Droid style repository for Android apps, provided by IzzyOnDroid. Applications in this repository are official binaries built by the original application developers, taken from their resp. repositories (mostly Github).

[interfect]

@bitsper2nd I've corresponded with Relan a bit, which has been quite helpful, but I don't want to page Relan constantly just because I can't get the basic F-Droid project infrastructure working in my environment.

@hbarsaiyan We could try that until we get the main F-Droid repo working. Looks like we might need special dispensation for our large APKs, but maybe they'll grant it? I'll try and ask.

[interfect]

I've opened a PR to Izzy's repo, which can supposedly grab the builds from Github: https://gitlab.com/IzzyOnDroid/repo/-/issues/136

[bitsper2nd]

I've opened a PR to Izzy's repo, which can supposedly grab the builds from Github: https://gitlab.com/IzzyOnDroid/repo/-/issues/136

I'm sad to read it got rejected. I don't mind grabbing apks from github. I already use an app to browse this site. The other alternative for those that want convenience might be making your own repo like Bromite.

[CharmCityCrab]

I've opened a PR to Izzy's repo, which can supposedly grab the builds from Github: https://gitlab.com/IzzyOnDroid/repo/-/issues/136

I'm sad to read it got rejected. I don't mind grabbing apks from github. I already use an app to browse this site. The other alternative for those that want convenience might be making your own repo like Bromite.

Getting listed on Google Play (Issue #71 ) could be prioritized more. It looks like there was a way forward that was found a while back and it just hasn't been followed through on yet. That's not a criticism, there are only so many developer hours available- I'm just saying, we could probably be on Google Play by now if we really wanted to be, and there's no question that's where most of the potential users are.

My impression is that the type of re-engineering of the product that is going on in this issue isn't really necessary for Google Play.

Obviously, the project would continue to publish apk files for direct downloads and keep trying to get into F-Droid if possible. There is nothing about being in Google Play that precludes that. However, putting more emphasis on getting into Google Play than has been put into it so far could be a solution to getting the browser in front of users and providing a trusted (by some) third-party updater that automatically scans the code and such (And of course those users who don't like Google Play would still have at least one, and hopefully two, other options- the apk downloads and perhaps F-Droid).

[bbigam]

I think that Iceraven will need a proper signature before going into the Play Store, though.

On Sat, Oct 10, 2020, 2:03 PM CharmCityCrab notifications@github.com wrote:

I've opened a PR to Izzy's repo, which can supposedly grab the builds from Github: https://gitlab.com/IzzyOnDroid/repo/-/issues/136

I'm sad to read it got rejected. I don't mind grabbing apks from github. I already use an app to browse this site. The other alternative for those that want convenience might be making your own repo like Bromite.

Getting listed on Google Play (Issue #71 https://github.com/fork-maintainers/iceraven-browser/issues/71 ) could be prioritized more. It looks like there was a way forward was found and it just hasn't been followed through on yet. That's not a criticism, there are only so many developer hours available- I'm just saying, we could probably be on Google Play by now if we really wanted to be, and there's no question that's where most of the potential users are.

My impression is that the type of re-engineering of the product that is going on in this issue isn't really necessary for Google Play.

Obviously, the project would continue to publish apk files for direct downloads and keep trying to get into F-Droid if possible. There is nothing about being in Google Play that precludes that. However, putting more emphasis on getting into Google Play than has been put into it so far could be a solution to getting the browser in front of users and providing a trusted (by some) third-party updater that automatically scans the code and such.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/fork-maintainers/iceraven-browser/issues/26#issuecomment-706588748, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQQNFQ7QAHEJ5XEVJHMY4JTSKCOXZANCNFSM4QNWLT2Q .

[abhijitvalluri]

Signing it for play store is trivial and is not a big deal. Also, I think Play Store now prefers you let them sign it for you so you don't have to do anything either. But I think starting now or sometime very soon, new apps uploaded to play store need to be in the Android App Bundle format (.aab) rather than the .apk format. Currently our gradle build creates as apk. So need to check how to make an aab and if that is involved to make that change. And potentially make it so you can continue to create .apks as well.

[rugk]

Also, I think Play Store now prefers you let them sign it for you so you don't have to do anything either.

Which is awful, BTW… 🤐

[abhijitvalluri]

Why is it awful? I have no idea as I never did that before.