Enable AV1 Decoder about bromite-builder

[csagan5]

Regarding the original issue itself (AV1 support): I will answer myself: from what I have tested this feature does not work and/or is not supported on Android, you can use https://demo.bitmovin.com/public/firefox/av1/ to test other (Android) browsers like Chrome or Brave; I only tested Chrome.

I will remove the flag from Bromite's GN_FLAGS.

[csagan5]

I'm content with us continuing wider off-topic conversations here (unless you have a different place you'd prefer)

The alternative would be a mailing list or forums, IM/chat would not be pleasant and valuable for records keeping. I have not made my mind about setting up forums (mailing lists are not that nice) and Github issues are generally nicer than forums and more dev-oriented.

If you were to consider changing the scope of the patch to only code changes, there might possibly be two other options to explore:

• Explore if there's a way to incorporate Gradle's shrinkResources https://developer.android.com/studio/build/shrink-code#shrink-resources or an approriate equivalent to Chromium builds (I'm not holding my breathe on this being a possibility)
  That's a bad idea IMO. We want to differ as little as possible from upstream Chromium; this change would possibly increase the amount of work in patch maintenance.

• Leave the pngs and hope lint rules aren't setup for unused drawable resources. The pngs total combined weight is 3.023kb when uncompressed, so leaving them won't be detrimental to APK size

There are lint rules that will make an error if you leave unused PNGs in the build; look at the https://gitlab.com/thermatk/Unobtainium patches to see how @thermatk silences the warnings there.

I did not adopt this change (and I am against it) because I do not want to add patches to the lint ignore list (or disable the unused resources warning altogether) for a problem we have at applying patches.

I do think it's important to resolve this issue at some point in the future -- reproducible builds that can be automated are a must (even if scarificing 3.023kb is the only option)

I also would like reproducible builds, but it has nothing to do with the disk space: the patches should be the minimum viable patches IMO and if upstream does not want unused resources I simply follow upsteam on this. Deviation will likely cause more work elsewhere (in either patch maintenance or troubleshooting); put it the other way round: if it were useless, upstream would have disabled the linting already (and it is not about disk space: having only the resources needed help in other ways, not least confusion when using the resources themselves).

Back on the topic of reproducible builds: the F-Droid attempt is the closest. Once all non-free binaries are removed the remaining (upstream) reproducible-build killers can be addressed.
I guess the only decent compromise to make the patches apply automatically is either a custom git am or to modify the lint ignore list; I opt for the former.

What you say is definitely possible but I am still not convinced that the issues you found with the safe browsing patches are not solved by using current master patches & list; I will have to verify that a build from scratch reproduces these problems but I suggest you try with latest patches first.

On the last three Bromite releases I attempted to build, I could not get past building safe_browsing with the existing patchset. The builds are always ran from a clean source tree (I added exclude=out after the first successful build). The first fatal error that gets thrown is:

`chrome/browser/download/download_item_model.cc`:
`fatal error: "chrome/common/safe_browsing/download_file_types.pb.h" file not found`

