Iceraven-browser: 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 [e-mail]
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.

[hbarsaiyan]

aab will be enforced in the second half of 2021for newly published apps and we can change the distribution from apk to aab later on if we want. IMO it's better to go with apk since aab are too much of a hassle to install if you download from outside the play store.

[interfect]

Why is it awful?
It sets the Play Store as the root of trust for your app instead of you the developer, and means you don't have a copy of the key to publish updates in any other way.

But it's also having the store sign is the way F-Droid works, so maybe it depends on who's doing it.

[abhijitvalluri]

It sets the Play Store as the root of trust for your app instead of you the developer, and means you don't have a copy of the key to publish updates in any other way.

But it's also having the store sign is the way F-Droid works, so maybe it depends on who's doing it.

From what I understand from Google's help page and documentation on this and also instructions on how to set it up on Stackoverflow it seems that you need to upload your private key etc. to Google's server. So, in other words, you create the keys you will use for signing, manually. And then upload it to Google. So in otherwords, you will still have access to those keys, right? So if you wish you can still sign the apks on your own.

I did a fairly brief scan of the documentation so may be I am missing something, but that is what I gathered.

[interfect]

Hm. I guess I guessed wrong about how it works.

Anyway, on the actual topic of this issue, I finally got the F-Droid build vm working, but I'm having trouble setting up the recipe to build mutually-compatible versions of everything. Something is going wrong in my Glean build due to a missing build task or something. I can post a log later.

[interfect]

Here's the misbehaving build log.
log.txt

[ildar]

the related discussion @ F-Droid:
https://forum.f-droid.org/t/google-also-now-managing-app-sigining-keys-like-f-droid/491/

[abhijitvalluri]

the related discussion @ F-Droid: https://forum.f-droid.org/t/google-also-now-managing-app-sigining-keys-like-f-droid/491/

Interesting. Also, feels like there is a lot of unwarranted paranoia and fear mongering in that F-Droid discussion thread. So Google doing something exactly the same as F-Droid is cause for concern, but F-Droid doing that isn't? Sometimes I cannot get behind the level of skepticism and paranoia displayed in FOSS circles. But sorry, I am totally derailing this topic. I shall shut up! 😄

[rugk]

Funny to hear that in an issue of a degoogleified Firefox browser. If not (reasonable!) paranoia is what drives this de-googlefying what else...

Anyway, actually there is a big difference: F-Droids builds the things from source and you can verify that. It's even possible reproducible. Google may do the same, but it's just their build and you cannot verify that.
Before you handed over your private key to Google you still had a way to verify that once you've installed the app, only the app developer/publisher could publish it. (kind of TOFU) This is now gone and Google can modify/publish any app under any name.

[michaelprager]

Yes this can easily be overlooked when out of context. The big difference is the dev only provides the sourcecode, fdroid provides the build. With public access to the code, the end user can determine if what is published as code is what we actually installs. There is nothing comparable when going the google play route.

[CharmCityCrab]

Interesting. Also, feels like there is a lot of unwarranted paranoia and fear mongering in that F-Droid discussion thread. So Google doing something exactly the same as F-Droid is cause for concern, but F-Droid doing that isn't? Sometimes I cannot get behind the level of skepticism and paranoia displayed in FOSS circles.

I agree with you 100%. Most Android users exclusively use Google Play as their source of apps. They already trust Google Play and will continue to. In that scenario, there isn't really any additional risk to getting Iceraven through Google Play. And this will make it easier for you guys to submit Iceraven to Google Play.

F-Droid has been re-signing apps for years, as has Amazon and (on iOS) Apple. This is par for the course and standard operating procedure for popular Android stores/marketplaces/repos..

If things go as seems to be tentatively planned, users will eventually be able select whichever store they want (Google Play, F-Droid) to download Iceraven through, or just keep downloading directly from Github. So, if people are uncomfortable with any of the three options, they can use one of the other two. If they are uncomfortable with all three, I don't know what would make them comfortable or where they get their browsers and other apps from.

Since it sounds like there aren't many barriers to submitting to Google Play, it is a little frustrating to watch people going to elaborate lengths to get on F-Droid, a store most people have never even heard of, while putting the main place people get their apps, and where it is much simpler to get them approved, on the backburner. It sounds like someone could submit the browser to Google Play tonight if they wanted to, whereas this F-Droid thing just keeps dragging on and on because of F-Droid's strict requirements about things that only some people care about. Google Play is where most of your new users will come from in the long run.

