administrators

Aha, I see. There was an apparmor package in xenial_-_edge that could be removed. The new version should filter in to the image with its next build.

Hey all, just wanted to give you a heads up that UBports Installer 0.5.6-beta is now in prerelease stage and it includes some stuff i know some of you have been waiting for. If your port needs to flash files that we can't re-host or download automatically, you can use the new manual_download step to have the user download something for the installer to work with afterwards. If your fastboot flash needs some of the new-fangled cli flags like --disable-verity or --disable-verification, the new flags array on the files object has got you covered. Use caution with these, don't be lazy

You can find more information on the release page. Also see the call for testing.

Let me know if we need anything else to make your port work with the installer, or if you have any other thoughts how i could make your lives as porters more enjoyable.

Cheers, and happy hacking!

Y'all know the drill, UBports Installer 0.5.6-beta needs your love! A snap package can be installed by running snap install ubports-installer --beta on any Linux distribution. Other packages are available on the release page.

You can help us test this release on UBports OPEN-CUTS.

Release notes

This release adds support for additional configuration options when flashing fastboot images, such as --disable-verity (#1459). MacOS users can now quit the UBports Installer by pressing Cmd+Q (#1047). A bug has been fixed that prevented the installer from reading absolute paths to config files (#1320) using the -f option. A new step manual_download has been added, to support downloading files with licensing restrictions that make it impossible to re-host them on our own servers for automatic downloading (#1456).

Experimental automatic reporting

Experimental automatic reporting has been added recently. Please check the instructions here to learn more.

Changelog

7 changed files, 150 additions, 51 deletions

• @NeoTheThird Quit on macos, fixes #1047 86a4d8e
• @NeoTheThird Implement additional fastboot flags, resolves #1459 71d46f7
• @NeoTheThird Support both absolute and relative paths, fix #1320 11575a6
• @NeoTheThird Add manual_download step, resolves #1456 055706d

Notes for Developers

manual_download step

The manual_download configuration step has the following structure:

        {
          "type": "manual_download",
          "condition": {"var": "bootstrap", "value": true},
          "group": "firmware",
          "file": {
            "name": "package.json",
            "url": "https://github.com/ubports/installer-configs/blob/master/package.json",
            "checksum": {
              "sum": "907f030a2e37c99dc8b0cfbf42f95213ef95b2e6714900ec002b213fad4672a6",
              "algorithm": "sha256"
            }
          }
        }

fastboot flash flags

Additional flags for fastboot flash can be set in the fastboot:flash action for every file individually. The raw option tells the installer to use the fastboot flash:raw command rather than fastboot flash. The flags option takes in an array with additional flags. Use caution when selecting these flags. Make sure you actually need them; don't just add everything. If you're using flags, do so because it's the only option to make it work.

        {
          "type": "fastboot:flash",
          "condition": {"var": "bootstrap", "value": true},
          "flash": [
            {
              "partition": "boot",
              "file": "halium-unlocked-recovery_dora.img",
              "group": "firmware",
              "raw": true
            },
            {
              "partition": "recovery",
              "file": "halium-unlocked-recovery_dora.img",
              "group": "firmware",
              "flags": ["--disable-verity", "--disable-verification", "--force"]
            }
          ]
        }

@evilbunny

It should be on the devel and rc channels already. If it isn't let me know, I've got some investigating to do then.

This is a bit of a late reply, but I believe we've fixed this issue with https://github.com/ubports/apparmor-easyprof-ubuntu/pull/17. It will be part of OTA-14.

@DjDeets Can you please send a log file from the installer when it hangs? It should be in %APPDATA% directory somewhere...

Hi, do you have a language code for it? I did not find it on our translation server... Is this a language supported by Unicode?

BR Florian

It's blender, and its not on the iPhone!

Hi everyone,

It's been about two years since we added QtWebEngine to Ubuntu Touch, beginning the arduous process of replacing Canonical's Oxide rendering engine.

At the time, all of the webapps and HTML5 apps on the store relied on Oxide's unique quirks. Some expected the behavior from Ubuntu.Web, others explicitly imported Oxide libraries.

Since then, things have changed. We've become increasingly present on 64-bit ARM devices where Oxide simply isn't available. Many of our users coming to the platform now can't take advantage of these apps.

Many app developers have released their apps to take advantage of Morph.Web or direct QtWebEngine imports. However, I believe there are still some holdouts on the store... Either by lack of maintainership or by choice. The Ogra webapp container in particular only uses the Oxide rendering engine. Any apps made with it simply don't work on the PinePhone, Volla Phone, Xperia X, Nexus 6P, or many other new ports...

With this in mind, I propose that we make OTA-15 of Ubuntu Touch the final release which includes the Oxide rendering engine. In other words, OTA-16 should not include Oxide. That gives a roughly three-month period to transition any remaining apps to the new rendering engine (on top of the two years already provided).

Removing the Oxide rendering engine takes a pretty large, not-updated piece of code out of the image. That means smaller updates for everyone, more space in the rootfs to provide newer features, and a more secure device overall.

Is this timeline with OTA-16 the first non-Oxide update feasible? What else do we need to consider before its removal that we can prioritize for OTA-14 and OTA-15?