Posts made by NeoTheThird

NeoTheThird

Here we go again: Hopefully the last release in the series of major backend-refactoring efforts. This one implements a new specification for the installer's config files, which allowed us to re-design the engine that translates configs into runnable steps from the ground up and correct some mistakes of the past. We're now at 56% unit test coverage on the installer itself (with all of our internal libraries sitting at 100%), and we are now unblocked from getting the installer to 100 % as well. Before we can do that, however, we need to do a full pre-release user testing session with all devices. This will hopefully be the last time we have to do it this diligently, so let's make it count!

NeoTheThird

@poVoq Sure, i'm open to including any and all operating systems! I opened an issue about it a while back, happy to hear your input on weather pmbootstrap should be wrapped or re-implemented: https://github.com/ubports/ubports-installer/issues/1396

NeoTheThird

Another UBports Installer pre-release is ready for testing:

This one was all about re-factoring the installer's own source code. not many new features, but massive changes to improve stability and maintainability. Let's do thorough QA to make sure I did not mess anything up ^^

NeoTheThird

Sorry for the quick iterations, here's yet another one:

Due to time constraints, we had to squeeze another minor thing in.

NeoTheThird

@tigerpro this should help: https://forums.ubports.com/topic/5186/call-for-testing-ubports-installer-0-7-3-beta

NeoTheThird

This maintenance release improves some error handling and improves the process of re-connecting to devices if the cable is unreliable.

NeoTheThird

Alright, we found some issues that should hopefully be resolved in 0.7.2-beta. If anyone wants to test, you know what to do.

@tigerpro A fix for your heimdall issue has been prepared in the library and will be included in 0.7.3-beta, if everything goes according to plan. Sorry for the delay there.

NeoTheThird

@tigerpro Thanks for the log, that should be fixable. Will report back when i know more.

nor can i figure out how to bring up opencuts mid-install

either by clicking report a bug in the top right corner or by selecting it from the global menu

NeoTheThird

This one doesn't include as many exciting features, but lands a major refactoring effort of our core background library promise-android-tools. The library is responsible for adb, fastboot, and heimdall - the communication with the device. We touched almost every function in the library, so meticulous testing is needed. See the changelog for more information.

Please download a package of your choosing from the release page and take it for a spin on your favorite device. Use the built-in reporting feature to let us know how it went. You can find out what combinations are still missing on UBports OPEN-CUTS.

Thank you for your help!

NeoTheThird

@herbi can you clarify, did this issue surface after using the installer or after starting an over-the-air upgrade from the system settings? In any case, you should be able to restore your device by using the installer, as long as there is no hardware issue.

NeoTheThird

Might be. The snap package handles udev rules (required for device access) that might cause issues when adding new devices. Could you check if another installer package, AppImage for example, sees the device?

NeoTheThird

You're familiar with the process by now: UBports Installer 0.6.0-beta is in prerelease stage and needs your attention. The good news: The Installer now features a GUI for automatic reporting, to OPEN-CUTS, making automatic reporting even easier!

You can find all packages along with an extensive changelog on the release page.Take it for a spin with your favorite device and push that button to let us know how it went. Thank you for your help!

NeoTheThird

The installer can instruct the user to manually download binaries and handle the flashing for them starting in version 0.5.6-beta. Someone already made a PR here to flash the OEM binary for suzu, could someone who has a device for testing send me a PR to enable this for kagura as well? Thanks

NeoTheThird

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!

NeoTheThird

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"]
            }
          ]
        }

NeoTheThird

Thank you to everyone for participating in the previous call for testing. The user reports turned up one issue with the macOS packages that we fixed in 0.5.4-beta. The fix involved some changes to our CI/CD systems, so we'll require some quick tests of all images to make sure nothing broke before we can declare it stable.

As before, just download an image of your choosing from the releases page and set the env var to report the result automatically. You can see the current coverage in UBports OPEN-CUTS. Thanks!

NeoTheThird

Hey everyone, another Installer pre-release lined up for testing! We're using our new experimental user-testing platform OPEN-CUTS to test this release and keep track of everything that's going on.

what to test

To help us testing, just download any package from the releases page or get the snap by running snap install ubports-installer --beta. We need to test every package on every operating system, just use any Ubuntu Touch device supported by the Installer and and re-install it using the new installer version. Keep on reading to learn how to tell us the result, don't worry, it's easy!

automatic reporting

An important new features for testers is that the installer can now automatically report testing results to OPEN-CUTS. If the installer runs into an error, choose the "report a bug" option to make the Installer automatically report a FAIL run to UBports OPEN-CUTS and include a link to the run in the generated bug report on GitHub. If you have a problem that does not result in an error and you still choose to report a bug, the installer will automatically create a WONKY run and attach it to the report. This already lets us know what doesn't work, but we're also interested in learning what does! To enable success reports, set the OPENCUTS environment variable (eg. by starting the installer with OPENCUTS=true ubports-installer from the terminal). This will make the installer automatically report a PASS run, if the installation process completed without errors.

By default, the created runs will be reported anonymously. If you have an account, you can copy your API token and provide it to the UBports Installer using the OPENCUTS_API_KEY environment variable (eg. by starting the installer with OPENCUTS_API_KEY=<your-access-token> ubports-installer from the terminal). The installer will then report runs associated with your account. You can sign up for UBports OPEN-CUTS using your email address. Don't worry, it's easy!

packages and changelog: https://github.com/ubports/ubports-installer/releases/tag/0.5.3-beta
find out what packages still need testing: https://ubports.open-cuts.org/build/5f7d9d8f04d6b6000750aaac
report a test manually: https://ubports.open-cuts.org/report?system=5e9d746c6346e112514cfec7&test=5e9d75406346e112514cfeca&build=5f7d9d8f04d6b6000750aaac

thank you

Testing the installer is always difficult, because of the many different cases and configurations to keep track of, so we depend on the community to help us out. Thank you for your help!

NeoTheThird

While that is a nifty and compact solution, it has some issues. For one, adb exec-in and exec-out are janky as fuck. It does very very weird things with error handlings, resulting often in unexpected silently corrupted files. Would absolutely not recommend. That, and the fact that there's no tar on windows, is why i proposed taring on the device and pulling for installer integration. Another angle has been started here.

NeoTheThird

Hey porters,

we have just landed an overhaul of our devices page and would like to encourage you all to list your devices there more early to make upcoming ports easier to discover. Adding new entries can now be done by creating a merge request with a markdown file that contains a YAML metadata block.

We invite you all to help us complete and refine the entries, because the community probably knows best about all the different ports

Cheers,

Jan

NeoTheThird

Re: Git workflow

Here's something i wrote up for another installer user the other day, maybe that's helpful to you

you'll want to keep your master completely in sync with our master, so when you navigate to it on your machine, the first thing you'll do is git checkout master to make sure you're on your master, then git pull upstream master --rebase to fetch the latest version from our master, git push origin master to push our master to your master on github. Now if you want to implement a new feature, you will create a branch by going git checkout -b nameofbranch. Then you make your changes. If you want to create a commit, you git add path/to/files for all your files you want to commit and then go git commit -m "My Commit Message". As soon as you have all your commits created, go ahead and git push origin nameofbranch to push your branch to your own fork on github. Then go to the webinterface to create the pull request.