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

Here's the official GitHub Statement and a blog post from Nadella.

I wouldn't make this so much about feelings. Let's face it: Microsoft is not evil. But Microsoft isn't necessarily good, either. Microsoft is just a very big company doing what they think is best for their business, and that doesn't always mean it's what's best for everyone else. And yes, they're dabbling with some open-source stuff, but only where it's required or at least very difficult to justify not to have it open. Microsoft wants to stay in control. They already lost the windows-server market to the "foss revolution", so they understood that they have to join the winning team if they want to stay on top. That alone doesn't make them evil. In fact, most companies work that way (even GitHub always has, that's why the GitHub server is proprietary), but they could still change. So let's give them credit for embracing foss where they are and encourage them to abandon their proprietary projects and selfish business techniques. They're saying they aren't the enemy, let's believe them that. But that doesn't automatically make them our friends.

What's worrying to me about this potential acquisition is that it will concentrate too much power with one entity, and that can't be good. This is a development that has been going on for a while now, the FOSS community made the mistake to place too much trust in GitHub for a long time.

GitLab is different that way. It's still a for-profit company behind it, but the client is open-source. You can even host it yourself, and even though real federation is not there yet, it's a lot more likely to come.

The biggest problem GitLab has at the moment is that it's a lot smaller than GitHub. GitHub has 27 million users and 49 million repositories, [GitLab only has 100.000 users/groups (even though that number seems to be pretty old). When we moved UBports from Launchpad to GitHub a little more than a year ago, we discussed GitLab as an option as well, but dismissed it because of lack of adoption. Since then, Gnome has proven that it's possible to move a big open source project to GitLab, and it worked for them.

All in all, i have to say i'm in favor of moving, but i would not rush things. The migration itself is pretty straightforward thanks to great tools, but there's a lot of stuff around it that needs to be modified. Most work will probably be updating the documentation and workflows. Worth it, but no need to rush it. We could make some preparations now, really analyze what to look out for, and make the move after OTA-4.

And for the lack of users, build it and he will come i guess

Hey Alan,

thanks for the writeup, that is a great explanation, especially for our non-technical users.

I can confirm that the switch to xenial is on the horizon. After the release of OTA-3 (which still uses vivid), it's full steam ahead with xenial work. To quote what Marius' famous words: "We want to walk up the stairs, not jump up the stairs," so i don't know what mir version the initial stable release of ubuntu touch on xenial will use, but i've seen the Wayland tests already working on some phones, so who knows... In the long run, Ubuntu Touch will ideally just use the latest stable version of Mir, we should not allow for another big backlock like the current one to accumulate. I'll restrain myself from using the stairs quote again.

It's great to see support from Canonical(-employees) here, thanks a lot Alan! I hope it will be a fruitful collaboration, without your continued work on Mir our already big task would be a lot more difficult. I'm sure you will also profit from us as an active downstream project that uses Mir.

Cheers,

Jan

"Explicit is better than Implicit" is a great principle for programming language design, but a user-friendly user-interface plays by different rules. In UX design, actions should be intuitive, and what could be more intuitive than tapping the background to get to the background?

If you think there needs to be a text or icon to hint for this action as well, ok, maybe. But it should be way more subtle than in the mockup. For me, the Application spread is one of the most distinctive and beautiful features of Unity 8, we can't f*** (mess) this one up.

A go-to-desktop-app in the spread... I don't know. Being able to just tap the background feels way more practical to me. Either the go-to-desktop-app would always be in the end of the spread, which would cost you time, or it would be somewhere in the list making it more difficult to find an application you want to switch to. Why add another UI element, if there's already a perfectly good option we can go with that doesn't bloat the UI nor reduce ease of use of the existing usecases?

On the topic of what is home, might i add:

Don't kill the desktop: A manifesto

In my opinion, Unity 8 should become a proper desktop environment, and that includes being able to put stuff on your desktop. Doesn't have to be applications (unless the user wants to, then let them do it), but it would also be incredibly useful for short-lived files. For example, i'm very often travelling by train in Germany, and since we don't have a ticketing app for Ubuntu Touch, i always put the ticket-pdf on my phone and open it in document viewer. That's something i would put on my desktop. Yes, i know, Gnome removed that feature a while back. But for many people that is a standard feature of Desktop Environments and it would be foolish to dismiss it as a legacy usecase. For me, it is clear. The desktop is my 127.0.0.1. And i'd love an easy way to get there.