By all means, do both, but it'd be nice if someone would just push the Google Play thing through at some point during the long drawn out process to get on F-Droid, since it is comparatively simpler and more important to the browser's future.

[CharmCityCrab]

Funny to hear that in an issue of a degoogleified Firefox browser.

I don't consider Iceraven a degoogleified Firefox browser. At least, I don't consider that to be one of it's primary purposes. Of course it tries to cut out unnecessary and proprietary dependencies and telemetry from all sources, Google included, but that wasn't the reason the project was started or it's primary point of departure from upstream Firefox.

"Our goal is to be a close fork of the new Firefox for Android that seeks to provide users with more options, more opportunities to customize (including a broad extension library), and more information about the pages they visit and how their browsers are interacting with those pages."

[abhijitvalluri]

Funny to hear that in an issue of a degoogleified Firefox browser. If not (reasonable!) paranoia is what drives this de-googlefying what else...

Anyway, actually there is a big difference: F-Droids builds the things from source and you can verify that. It's even possible reproducible. Google may do the same, but it's just their build and you cannot verify that.
Before you handed over your private key to Google you still had a way to verify that once you've installed the app, only the app developer/publisher could publish it. (kind of TOFU) This is now gone and Google can modify/publish any app under any name.

[Apologies for the completely off-topic post that will follow this! I shall not post any further on this tangent]

At best this is De-mozilla-fied browser. A de-googlefied browser would be a variant of Chromium... right? 👀
It seems ludicrous to believe or worry/fear that Google will do anything to damage the reputation of Android and its own Play Store for absolutely zero benefit. They already have plenty of telemetry and other relevant data through the built in telemetry in Android, via the usage of your Google account which is mandatory for using Google Play, etc. After having this wealth of information, it would be downright insane to then go ahead and modify apks using the keys you entrusted them with for absolutely zero benefit.

Firstly, this will be extremely easy to identify. Every app developer can verify the integrity of the apks on Google Play with their own personally created and signed versions. If even a hint of this gets out to the public, there will be massive backlash, lawsuits, class action lawsuits till the next decade or two. The associated loss of trust, reputation, and financial harm it will cause Google is so massive no sane person will ever decide to let this happen at Google. Which is why I correctly called this unwarranted paranoia and fear. With this level of concern, can you even trust Android, even a AOSP ROM version of Android? Perhaps one should use a completely different OS in that instance. iOS is also out of the picture because it is completely closed source and Apple is far more opaque.

[rugk]

whereas this F-Droid thing just keeps dragging on and on because of F-Droid's strict requirements about things that only some people care about.

Well… these exact strict requirements is what you are trying to accomplish with Iceraven: remove proprietary components etc.
As such, this fits perfectly into F-Droid.
Those who want to download a browser on Google Play are less likely to have these requirements and just download Firefox. Nobody cares to find a fork of Firefox there. They would not even know of Iceraven.
I bet more people know of F-Droid than of a Firefox fork called Iceraven.

Your target group very certainly is on F-Droid – not on Google Play, anyway.

That said, you can of course submit it to Google Play, I did not want to argue against that. Just explain the reasoning behind the problem of Google's self-signing.

[abhijitvalluri]

In any case we don't have to let Google self sign of we go via Google Play. It's optional.

[bitsper2nd]

Your target group very certainly is on F-Droid – not on Google Play, anyway.

the target group also uses apps from google play, even if they are downloaded from apk mirror, apk pure, github or even a client that access the playstore like Yalp or Aurora. The target group also uses apps to connect to non-free services and closed servers. At the end of the day is a matter of trust and convenience.

[CharmCityCrab]

Well… these exact strict requirements is what you are trying to accomplish with Iceraven: remove proprietary components etc.
As such, this fits perfectly into F-Droid.

I'm not meaning to suggest that the app isn't a good fit for F-Droid. I've always been of the mind that it should be in both F-Droid and Google Play, and individuals users can choose which one they prefer. Being on F-Droid seems important to the lead developer and will happen eventually, assuming he doesn't get too frustrated with the process of modifying it to meet F-Droid's specifications (Personally, I thought it was a much more important thing when it looked like we'd be the first and possibly the only Fenix-based browser in. Now that we aren't, it doesn't seem as important, though I still believe it should be done at some point).