Maybe it doesn't need download_file_types.pb.h to be in the file system if it's been previously compiled and available in your out directory? I was close to just changing the GN_ARGS to safe_browsing_mode=2 so it would just generate it (See: https://github.com/chromium/chromium/blob/master/chrome/browser/BUILD.gn#L5121 and https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/resources/safe_browsing/README.md)

I confirm the problem you have seen; sorry for doubting it but I remember recent builds of ~30k ninja targets without issues. Even in those cases, obviously not everything was being invalidated/rebuilt. This is also a bug of Chromium gn flags (but I will not report it upstream, unlikely to be fixed).

Please go ahead with the updated patches PR.

It seems to be that the theme (in that commit) is referencing that bottom navbar color, thus might look wrong somewhere else if becoming black.
Is the black navbar OK for users using a white color combination (I guess that would be the first of your screenshots)? What concerns me is that we have not found one (or more) recent upstream Chromium commits that are responsible for the change that has been seen and that we are trying to revert. Perhaps there is none because it was changed in a more subtle way?

The commit you linked was the first commit related to it, since then they added an additional commit that contained a second style value with a name of android:navigationBarDividerColor (the gray-ish top border). The third and last commit to values-v27/styles.xml added comments that link to an internal (private) bug tracker. The history can be viewed here (sorry the Github's mirror history view isn't rendering at the imo) https://chromium.googlesource.com/chromium/src.git/+log/master/chrome/android/java/res/values-v27/styles.xml

The nav bar default color scheme for as long as I can remember has always been with a black background. The color change to white was introduced in the new "Material Design Refresh", and has always targeted SDK 27+.

Here's a random old forum thread where Oreo users say they have the white nav bar, and Nougat users are saying it's still the traditional black nav bar: https://hardforum.com/threads/chrome-64-for-android-white-navigation-bar.1953206/

Additionally found this old screenshot of a site reviewing v63 (https://theleaker.com/google-chrome-v63-update-on-android-comes-with-new-ui/), and you can see it's black as well:

Let me know if it's something you have interest in including and I'll open a PR and we can sort of the remaining bits in that issue

Yes, please, go ahead with the PR for this as well.

My only concern (as in previous comment) is that we didn't find one or more specific upstream commits to revert, so I suspect other bits might have been left out. If this is the case I would expect some user to complain about this (while if we do our homework we prevent the rollout of a partial fix).

But let's ignore this concern for now, I checked the commit history you sent me and I seem to grasp what you mean regarding the change being already specific to v27+.

[nikolowry]

Let me give you a goal post: finish/replace the work done for Unobtainium (building a FOSS Chromium). Make that Android browser app (whatever you wish to call it, if it's not a continuation of Unobtainium) building and available via F-Droid (that means going through the vet process etc).
You can be sure I will follow the progress; afterwards tell me that it is finished, and we can talk again about all of this.

Sounds good @csagan5! This is really what I was trying to get at all along, sorry for the long-winded discussion

[csagan5]

@nikolowry on the topic of AV1: I have managed to reconstruct a patch to make it work, you will see it released on next release (v72).

Basically upstream Chromium only allows AV1 on desktop (unknown reasons), but it works just fine on Android. I was deceived by the javascript function canPlayType which would make most HTML5 AV1 tests fail.

So on next release AV1 will be reported as playable with canPlayType and work just fine, as you can test with Bromite here: https://tools.woolyss.com/html5-audio-video-tester/?u=https://www.elecard.com/storage/video/Stream1_AV1_720p_1.5mbps.webm

Edit: information is now on the wiki: https://github.com/bromite/bromite/wiki/AV1-support

[csagan5]

@nikolowry you can safely build with the AV1 decoder disabled, I could not make it work on Android anyways. Also, this is a Chromium issue so if you ask on their tracker/mailing list they should be able to solve it?

[nikolowry]

@csagan5 I assumed you had it working per https://github.com/bromite/bromite/blob/master/build/GN_ARGS#L6. Shouldn't that be removed from Bromite's source?

[csagan5]

@nikolowry the full story is a bit more long. I had it working at some point, but then I could still not pass AV1 decoding tests online so I concluded something else was missing. From what I could read upstream it is supposed to work (see also: https://caniuse.com/#feat=av1).

I can either remove the flag from GN_ARGS or try to dig out the patch I was using to make it build. Can you confirm/deny whether AV1 decoding works on Chrome on Android?

Regardless upstream should make Chromium work when that GN flag is being used but I would not want to hunt the bugfix upstream.

Also, on a side note (off-topic):

• I had disabled jumbo building because of some weird issue, maybe I will enable it again
• reducing those symbols does not make anything faster from what I measured (and makes any crash troubleshooting impossible)
• the issues you are having with the patches not applying are due to some cleanup/reordering I did to allow using some patches stand-alone; with last commit you should have less issues (only the issues with the binary files deleted, but that is a problem of git am itself)
• I saw you are trying a dark nav patch, however I am not sure it would look good on pre-SDK27 systems as well? I have pinpointed as one possible source of the white nav bar this upstream commit: chromium/chromium@bd6f02339cb7c it might be useful for you (also to not break what was being done in that commit regarding the MainTheme)

[nikolowry]

I have yet to investigate AV1 decoder support in arm and x86 builds. If you can confirm support for those arch types @csagan5, I'll just add a conditional to remove this arg on arm64.

---

Edit: please ignore! Will address your points shortly

[nikolowry]

Was previously out-and-about @csagan5 and wanted to address your points once I was back on my machine.

• I had disabled jumbo building because of some weird issue, maybe I will enable it again
  reducing those symbols does not make anything faster from what I measured (and makes any crash troubleshooting impossible)
• reducing those symbols does not make anything faster from what I measured (and makes any crash troubleshooting impossible)

Reducing just the symbols changed my compilation steps from 34,234 to ~24,000. After adding jumbo build support it was reduced from ~24,000 to ~17,000 (I exclude out from cleaning, so these estimates might be off).

the issues you are having with the patches not applying are due to some cleanup/reordering I did to allow using some patches stand-alone; with last commit you should have less issues (only the issues with the binary files deleted, but that is a problem of git am itself)

I'm trying to avoid git am for removing the settings_translate.png's, don't want to dirty the tree with commits -- will revisit that in the future with maybe trying to reset instead of clean during fetch-sync.

At a glance the changes to chrome_network_delegate.cc in Bromite-adblock-engine.patch should do it. I ended up referencing the old patch order and checked in a temp patchlists.txt until they were resolved on your side (was going to make a PR but you beat me!).

I am however going to make a PR by day's end for https://github.com/bromite/bromite/blob/master/build/patches/ungoogled-chromium-disable-safe-browsing.patch.

I suspect that your builds aren't done "clean" everytime (fetch and gclient sync are the worst), and that due to the previous use of safe_browsing_mode=2, chrome/common/safe_browsing/download_file_types.pb.h is available in your file system and that's why you don't get additional errors after changing to safe_browing_mode=0. Your patch consists of 1076 lines of changes, while the one I ended up having to use is 1495. The main changes are in lines 245 to 797 in https://github.com/nikolowry/bromite-builder/blob/master/patches/ungoogled-chromium-disable-safe-browsing.patch#L245.

The following files needed additional changes or for patches to be created:

• chrome/browser/component_updater/file_type_policies_component_installer.cc
• chrome/browser/download/chrome_download_manager_delegate.cc
• chrome/browser/download/download_item_model.cc
• chrome/browser/download/download_item_model.h
• chrome/browser/download/download_prefs.cc
• chrome/browser/download/download_target_determiner.cc
• chrome/browser/download/download_target_determiner.h
• chrome/browser/download/download_target_info.cc
• chrome/browser/download/download_target_info.h
• chrome/browser/download/download_ui_model.cc
• chrome/browser/download/download_ui_model.h

Sidebar: This type of scenario is why I was disappointed that build issues were ignored/unsupported. Chromium is complicated to build, and without being able to inspect each other's build files we'll most likely always end up in cases of "Works on my machine".

I saw you are trying a dark nav patch, however I am not sure it would look good on pre-SDK27 systems as well? I have pinpointed as one possible source of the white nav bar this upstream commit: chromium/chromium@bd6f023 it might be useful for you (also to not break what was being done in that commit regarding the MainTheme)

Doesn't pre-SDK27 systems ignore values in values-v27? Those systems should have never had the White Navigation bar to begin with (and thus this patch would be irrelevant to those users). Atleast that's how I understand https://developer.android.com/guide/topics/ui/look-and-feel/themes#Versions.

And the commit referenced seems to be for 65.0.3286.0, my patch targets tip of the tree https://github.com/chromium/chromium/blob/master/chrome/android/java/res/values-v27/styles.xml

If it wasn't for the Java linting during builds which enforces no unused res values, I would have never touched chrome/android/java/res/values/colors.xml and instead would have just changed chrome/android/java/res/values-v27/styles.xml to use @android:color/black.

Here's some screenshots of 71.0.3578.115 with the Dark-Navbar.patch:

Link to the build (chrome_modern_public_apk arm64) I'm running on my personal device: https://neeks.me/cloud/index.php/s/kn7Djx7AstbWfKJ

[csagan5]

I'm trying to avoid git am for removing the settings_translate.png's, don't want to dirty the tree with commits -- will revisit that in the future with maybe trying to reset instead of clean during fetch-sync.

Both git apply and git am don't support these patches, it seems to be a limitation of git. No matter how I format them, they do not manage to cleanly remove binary files. I apply them semi-automatically (with a modified git am).

At a glance the changes to chrome_network_delegate.cc in Bromite-adblock-engine.patch should do it. I ended up referencing the old patch order and checked in a temp patchlists.txt until they were resolved on your side (was going to make a PR but you beat me!).

Yes, those are the correct patches second the new order; alternatively you could have used the old patches in the old order. I was waiting for next release to publish the "fix", but they are tested to build.

I am however going to make a PR by day's end for https://github.com/bromite/bromite/blob/master/build/patches/ungoogled-chromium-disable-safe-browsing.patch.

I suspect that your builds aren't done "clean" everytime (fetch and gclient sync are the worst), and that due to the previous use of safe_browsing_mode=2, chrome/common/safe_browsing/download_file_types.pb.h is available in your file system and that's why you don't get additional errors after changing to safe_browsing_mode=0. Your patch consists of 1076 lines of changes, while the one I ended up having to use is 1495. The main changes are in lines 245 to 797 in https://github.com/nikolowry/bromite-builder/blob/master/patches/ungoogled-chromium-disable-safe-browsing.patch#L245.

The following files needed additional changes or for patches to be created:

• chrome/browser/component_updater/file_type_policies_component_installer.cc
• chrome/browser/download/chrome_download_manager_delegate.cc
• chrome/browser/download/download_item_model.cc
• chrome/browser/download/download_item_model.h
• chrome/browser/download/download_prefs.cc
• chrome/browser/download/download_target_determiner.cc
• chrome/browser/download/download_target_determiner.h
• chrome/browser/download/download_target_info.cc
• chrome/browser/download/download_target_info.h
• chrome/browser/download/download_ui_model.cc
• chrome/browser/download/download_ui_model.h

Yes, I avoid starting from scratch at all costs; I have deleted that generated file download_file_types.pb.h but it still builds (incrementally) fine with safe browsing disabled.
The patch you mentioned is an upstream one and I usually append my changes to the subsequent one (which I maintain). If you were to make changes to that patch, it should technically be upstreamed for consistency as I'd rather append them to the Bromite-specific one.

What you say is definitely possible but I am still not convinced that the issues you found with the safe browsing patches are not solved by using current master patches & list; I will have to verify that a build from scratch reproduces these problems but I suggest you try with latest patches first.

Sidebar: This type of scenario is why I was disappointed that build issues were ignored/unsupported. Chromium is complicated to build, and without being able to inspect each other's build files we'll most likely always end up in cases of "Works on my machine".

Sorry, I don't have the interest/manpower to support this at scale. The case you are focused now on is one of tens I have seen and there is really no automation that can help with it. Upstream does not build with all combinations of flags and sometimes intentionally breaks support of some of them (WebRTC etc) for their own needs.

Doesn't pre-SDK27 systems ignore values in values-v27? Those systems should have never had the White Navigation bar to begin with (and thus this patch would be irrelevant to those users). Atleast that's how I understand https://developer.android.com/guide/topics/ui/look-and-feel/themes#Versions.

And the commit referenced seems to be for 65.0.3286.0, my patch targets tip of the tree https://github.com/chromium/chromium/blob/master/chrome/android/java/res/values-v27/styles.xml

If it wasn't for the Java linting during builds which enforces no unused res values, I would have never touched chrome/android/java/res/values/colors.xml and instead would have just changed chrome/android/java/res/values-v27/styles.xml to use @android:color/black.

Here's some screenshots of 71.0.3578.115 with the Dark-Navbar.patch:

It seems to be that the theme (in that commit) is referencing that bottom navbar color, thus might look wrong somewhere else if becoming black.

Is the black navbar OK for users using a white color combination (I guess that would be the first of your screenshots)? What concerns me is that we have not found one (or more) recent upstream Chromium commits that are responsible for the change that has been seen and that we are trying to revert. Perhaps there is none because it was changed in a more subtle way?

[nikolowry]

I'll close this shortly! Since this repo doesn't have any traffic, I'm content with us continuing wider off-topic conversations here (unless you have a different place you'd prefer)

---

Both git apply and git am don't support these patches, it seems to be a limitation of git. No matter how I format them, they do not manage to cleanly remove binary files. I apply them semi-automatically (with a modified git am).

If you were to consider changing the scope of the patch to only code changes, there might possibly be two other options to explore:

• Explore if there's a way to incorporate Gradle's shrinkResources https://developer.android.com/studio/build/shrink-code#shrink-resources or an approriate equivalent to Chromium builds (I'm not holding my breathe on this being a possibility)
• Leave the pngs and hope lint rules aren't setup for unused drawable resources. The pngs total combined weight is 3.023kb when uncompressed, so leaving them won't be detrimental to APK size

I do think it's important to resolve this issue at some point in the future -- reproducible builds that can be automated are a must (even if scarificing 3.023kb is the only option)

What you say is definitely possible but I am still not convinced that the issues you found with the safe browsing patches are not solved by using current master patches & list; I will have to verify that a build from scratch reproduces these problems but I suggest you try with latest patches first.

On the last three Bromite releases I attempted to build, I could not get past building safe_browsing with the existing patchset. The builds are always ran from a clean source tree (I added exclude=out after the first successful build). The first fatal error that gets thrown is:

`chrome/browser/download/download_item_model.cc`:
`fatal error: "chrome/common/safe_browsing/download_file_types.pb.h" file not found`

Maybe it doesn't need download_file_types.pb.h to be in the file system if it's been previously compiled and available in your out directory? I was close to just changing the GN_ARGS to safe_browsing_mode=2 so it would just generate it (See: https://github.com/chromium/chromium/blob/master/chrome/browser/BUILD.gn#L5121 and https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/resources/safe_browsing/README.md)

It seems to be that the theme (in that commit) is referencing that bottom navbar color, thus might look wrong somewhere else if becoming black.

Is the black navbar OK for users using a white color combination (I guess that would be the first of your screenshots)? What concerns me is that we have not found one (or more) recent upstream Chromium commits that are responsible for the change that has been seen and that we are trying to revert. Perhaps there is none because it was changed in a more subtle way?

The commit you linked was the first commit related to it, since then they added an additional commit that contained a second style value with a name of android:navigationBarDividerColor (the gray-ish top border). The third and last commit to values-v27/styles.xml added comments that link to an internal (private) bug tracker. The history can be viewed here (sorry the Github's mirror history view isn't rendering at the imo) https://chromium.googlesource.com/chromium/src.git/+log/master/chrome/android/java/res/values-v27/styles.xml

The nav bar default color scheme for as long as I can remember has always been with a black background. The color change to white was introduced in the new "Material Design Refresh", and has always targeted SDK 27+.

Here's a random old forum thread where Oreo users say they have the white nav bar, and Nougat users are saying it's still the traditional black nav bar: https://hardforum.com/threads/chrome-64-for-android-white-navigation-bar.1953206/

Additionally found this old screenshot of a site reviewing v63 (https://theleaker.com/google-chrome-v63-update-on-android-comes-with-new-ui/), and you can see it's black as well:

Let me know if it's something you have interest in including and I'll open a PR and we can sort of the remaining bits in that issue

[nikolowry]

@csagan5 whenever I have a little downtime this week, I'll update the patches and use git-format-patch this time around.

Per the Dark-Navbar.patch,
I started looking into available experimental flags and I suspect users who've enabled chrome://flags/#enable-chrome-duet (requires two restarts) or possibly even chrome://flags/#upcoming-ui-features might be opposed to reverting to the black nav bar. Screenshots attached at the end of this comment for reference.

Before I saw this response I was heavily considering adding a --dark-nav-bar flag so I could build my own "personal variant" while still supporting only Bromite patches.

This might be looking too far ahead, but I'd like to suggest we work out all the final kinks in this repo and then transfer it to the Bromite organization. I'd be more than willing to maintain it, especially knowing you have no interest in doing so.

Following that, a build bot could use it to handle building and uploading the latest releases -- one default ui and one dark nav bar ui of each variant. A few adjustments to version would allow supporting building from master.

Screenshots from bromite-builder w UI flags enabled:

Screenshots from Bromite w UI flags enabled

[csagan5]

Per the Dark-Navbar.patch,
I started looking into available experimental flags and I suspect users who've enabled chrome://flags/#enable-chrome-duet (requires two restarts) or possibly even chrome://flags/#upcoming-ui-features might be opposed to reverting to the black nav bar. Screenshots attached at the end of this comment for reference.

In this case it would be better to follow upstream for this change, also because it's unrelated to the goals of Bromite.
Scenario:

1. we release Bromite with the Dark navbar patch
2. an user submits a bug report saying that it breaks their UI
3. the patch has to be removed to be consistent with upstream

This ^ is what makes me hesitant.

Before I saw this response I was heavily considering adding a --dark-nav-bar flag so I could build my own "personal variant" while still supporting only Bromite patches.
[...]
Following that, a build bot could use it to handle building and uploading the latest releases -- one default ui and one dark nav bar ui of each variant. A few adjustments to version would allow supporting building from master.

Different APKs released for different UI flavours? Sorry, this does not sound like a good idea to me. You could have a chrome://flags but separate builds with a specific UI tweak changed is not something I would release. I have thought of this (different variant builds) in the past for bigger feature changes (not related to UI), but my reasoning always ends up that it's a bad idea and should be done via app settings or flags, since it would confuse the user base and create a myriad of other troubleshooting issues.

This might be looking too far ahead, but I'd like to suggest we work out all the final kinks in this repo and then transfer it to the Bromite organization. I'd be more than willing to maintain it, especially knowing you have no interest in doing so.

We have already briefly discussed this, but sorry I am not interested into this; if I were to pick again working on the build aspect, I would most likely work on the F-Droid upstream issue rather than this (because it would have the best value for community). Thanks for the offer though, it's appreciated.

On the other hand I fully endorse your desire to build it from scratch and apply any customization you like, and share the way you do it with others (although I do not believe there is or there should be "one" way to do this, as the build is so complex and customizable).

Edit: I have adopted some of your changes for the fix to the safebrowsing patches, but I am using a different approach (#if defined(FULL_SAFE_BROWSING) instead of deletion).

You can find the updated safe browsing patch later on master, that should build cleanly now.

[nikolowry]

No worries @csagan5, adding to chrome://flags would be a little too much to tackle when there's more pressing build related issues to tackle. Will go with the optional CLI command for now.

We have already briefly discussed this, but sorry I am not interested into this; if I were to pick again working on the build aspect, I would most likely work on the F-Droid upstream issue rather than this (because it would have the best value for community). Thanks for the offer though, it's appreciated.

Well I was trying to imply that this utility's real purpose would be for "reproducible" (read: F-Droid) builds, and it being available as a standalone utility would just be an extra -- two birds, one stone. I'm going to add a CLI option for adding additional GN args during builds shortly (that would take care of the signing args without having to check anything related to it in Bromite's GN_ARGS)

Hypothetically, if this transfer happened today I'd remove all the checked-in bromite-builder patches, not add any dark-navbar CLI options and instead add a new CLI option like --patches-dir or --custom-patches. The main benefits being:

• New contributors could have an easy way to experiment with patches before PR's
• Seasoned Chromium builders will have an easy way to roll their own opinionated versions
• Limits the scope of this repo to being dedicated to only building Bromite (one thing well)

Do agree the UI variant suggestion would be a little too much! Just throwing out ideas

[nikolowry]

Oh and I'll test the Safe Browsing updates today!

[csagan5]

I was just reading this article about the new UI: https://www.zdnet.com/article/google-chromes-new-ui-is-ugly-and-people-are-very-angry/

Regarding the build process: the one that F-Droid requires is a tad (I think a lot) more complicated than the one you are using and the one I use as well. It requires a VM etc. you will see if you ever try.

If you want to build custom Bromite builds it's sufficient what you are already doing and it can serve as a template for others that are starting from scratch. I still do not understand though how your builder differs from a generic Chromium builder + apply some patches (and arguably you should be able to find many of these projects already), this is why I am not interested in supporting an "official" builder.

[nikolowry]

@csagan5 getting this utility to be F-Droid acceptable is more than feasible (CI/CD, DevOps in general are my favorite). Just need to iterate through the last hurdles.

The only real difference from a generic Chromium builder at the moment is that this is dependent on Bromite releases. If the branding icons and manifests were available, I would have been building with those as well.

I see immense potential in this if it became bromite/bromite-builder and handled the "official" releases/builds. It would satisify a lot of the complaints I've seen about Bromite:

• Transparency, reproducibility and testability of Bromite patches/builds (A FOSS must)
• Lessen the barrier for contributing patches, after the initial fetch it provides a quick way to test a new patch applies cleanly

If this were to happen I would have no problem with providing complete support and maintenance -- you would not be bothered and you could redirect all relevant build issues to it instead. All opinionated things would be dropped (Dark-Navbar.patch), but functionality would be added for any user to include their own "custom patches" for building

[nikolowry]

One last note, in a few days time this utility has already added value to the Bromite project:

• We were able to resolve the outstanding git binary diff issues
• We discovered that the existing safe browsing patch was lacking and needed code changes

Hypothetically, If I were to start sem versioning this today I'd start at it at v0.1.0 and wouldn't suggest it to become "official" until v1.0.0 (I should do this regardless, and also add a roadmap).

I'm confident that in the few weeks it will take to get to that level of "feature completeness", examples of the additional value provided by making this "official" will be discovered as well.

[csagan5]

@nikolowry no need to sell this to me, as I have already said: make it happen for Chromium, then Bromite is automatically happening since it is a bunch of patches and nothing more.

The approach of Unobtainium was correct in this sense: first achieve Chromium FOSS builds, then you can customize those.

I am not aware of such complaints and I invite each of the complainers to solve the problem (for me and for them) for Chromium FOSS builds first, then I will setup a fork with Bromite's patches in no time :)
Also: you only get the feedback of complainers, while who achieves success or gives up will not necessarily tell you (does not have to). I have no interest in supporting the most vocal members of the community.

The go-to place for automated FOSS builds of Chromium would be F-Droid as well, but there are other public parties building Chromium for multiple OSes already (although not FOSS), one could look at those.

• We were able to resolve the outstanding git binary diff issues

We simply reverted my non-standard non-binary patches (that I was using because I was thinking to use this for larger patches, like the removal of binary blobs, that you will meet later on), which is good as now they are standard.

• Lessen the barrier for contributing patches, after the initial fetch it provides a quick way to test a new patch applies cleanly

You do not need me and do not need Bromite for this :) the hurdles come from building Chromium, not Bromite. Make building FOSS Chromium easy-peasy and then you can use any patches you like there.

This is the reason why I maintain a collection of patches: no interest in the building aspect, too much work, sorry, and similarly no interest in making it F-Droid/FOSS compliant.

When you continue down the path you laid out, you will discover that:

• removing all the binary blobs to make the software FOSS-compliant is a major task
• some features get broken and others simply start crashing, inexplicably
• maintaining large patches that remove all the binaries becomes very hard

I have decided to focus my efforts on maintaining the current patches and adding more of course as they seem fit. I am also (slowly) developing some privacy-focused features from scratch.

I see immense potential in this if it became bromite/bromite-builder and handled the "official" releases/builds.

Bromite is open source, nobody is stopping you from making it build anywhere you like; and if additionally you want to make it FOSS-compliant (no binary blobs embedded or used during the build), you are also welcome to do that and submit patches.

If the branding icons and manifests were available, I would have been building with those as well.

I am sorry, you started this discussion about the build system, now it has become about using a public build system for the official releases, making it FOSS compliant. These are all things already discussed for Unobtainium at Gitlab.

Let me give you a goal post: finish/replace the work done for Unobtainium (building a FOSS Chromium). Make that Android browser app (whatever you wish to call it, if it's not a continuation of Unobtainium) building and available via F-Droid (that means going through the vet process etc).
You can be sure I will follow the progress; afterwards tell me that it is finished, and we can talk again about all of this.

[nikolowry]

@csagan5 I'll be on the look out!