DELETED (replaced by #191): Make this block usable on Raspberry Pi Zero 2 W

[tim-littlefair]

There are two impediments which prevent this block from running usefully on on RPi-Zero2W:

• The wrapper script /usr/bin/chromium will always present a modal dialog warning that the 0.5 GByte memory of this board is less than the 1G recommended minimum for Chromium to run. If the device has an attached mouse or pointer device this can be dismissed by the user (it needs to be dismissed twice because the wrapper is run to capture the Chromium version number before it is run as a full browser). This is ugly enough, but if the device is being run in a display-only application where the user does not have a mouse/pointer there is no way of dismissing the dialog and the intended content will never be displayed.
• The source file public-html/index.html which gets installed into /home/chromium includes <script> elements which load the Bootstrap and JQuery Javascript libraries, and with these loaded the limited memory is presumably exhausted and no content is displayed (leaving the screen white).

The two commits in this PR address these impediments by:

• modifying the start.sh and startx.sh scripts to ensure that, on this hardware only, additional argument --no-memcheck is included both times /usr/bin/chromium is run.
• adding an additional script running during the docker build which, on this hardware only, patches /home/chromium/index.html to comment out the <script> elements which load the large Javascript libraries.

Although this patch was built against the current master branch of browser, based on the obsolete balenalib base image, they were originally developed against a branch updated to reflect the changes in pull request #185 which, when merged, will update this to use generic docker images. I believe that these changes are orthogonal to the changes required for #185, and it is unlikely to matter which of the two is merged first.

Of course whether the maintainers choose to accept this patch will also depend on whether they consider operability on this low resource device to be worth supporting. Experiments I have done here suggest that the device can cope with moderately complex static HTML5/CSS (e.g. copying pages generated from RST using sphinx styling), and can also handle very simple Javascript operations on the DOM of the page, but not heavyweight Javascript libraries).

[flowzone-app]

A repository maintainer needs to approve these workflow run(s).

To approve, maintainers can either:

• Submit an approval review on this pull request, OR

• Submit a review comment starting with /deploy

Then re-run the failed job(s) via the Checks tab above.

Reviews must be on the specific commit SHA of the workflow run to be considered.

[tim-littlefair]

I've converted this pull request back to a draft because since raising it I've come to a better understanding of the way Balena's 'Block' concept works, and realized that the changes I made in commit 3a2e544 won't have the result I was intending.

My intent was that this commit would monkey-patch the public-html/index.html file to comment out JQuery and Javascript library loads only when the block is operating on an RPi02w and leave it unchanged when running on all other hardware. But I now realize that the monkey-patching is done at BalenaHub during the creation of a single common container image which will be served as-is regardless of the target hardware - so whether the monkey-patching takes effect or not depends on the reported hardware variant of the BalenaHub build container, not the runtime unit running the block.

I suspect that this will mean that behaviour will depend on the default device type chosen for the block - on blocks which target RPi02w the Javascript will be removed for all runtime hosts, while those which target other aarch64 types will leave it in place for all hosts including RPi02w. I haven't tested this suspicion yet.

I note that PR #185 has been merged - I'm working on something else at the moment, but will come back when that resolves. When I do I will update this branch to retest after merging the changes from #185, and propose one or other of the following alternative changes:

• Instead of monkey-patching public-html/index.html I could change it directly in the repo to remove all
  4 <script> elements. As far as I can see on my own installs the behaviour of the page would not change.
• Generating an alternate file public-html/index-lowmem.html with the <script> elements removed during container
  build and putting in place changes to default to this instead of the original URL on RPi02w. The generation of this
  file might also add a visible disclaimer about the limitations on the web content which can be handled by the
  block on low memory hardware (AFAIK the RPi02w would be the only RPi-based aarch64 hardware available at
  present which would need this).

If anyone from the maintenance team is looking at this PR while it is in draft state I'd welcome advice on which of the options above would be preferred, if either. Of course suggestions of other options or rejection of the PR on
the grounds that there is no appetite to support RPi02w would be equally valid.

[tim-littlefair]

I've raised #191 as a more minimal replacement for this.

Unfortuntabely #191 appears to have brought in more commits than I intended (although the file diff looks right).

Closing this one as it is superseded.