At the same time, though, Iceraven has never seemed to me to be a browser that is ideologically set against being in a store like Google Play or anything like that. It's not sponsored by GNU. :) I suspect the userbase has varying opinions. The reason for most of the users switching wasn't "Firefox isn't open-source enough", it was "Firefox doesn't give users enough customization, options, and information about how they browse and interact with their browsers and the Internet,.". Basically, people wanted more options. Extensions were a big part of it for many folks. Personally, I could not stand the inability to put protocol and "www" back into the URL bar (Which Iceraven restored). There's a bunch more to it, but a community project with a powerful customizable browser meets our needs much better than what seems to be a stripped down Chrome-ified Fenix Firefox that was clearly delivered from the top down instead of the bottom up.

There's sort of this implicit recognition that while Mozilla and Firefox are more like what we want that Google and Chrome, really neither browser met (or was trying to fully meet) a lot of users' needs entirely, so the closest thing we had that we could rely on for upstream updates was forked. Sometimes where we want to go coincides with what Mozilla is doing (For example, Firefox already has adopted some native Iceraven code, with modifications) and sometimes it is 180 degrees the opposite.

Stripping proprietary elements and telemetry make sense, since it pleases a portion of the current and potential user base, and a small purpose-drive project like this wouldn't likely be overly considered about telemetry results anyway ("Hey, not many people with telemetry turned on use a certain feature. Let's ditch it and six more things besides! Oh, wait, we're not Mozilla? Nevermind.".). The point is to, at least to an extent, actually provide people who want obscure choices obscure choices It's not a least common denominator browser that's aiming to beat Chrome at it's own game and become something it's not in the process. And of course telemetry going to anyone other than Iceraven devs makes even less sense than telemetry in general in the context of the browser.

However, that doesn't preclude a Google Play option where people can download the exact same browser that is available now on Github and will hopefully be available on F-Droid, just with (potentially) different signing signatures (The F-Droid signing signature will always be different from anything else, because they assign one to apps and put the apps instead their own wrapper). The plan isn't to stick telemetry and proprietary elements back in. Google Play may include such elements in it's store, and there may be such elements in Android itself, but anyone going the Google Play route to download the browser already has those things going on with their phone, so it probably isn't a big deal for them. :) Anyway who doesn't have or want Google Play will have two other options (F-Droid store and Github direct download).

Those who want to download a browser on Google Play are less likely to have these requirements and just download Firefox. Nobody cares to find a fork of Firefox there. They would not even know of Iceraven.
I bet more people know of F-Droid than of a Firefox fork called Iceraven.

Your target group very certainly is on F-Droid – not on Google Play, anyway.

My guess would be that Google Play will actually net Iceraven a fair number of random users trying out browsers, including some people who use Chrome on desktop (Some of my push in the icon artwork thread had the undercurrent of picking something colorful that would stand out to those type of folks- though I lost, which is fine. :) An icon isn't everything, and I am sure I will like the final version of the winning entry well enough, though my fingers are crossed for the possibility of a "Pick your own icon" option in the future. :) ). It's not so much that people always go bounding into Google Play looking specifically for a Firefox fork, it's that that's where they look for cool new browsers and whatever looks cool and seems like they will meet their needs. Personally, I am not sure I would mention Mozilla or Firefox at all in a Play store description if it were up to me. Having a mobile browser that provides desktop type power options and customizeability, with full extension support, is potentially appealing to users who gave up on Firefox long ago, or were born past Firefox's peak and will always see it as behind the times, and use various different desktop browsers, or don't even have a desktop at all (Increasingly the case with young people).

I think in that environment, we would be competing with a bunch of Chromium forks for users who don't know or care what we're a fork of. There aren't even a whole lot of browsers on Google Play that support extensions at all, let alone regularly updated ones. Yet, there are Chrome users on Windows, where Chrome has extensions, who will want an experience with extensions on mobile and are indifferent to the underlying code and where it may be forked from. Ditto Edge for Windows users.

