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.

@marc_aurel Sounds great! We'll certainly try to be there with some members of the core team, and i hope we'll also get some more community devs to join the party

"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.

@Shannon64 You need to reboot your phone to bootloader/fastboot mode (press and hold the volume up and power buttons until the phone reboots) and connect it to your pc with a usb cable. Then, open a terminal and navigate to where those files are (you said you put them on your desktop, so it's cd Desktop). Run sudo apt install fastboot to install the fastboot utility. Then run the commands from my post above and watch out for any errors. After that, hold the power button until the phone vibrates to reboot the device.

@Shannon64 Were you talking to me? The user i was supporting was able to resolve the issue with my above suggestion, so if you have the exact same issue and you also came from an operating system other than cyanogenmod 12, i recommend you try what i described.

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.

I'll leave a lot lying around, but if you want we can meet somewhere.