I'm with @Flohack on this one. We should only have the real essentials as core apps preinstalled. In my opinion these are:

• Terminal
• Phone
• SMS
• Clock (with timer, alarm, etc)
• Camera and Gallery
• Weather
• Address-book (with carddav support)
• Calendar (with caldav support)
• Files (with Nextcloud integration, Document viewer and plain-text editor)
• Webbrowser
• E-Mail client
• Music (with the option to play from files, 7 Digital drm free store)
• Openstore (for downloading everything else)

@WLBI It's not set in stone how soon this will be available, but we will support Anbox (Native Andorid app compatibility), so you will be able to run DB Navigator and clever-tanken if you can get your hands on the apks. Anbox already works(-ish) on Ubuntu Touch and it might even (as soon as it's stable, but not in our first release) be pre-installed.

If you want to chat about Ubuntu Touch and its related projects, you've come to the right place!

Here are some tips to help you get the most of this forum:

1. If you're new to the community, please read our Meet the Community page. It will walk you through our various other community platforms, like the documentation (available in several languages), our Telegram group, or our Matrix room #ubports:matrix.org
2. We strive to be considerate, respectful and collaborative. All UBports members work for free in their spare time, so try to appreciate their work. The Ubuntu Code of Conduct applies in all areas of the UBports community.
3. Please tag your posts to make it easier for other users to navigate the forums in the future. For example, if your post concerns the Fairphone 2, just tag your post that way and it will show up in this list.
4. If you want, you can introduce yourself here.
5. Found a bug? Please report it on GitHub.
6. The right to free speech means the government can't arrest you for what you say. It doesn't mean that anyone else has to listen to your bullshit, or host you while you share it. The 1st amendment doesn't shield you from criticism or consequences. If you [...] get banned from [this] Internet community, your free speech right s aren't being violated. It's just that the people listening think you're an asshole, and they're showing you the door. - xkcd 1357
7. Use common sense
8. Have fun!

@jobus

The checksums for the partition images are served by api.ubports.com. This sha256 hash is checked both in the manual install instructions and in the installer. You can find the json for your device here: https://api.ubports.com/v1/devices/vegetahd

I will add checksums for the executables and installation packages of the installer to the releases page, doing that automatically in ci has been on my list for a while. Wasn't my highest priority so far, because github defaults to https, so the only remaining attack vector i can see would be to switch the files hosted there, which is not very likely to happen unless we have a mole, the account of someone with access to the org gets pwned or someone hacks Microsoft. In all cases, there'd be more efficient ways to do much more severe damage, but since this has been requested some times now, who am i to stand in the way of progress.

Hey everybody, sorry about the late reply. I just had a report of a successful fix for this on Telegram. The user who had the exact same problem was coming from CyanogenMod 11, while our HAL-container for the Oneplus One is based on CyanogenMod 12. What you can do is flash the firmware of CyanogenMod 12. Download this zip file, extract it and open a terminal in the folder containing the files. Then, reboot your phone to fastboot/bootloader mode and connect your device with a usb cable. Run the following commands to flash the firmware:

fastboot flash modem NON-HLOS.bin
fastboot flash sbl1 sbl1.mbn
fastboot flash dbi sdi.mbn
fastboot flash aboot emmc_appsboot.mbn
fastboot flash rpm rpm.mbn
fastboot flash tz tz.mbn
fastboot flash LOGO logo.bin

Making a mistake at this stage can brick your device, so please make sure no of the commands return an error. Last but not least, reboot the device.

Why does it have to be one or the other, when we can do both? The other selling points of Ubuntu Touch don't magically go away just because it can also run android apps.

Having Android app compatibility helps lower the entry bar for many users. I'm not talking about the general public and people without any interest in Linux and free software, i'm talking about Linux users that still need (not because they want to use them, because they have to) certain apps, like WhatsApp, Snapchat, etc. Even some UBports team member even carry an iPhone or Android phone additionally to their Ubuntu Touch device with them in order to use these (not pointing fingers here). That is ridiculous, and if we can avoid that, why wouldn't we? Sure, you can dislike these apps, but if you need WhatsApp for your work, what are you going to do about it?