I've also seen people on Reddit and elsewhere (Some of them Firefox users) who want to try Iceraven, but don't trust apk downloads and don't want to install F-Droid. For them, Google Play is what they trust, and they don't want or need any additional app stores. There are even users who know about all this stuff and who's main store is Google Play, who can do the F-Droid or direct download thing, but would rather have Iceraven in with everything else they use on Google Play.

Really, putting the browser in both stores and providing downloads at the same time is just providing people options- which is sort of a meta version of what the mission of the browser itself is in terms of what's inside the software. :) Everyone does what they are comfortable with or prefer.

That said, you can of course submit it to Google Play, I did not want to argue against that. Just explain the reasoning behind the problem of Google's self-signing.

It sounds like maintainers still have the option of signing their own Google Play apps (Something F-Droid does not allow). However, someone mentioned developing a signature Google Play would accept as a potential roadblock, so someone else pointed out that if the devs don't want to devote time to figuring that out or have trouble doing it, Google offers the option of signing it itself. It's just an alternate path they could take to move things along and save themselves work, not a strict requirement.

[CharmCityCrab]

Um, incidentally, I apologize if any of that offended anyone.

I realize that there are people from the free as in freedom (or open-source) software community here, some of them because I specifically mentioned the browser in an F-Droid sub-reddit back closer to when the browser first began development.

Obviously, I really value having everyone here and don't want to make it sound like anyone and their viewpoints aren't 100% welcome and part of the community from my point of view. I think it's great that we have some of that constituency and hope the browser does get listed in F-Droid and continues to meet their needs.

The truth is, any browser probably has several main constituencies, that's certainly one of Iceraven's. I'd even like to think that I helped built it up here to at least some small degree (Though I may be vastly overestimating my own significance in that regard).

My point was just that, really, that there are also users who would prefer to get their updates from Google Play, and an additional audience we could reach from Google Play, and we could probably get on there relatively quickly if we put more emphasis on it. And we could do all that without giving up on F-Droid or making any chances to the browser itself that would negatively effect the experience of people accessing it on F-Droid or downloading the APK.

One thing I noticed when I first installed F-Droid was that it sort of tried to take over updates on several of my Google Play apps (One can disable this on an individual app basis in settings and Google Play picks it back up if desired), because they had the same apps. So, it would be far from unprecedented for an app to be listed in both places. Google Play won't bar us for meeting F-Droid's standards for eliminating proprietary telemetry or anything.

That's all I meant, really. We've got a browser that is aiming to meet the aspirational standards of F-Droid, but which also may have appeal to Google Play folks for different reasons. So, let's be both places and attract all the users who might be interested. I don't foresee Iceraven stopping offfering extra options or adding any telemetry, proprietary or otherwise, anytime soon. So, it could legitimately work for everyone.

The one group I see Iceraven being a tough sell for are folks who want a streamlined hardened speedy browser, simply because having a bunch of options, customization, and extensions cuts against that goal. Part of why we exist is because Firefox seems to have made a decision to chase the streamlined harden speedy crowd, offering options, customizations, and extensions only insofar as it doesn't cut against that goal. We went the other way, so people who's big issue is they want a dead-simple interface with superfast speeds and no choices to make may find a better fit elsewhere (Though they are certainly welcome to use the browser if they like it for other reasons). Even there, though, we are merging in rendering and other speed improvements from upstream Firefox, so it's not like we're going to fall too far behind and be ploddingly slow. Iceraven will likely continue to be close enough in that category for most users.

Similarly, though I mentioned that having a lot of extensions might in theory make us less hardened, people can decline to install extensions they find iffy, and cutting out a lot of proprietary code and telemetry, as Iceraven has done, actually does harden it in some other ways that most browsers (i.e. Firefox, Chrome) aren't willing to consider. So, that may wind up being a difference in type rather than a clear difference in which browser is more hardened against attack (And Tor will obviously continue to beat us all in that category, though people give up a lot for that type of security level).

I also love open-source. That's what makes this browser possible in the first place. WIthout it, we couldn't have forked from Firefox, we couldn't continue to incorporate some updates from Firefox, and we couldn't have incorporated the code we incorporated from F-Droid Fennec (Which is actually based on Fenix now, despite the name). With at least four different Fenix-based browsers out there (Iceraven, Firefox, F-Droid Fennec, and Tor), and all of them seemingly understaffed, including the Mozilla mothership (Rumored to only have six or fewer full-time employees devoted to Fenix), everyone is probably going to wind up drawing code from everyone else where it fits in with what their particular browser is trying to do, and though the open-source licensing allows all the browsers to do that without permission anyway, open cooperation may get us further in pooling limited resources.

If Mozilla ever goes under as a cooperation or ceases Fenix development, we're probably going to be in rough shape as to the future of Iceraven, though I would hope that perhaps the three Fenix projects that remain and any group that might inherit the Firefox brand could pool resources even further and try to keep the ships afloat with perhaps some outside help from a foundation or something, and I know that.

So, though I am a bit salty about some of the things Mozilla has done lately both in general (The initial state of Fenix at launch, their general push toward Chrome-itization and monetization product wise and away from most of the things Iceraven stands for, megabar on desktop, inappropriate hostile behavior in public towards the public from developers without apology or career consequence, etc.) and to me personally (Banned for life from their Github on a pretext without warning or ability to appeal, a lot of deleted posts on the Firefox sub-reddit, etc..), I am not anti-Mozilla either in an absolute sense. I am very concerned that Blink/Chromium is going to be an absolute monopoly pretty soon and Mozilla is the main driver of Gecko, the non-Blink option, so they have my support in an abstract sense.

It may be that pretty soon only Firefox and it's forks can offer the level of ad-blocking technology to which we've been accustomed. Once Chrome for desktop goes to Manifest v3 as it's only supported format for extension and stops supporting Manifest v2, they will lose extensions like UBlock Origin, and whether their forks can keep them depends on what sort of resources the forks can or are willing to bring to bare to do it. Firefox and its forks may be all that stands between us and the abyss on that one eventually.

I actually behind the scenes have tried to check in with some of the fired former Mozilla people to see if they'd be interested in trying to get involved in Iceraven (Though only a couple of them. Anyone with some time on their hands who wants to politely invite them to help out in any capacity they are able to and would be helpful with should feel free- they laid off of a lot more people than I happened to contact. Just don't pester them.). So far, no takers, but I'd certainly have no objection to experienced people who can take some of the burden off our regular developers while they are looking for their next paying gig doing so.

So, you know, peace and love to all and all that. :)

Finally, I should mention that though I use the word "we" a lot, it's just because I've been around Iceraven from the beginning (Back when it was Iceweasel fork-1. :) ) and have been talking it up various places, participating here, and trying to connect our developers with people and information that could be useful when possible (Linked to a couple of patches submitted for other projects that would work with Iceraven and later got incorporated in various forms, helped write part of the "readme", recruited potential developers and users, that sort of thing). I am not one of the formal maintainers of the project (In fact, I don't know how to code), nor do I own any of the trademarks or have any formal role in decision making (Though we are lucky to have folks who do listen to the community and take it into account when they make decisions). I'm just an involved user using "we" the way I talk about my favorite sports teams. :) So, if I say or do anything offensive, folks should understand that it isn't a reflection on our actual maintainers who do the coding, or the project as a whole. I'm only speaking for myself.

The good stuff is them, the bad stuff is me. ;)

Anyway, sorry about the digression.

I'll try to cool it on this issue for a while and let the developers get back to work without the crosstalk. :)

[hbarsaiyan]

Could really use a tl;dr here lol

[TheOPtimal]

There is some sort of Firefox installation manager in F-Droid. Maybe we could open an issue there and ask them to add Iceraven.

[dimqua]

To my understanding, the main issue here isn't getting updates, but getting a reproduceable fully-FLOSS build of this browser from the main F-Droid repository.

[Dev-i-l]

any update on this?

[interfect]

Not really. Since we're tracking the dependencies of Mozilla Firefox much more closely now, this should be much easier, and I might have revised my storage setup in a way that will make the buildbox VM happier, but I had a lot of trouble with it and it takes a long time every try.

January 12, 2021 6:46 PM, "Dev-i-l" <[email protected] (mailto:[email protected]?to=[e-mail])> wrote:
any update on this?

—

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (https://github.com/fork-maintainers/iceraven-browser/issues/26#issuecomment-759167633), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AAFXTNT3RDST5XFEJLW47ALSZUCQNANCNFSM4QNWLT2Q).