Another thing that is disregarded in my opinion is the open nature of this project. A (imho) unique selling point of Ubuntu Touch is the fact, that it let's you use your phone like a real computer. I'm not talking about attaching a screen, mouse and keyboard here, i'm talking about the open nature of the OS. You should be allowed to run whatever weird-ass piece of software you find, just like on the Linux desktop. And Anbox already works on the Linux desktop (in fact, it already works more or less on the phone as well), so artificially breaking compatibility would seem really weird to me. If i want to run something on my phone, who the f*ck are you to tell me not to do so?

The argument that Android compatibility would discourage developers from creating native apps for Ubuntu Touch is only valid up to a certain point. Big for-profit companies don't care about Ubuntu Touch, the market is way too small for that. There won't be a native Whatsapp client, there won't be a Netfilx app, that's just how it is. Again, you can go all Stallman about it and say that you don't want to use these services anyways (and you are probably right), but until there are alternatives, it is kind of necessary for many people.

What's also disregarded in the discussion about the unavailability of Google Mobile Services is how many apps work perfectly fine without them. 2300+ free and open source apps from f-droid change the math a lot. Also, many of the Apps from Google Play are available as Apk downloads, and can be used without Google Mobile Services.

Last but not least, i want to remind you a) how hard it is to develop Apps for Ubuntu Touch at the moment (ask @DanChapman, he will sing you a song about it) and b) how much work it is to maintain the SDK. UBports only has a very small and busy team, so having Android compatibility just takes the pressure of for now. It is by far not an ideal solution, but it could help a lot of people using Ubuntu Touch as a daily driver, and that's what we're aiming at after all. We don't want (and we won't) make Ubuntu Touch just another Android rom, we have unique advantages that won't go away. We will still have native apps. But having Android compatibility is the right decision for now.

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!

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

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!

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!

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.

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

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.

Awesome, saw you opened a PR here, i'll give you a code review with some pointers. Really appreciate the work you put into this, i'm confident we can get it done fairly soon

Hey @AlainW94,

maintainer of the installer here

Kudos on how far you've come already, that's really cool! This is very similar to what we had planned in this issue. The commands there should work pretty much on every device with enough storage. Could you maybe open a PR soon, so we can coordinate the code to not conflict with the other things we have planned in the installer?

Some notes:

• You might want to avoid streaming output of adb commands to tar directly to the disk of your machine, but rather tar on the device. Even though it'll take up some space on the device, it'll be worth the added stability. Adb is very unreliable when it comes to exit codes and what buffer to write to. You don't want it to silently write "waiting for devices" to your precious backup file and corrupting it without you knowing.
• You'll need to implement adb pull in the promise-android-tools module. It'd be great if you could open a pr for that rather sooner than later.
• This is not a small undertaking, so in try to aim to get your changes in early wherever possible to avoid merge conflicts going forward. You might for example want to get your pull animation in now already.
• Avoid device-specific hacks and workarounds in the installer code. You'll have heard about the config file format introduced in 0.3.x-beta, which aims to pave the way to make the installer code device- and os-agnostic. I could imagine adding another field like actions[], which holds steps like this, to the entry in operating_systems. We might even want to introduce some braking changes to the file strucutre to do this really right.

Hope i did not overwhelm you, just excited for community contributions to my pet project XD

If you need any help, hints or pointers, please let me know.

Thank you!

@jobus

The checksums for the partition images are served by api.ubports.com. This sha256 hash is checked both in the manual install instructions and in the installer. You can find the json for your device here: https://api.ubports.com/v1/devices/vegetahd

I will add checksums for the executables and installation packages of the installer to the releases page, doing that automatically in ci has been on my list for a while. Wasn't my highest priority so far, because github defaults to https, so the only remaining attack vector i can see would be to switch the files hosted there, which is not very likely to happen unless we have a mole, the account of someone with access to the org gets pwned or someone hacks Microsoft. In all cases, there'd be more efficient ways to do much more severe damage, but since this has been requested some times now, who am i to stand in the way of progress.