Hi everyone, i'll try to keep this short:

Intro (Motivation)

First of all, i opened a new Topic (instead of using the old "Roadmap" Topic in the Forum) because i think that topic was about an "idealistic" roadmap = what do we want to have as a end-product. This Roadmap here is supposed to be a detailed list what needs to be done. And perhaps some links and stuff that might help. I'm not saying that the forum is the best place but i was under the impression that it is very hard to see where to help/begin and what is the status when there is talk about "moving to 16.04 base" or "basing on Halium 7.1".

@Developers please don't get this wrong but sometimes i am under the impression that some or all from the core team are working on all projects at the same time. This is no ones "fault" since we just don't have that many devs and i am very thankful for your work, however i think that for an optimal developement pace some focusing (aka a Roadmap ;-P) would help sometimes.

Why i think we don't have this already

I know that there are our github milestones for 15.04 and 16.04 here, however the tasks are

• very unspecific
• rather wishes than tasks

What is missing

AFAIK we don't have a real prerequisites list for a devices kernel and android base in the moment. This would help a lot since achieving this prerequisites would be tasks to each milestone. So to make a good Roadmap, we first need to know what needs to be done exactly. (Of course we cannot know all of this in advance).

Action Points

1. Identify what needs to be done exactly. (like what features are needed inside the kernel for systemd, for lxc, for apparmor? A first reference might be what canonical did inside "project avila - xenial kernel" to get a 16.04 base with systemd and snappy going?)
2. Decide which ones are "must haves" and which are "nice to haves"
3. Create big milestones out of this.
   4.Set up some place to gather info material on this together

A Quick Sketch

Milestone 1 (Gathering Info for Roadmap)

1. Identify kernel features needed for Ubuntu 16.04 rootfs
   1.1. Which features are needed for systemd? What's the earliest mainline version including these? (most phones have 3.4 or 3.10 based kernels so earlier would be better, IF newer, is there a backport available? Where is it?)
   1.2. What version of apparmor needs to be inside the kernel? (Mainly needed for snappy i guess?!)
   1.3. Check what canonical did to their images, see if we should reuse anything?
2. Identify kernel features needed for Halium 7.1 base ( I know, this should be on haliums roadmap but we need to adress this too)
   2.1.What lxc features are needed? (different lxc features in different mainline kernels, e.g basic support was in 2-6 something, almost everything landed until 3-8 only unpriviliged containers landed in 3-12)
3. Identify all steps needed so Halium 7.1 and Ubuntu 16.04 interact nicely
4. Identify all steps needed to get Mir 1.0 (or 0.27) with yunit up-and-running.
   4.1. Do we have to do anything ourselves? (since there is a mir-staging PPA and yunit devs are working on 16.04 themselves?)
   4.2 Will there be any ABI/API breakages we have to consider?
5. What steps will be involved in transition of apps/frameworks to 16.04?
   5.1. Should we move to snaps? Alternatives? Consequences for each decision?
   5.2. Do we have to build the frameworks and distribute them somehow? How?
   ...

Milestone 2 (Setting Prioreties and Set Up Infrastructure)

1. Set Prios to tasks gathered in Milestone 1, perhaps even state expected difficulty
2. Set up some place devs can gather links/info without doing shiny documentation around this
3. Tell the docu people to keep an eye on that place and merge important stuff into docu.
4. Get started with most important tasks.
   4.1 Important assign who is looking into what!

Milestone 3 (Booting 16.04 rootfs with Halium 5.1 base)

Dont't know what is needed here...

Milestone 4 (Getting display server + everything else to work on 16.04-H5.1)

Dont't know what is needed here...

Milestone 5 (Move to Halium 7.1 base)

Dont't know what is needed here...

The bad news...

... is that this needs to be done by our core devs because only they will know what exactly what needs to be done (i guess?).

Outro

This is not meant as an attack on anybodys behaviour so far or the state of documentation or anything, just some ideas i had that i wanted to share and would like to hear your thoughts about it.

Hi everyone,
I'm new to this group (at least in really trying to contribute) but i would like to summarize a proposal, mainly to all those who want to help but don't have dev skills or money. (I'll try to keep it short but it's a big topic, sry)

The documentation is IMO in a very bad shape (both the remaining one by canonical and the ubp parts) and one thing i think that really held back UT was that this has allways been that way. @ all people who have been involved in this, please don't take this too harshly, i fully understand that as developer there are more important things to do than documentation (and also there's allways too little time). However, since this is a 100% community driven project we need to improve this so porters/app devs/non devs may more easily contribute to the succeess of the whole group. ( I personally was trying to do a few things with my limited skills back in 2016 and didn't get far and a few friends of mine started to develop a few apps and were almost immediately frustrated with out-dated docu)
So long story short, documentation is the future(IMO ;-P)

To get going I would like to share my initial ideas on steps we have to take and hear your thoughts on this

Step 1: Analyse the situation
The current wiki is sorted into

• Install
• Developement
• Bug reporting
• links

This is a somewhat historical picture since it was very nice when only porting to new devices was done by ubp. I'd think something like the following would be more appropriate today:

• Install (keep this)
• User Contribution
  • Bug reporting
  • Translating
  • Documentation (Guidelines)
  • Donating (not shure if this is a must have, it's pretty straight forward how to donate ;))
• System porting & developement
  • Device Overview
  • Specific Device Pages
  • General Porting Information (just link to canonicals guide somewhere and only keep ubp stuff in this wiki)
  • Kernel Information (what patches/backports are needed for which features, e.g. lxc -> libertine, apparmor -> confinement, dunno -> miracast)
  • architecture armhf vs arm64 (aka why only M10 got snaps and 16.04 base)
  • ubuntu base (document what is different from the desktop 'mainline' ubuntu?)
• App Developement
  • Framework/APIs (not shure, this is still to be decided right?!)
• UBP Infrastructure
  • build system (how does this work, ...)
  • community organisation

Step 2: Tell people how they can help
This is the actual core of my proposal i think; There are a few things in that list that no one who isn't involved in really working on the code may answer. HOWEVER, there are many things that people like me, who can read a few things, use a search engine or just have a phone/tablet they want to see ported can do. So the important thing is to tell them(us) how and what to document. I have a few ideas that might be achievable without coding skills:

• Make a big table where all the hardware info is gathered of every device. With this i don't mean something like (2Gb RAM) but rather every chip inside as exact as possible ( e.g. for the bq aquaris: RAM = SKhynix H9TP65A8JDAC PRKGM 510A 2MYRV05bQ3 [at least that's written on the chip]) and check whether there are drivers in the mainline kernel (and IF, link to the specific patch and document the kernel version) This is something everyone might do who wants his/her device ported.For reference, something like the sunxi mainlining matrix for allwinner ARM SoCs combined with a more detailed version of the wikipedia comparison of smartphones

• Gather device specific Info for existing/wished for device in each specific sub page. For example is the storage on the device so scarce that something like the rootfs-modifier for the HTC Desire Z by w-flo is necessary? Often, this is rather recycling of info posted online for example on xda forums or on UT specific blogs. (e.g. for bq e4.5 one might find very usefull info @ sturmflut's blog which is now @ lieberbiber.de others might try to see if some ways of obtaining info is similar on their device.

• Also for any topic: go through the web and try to document common errors and how to solve them when porting or ways to debug and such stuff (e.g. watch marius gripsgard's talk @ ubucon 2016 and filter out usefull info for devs)

As I Said, these are only ideas and i would like to hear your thoughts. However I for one would like to contribute to this with all the (little) time i can spare. For starters, a quick documentation how to use the wiki would be nice. It's not too complex but is there a way that is not as chaotic as cloning the repo and editing it with an editor like atom/geany, whatever? (is there a gui like for dokuwikis or something?!). Maybe another "documentation" work group might be usefull?
Best regards

@guru KDEconnect is an extremely cool app to bridge all your devices. Here is the github repo and KDE community wiki entry. In just a few words:

1. Link your PCs, Smartphones, Laptops via Wifi or Bluetooth
2. Share content (send files, share clipboard) encrypted and with nautilus (filemanager) support
3. Some nifty features for the smartphone:
   • Find my phone (click on desktop and phone will ring)
   • See notifcations, take calls, answer on messager on desktop
   • Send CLI commands/touchscreen/keyboard events to desktop
   • See phone status (battery) on desktop

Sorry for redundancy, Stefan already mentioned a few of these, i'm just a big fan of this app and would love to see it on UT

A.S: This is something like a working document for me and others to join efforts to get the convergence going from the x86 side. I will not have time (and already spent too much of it) working on this for the next 3 weeks since i have some pretty important exams and if i don't stop now it will probalby be very bad. However, maybe some of you might want to try this out a little further and once i come back from university i will find that all of this works Good Luck to all who try this out and please post any success/faliure (the last one is often even more important ;-)) on this thread!

Simulating a "Ubports" 16.04 on x86 hardware (or VM)

What does this mean? Well there are some tablets out there with x86 hardware which desperately need to get hold of the UBports experience, but how to do this?

Idea

• Goal: Have a Ubuntu 16.04 with Yunit (atop mir) running snaps & (phone) clicks
• Path
  • Install Ubuntu 16.04
  • Set up Yunit
  • Set up sth. like 15.04 (armhf) container to run phone apps

Why is this usefull? This is not really Ubports, however it is somehow what i personally think we can explore and try out to show where the project can head in the mid-term. (In the long term it is essential to migrate the UITK to QQC2-suru or Kirigami or whatever and update the ubuntu-sdk-framework from 15.04.6 which is not available in 16.04 aka migrate the 15.04 click apps to whatever we will be using afterwards). If this works, the pressure behind updating the underlying Ubuntu version is lowered (at least i believe so)

Roadmap

1. Set up 16.04 (x86) with Yunit and test basics - ~100% done
   1. Setup 16.04.3 in VM download 16.04 here - works
   2. Install Yunit as described on their blog - works
   3. Test apt install method! - works
   4. Test snaps! - works (some do not and for dash integration of new/removed packages, reboot required)
   5. Test clicks! - fails (cause missing 15.04.6 framework and all clicks fro armhf only AFAIK)
   6. Installing things from software center - works (also gtk+ apps)
2. Set up 15.04 and test clicks - ~0% done
   1. Setup 15.04 in VM download 15.04 here - todo (which version would be best?! PROBLEM: armhf images not available for download so testing this is hard to compare to LXC (armhf) container)
   2. Try to get clicks running (openstore etc.) - todo (maybe stable-phone-overlay ppa needed?!)
3. Set up 15.04 (armhf) LXC container on 16.04.3 (x64) and connect both - ~10% done
   1. Use 16.04 with yunit as described in (1) and set up LXD how-to here (update: this way of installing won't work directly since there are no vivid containers @ linuxcontainers.org however there are the sdk images @ https://sdk-images.canonical.com/releases/ ) see also additional ressources at the end of this document - work-in-progress... PROBLEM: cross-architecture container don't work that well, some possible work-arounds i see:
      1. Try qemu ("real" virtualization) in seamless mode to emulate an armhf environment (downside: ressource intensive)
      2. Compile the clicks from the openstore for x86 architectures (32-bit binaries work on 64-bit but not vice versa so 32-bit would suffice) and perhaps use a 15.04-amd64/i386 container instead of armhf
   2. Launch an Ubuntu 15.04 (armhf) container - todo (maybe impossible, might work with sth. like qemu-user-static but has downsides)
   3. Install dependencies and configure the container (internally at first) to enable (phone) clicks as done in (2) - todo
   4. Test if installing clicks (headless) works - todo
   5. Make host hardware and files accessible for Container (some usefull links: 1, 2, 3, 4 a quick and dirty thing would be to use something like mirscreencast just as a proof-of-concept) - todo
   6. Test graphical clicks! - todo
   7. Test audio (in/out) clicks! - todo
   8. Test networking - todo
   9. Play around with phone apps! - todo
4. Polishing - ~1% done
   1. Write the docu! (best if that gets done while testing) - wip
   2. Gather what is still missing - done, almost everything
   3. auto-start container on host bootup -todo
   4. write script which does all the installing/configuring on vanilla 16.04 - todo
   5. See how the appstore can be mde to automatically use the container to install clicks (if necessary...) - todo
   6. Make cool videos of this! - todo

Docu

This is

(A) for people to reproduce and work further on the project and

(B) so we can write a bash script or something to do all necessary steps on a vanilla 16.04 system

The ways to install Virtualbox/Qemu or anything like this are not explained for now since some may want to try this on an actual device. On an actual device, i would also recommend using isorespin.sh from Ian Morrison (http://linuxiumcomau.blogspot.de/) to respin the iso with the most recent kernel. This often helps with hardware problems from my experience!

Setting up 16.04.3 (64-bit)

For doing this maybe it's usefull to move inside a directory, however i'm leaving this out for now since i am not your janitor.

wget http://releases.ubuntu.com/16.04/ubuntu-16.04.3-desktop-amd64.iso
# in the script we should check sha256sum or something afterwards, i always do this manually (sorry, i'm a noob ;-P)
wget http://releases.ubuntu.com/16.04/SHA256SUMS
sha256sum ubuntu-16.04.3-desktop-amd64.iso
# compare with what is listed in the SHA256SUMS file
less SHA256SUMS

Now you can either Respin this iso or directly move to your VM/tablet and install Ubuntu as usual...

Installing yunit

As described on the yunit blog:

wget -qO - https://archive.yunit.io/yunit.gpg.key | sudo apt-key add
echo 'deb [arch=amd64] http://archive.yunit.io/ubuntu/ xenial main' | sudo tee /etc/apt/sources.list.d/yunit.list
echo 'deb-src http://archive.yunit.io/ubuntu/ xenial main' | sudo tee --append /etc/apt/sources.list.d/yunit.list
sudo apt update
sudo apt upgrade
sudo apt install yunit-desktop

Setting up LXD and 15.04 (armhf) container - failed attempt

ATTENTION: This does not work as described in the whole section and is just an "extended log" for all who are interested

sudo apt install lxd
newgrp lxd
lxc remote add images images.linuxcontainers.org
# there are no vivid images @ linuxcontainers.org, need to do this manually
lxc image list images:
lxc launch images:ubuntu/vivid/armhf ubuntu-15.04-armhf

TODO If this works, the container has to be auto-started on host bootup! TODO

# Testing on the ubuntu 16.04.3
sudo apt install lxd
# says already newest version so ommiting creating a new group
lxc remote add ubuntu-sdk-images sdk-images.canonical.com
lxc image list ubuntu-sdk-images
## Okay this does not work, i wanted to avoid installing more of the sdk than needed on
## the host but let's try it as proposed in the second link under additional ressources
sudo add-apt-repository ppa:ubuntu-sdk-team/tools-development
sudo apt-get update
sudo apt install ubuntu-sdk-tools
# Now listing the available remotes:
lxc remote list
# damn, the sdk images have been deleted, so we have to download them manually and install
# as discussed by stephane graber in the 4th link under additional ressources...

We have 2 tarballs for every container inside (https://sdk-images.canonical.com/releases/vivid/) with the following combinations:

• amd64 - amd64
• amd64 - armhf
• armhf - armhf
• i386 - armhf
• i386 - i386

And i am assuming the first means the host, the latter the container architecture. Since trying this on an amd64 host, i choose amd64 - armhf to download and according to stephane, we can install the metadata tarball (the tiny one) and rootfs tarball (the bigger one) with the following command

lxc image import <metadata tarball> <rootfs tarball>

wget https://sdk-images.canonical.com/releases/vivid/ubuntu-sdk-15.04-amd64-armhf-lxd.tar.xz
wget https://sdk-images.canonical.com/releases/vivid/ubuntu-sdk-15.04-amd64-armhf-root.tar.xz
lxc image import ubuntu-sdk-15.04-amd64-armhf-lxd.tar.gz ubuntu-sdk-15.04-amd64-armhf-rootfs.tar.gz
# This should state "Transferring image: xx%" and then "image imported with fingerprint: xyz"

Now we can list our image and then try launching it

lxc image list

we see that currently, no alias is set and since i am lazy and don't want to type the fingerprint all the time, we edit the image

lxc image edit <fingerprint>

and add the line

  aliases: 15.04

but this does not seem to work right now... (it doesn't update the aliases) strangely, it states the architecture of the container to be x86_64 so this may be the wrong container...

To prevent this problem, i deleted the container again and imported again attaching the --alias=15.04 flag

lxc image delete <fingerprint>
lxc image import ubuntu-sdk-15.04-amd64-armhf-lxd.tar.gz ubuntu-sdk-15.04-amd64-armhf-rootfs.tar.gz --alias=15.04

This works and now we can just use this alias for referring. Let's test it with simply opening a bash shell in the next step...

It seems, we have to launch the lxc container from the image we just imported:

lxc launch 15.04 ubuntu-15.04-armhf

However, trying the "armhf-armhf" image will give the error:

error: The image architecture is incompatible with the target server

Damn, this seems to indicate that the guest container has to have the same architecture as the host

(alhough i was able to run a i386 image on 64-bits but perhaps) Testing this thesis on Ubuntu 16.04.3 (x64, unity7, x11, qemu-user-static installed) with a xenial-armhf (fails, but with a more complex error code), testing with artful-amd64 (works) testing with artful-armhf (fails)

Trying again

Assuming we already installed LXC, now only getting the correct (hopefully?!) images from the old sdk and setting up the static qemu-binaries to emulate armhf...

sudo apt install qemu-user-static
wget https://sdk-images.canonical.com/releases/vivid/ubuntu-sdk-15.04-armhf-armhf-lxd.tar.xz
wget https://sdk-images.canonical.com/releases/vivid/ubuntu-sdk-15.04-armhf-armhf-root.tar.xz
lxc image import ubuntu-sdk-15.04-armhf-armhf-lxd.tar.gz ubuntu-sdk-15.04-armhf-armhf-root.tar.gz --alias=15.04-armhf

However, qemu-user-static was already installed in the VM system and again we get the error...

error: The image architecture is incompatible with the target server

Theoretically moving to container to apply changes needed for click

lxc exec 15.04 /bin/bash

This does however not work currently

TODO find out what is needed to get this to work. TODO

Setting up LXD and 15.04 (amd64) container with recompilation of clicks

LXD

sudo apt install lxd	
# instead of apt you can also use snap on snap enabled systems
newgrp lxd

The remote for the sdk-images seems to have been removed from the LXD config so we get the image manually...

wget https://sdk-images.canonical.com/releases/vivid/ubuntu-sdk-15.04-amd64-armhf-lxd.tar.xz
wget https://sdk-images.canonical.com/releases/vivid/ubuntu-sdk-15.04-amd64-armhf-root.tar.xz
lxc image import ubuntu-sdk-15.04-amd64-armhf-lxd.tar.gz ubuntu-sdk-15.04-amd64-armhf-rootfs.tar.gz --alias=15.04-amd64
# This should state "Transferring image: xx%" and then "image imported with fingerprint: xyz"

Now we have an image based on the 15.04-amd64-rootfs, we can start a container by using

lxc launch <image-alias> <container name>
# in our case
lxc launch 15.04-amd64 ubuntu-15.04-amd64

Compiling the clicks

Attention: The openstore in this example compiled and installed successfully on 16.04. However it has some problem with actually running which has probably to do with mir. So not everything may work exactly as described below

The theoretical workflow once all dependencies needed is:

• get the source code (git clone <repo.git>)
• qmake <appname.pro>
• make install
• and launch

So far we have not moved inside the container, you can for example start a bash shell in the container by using

lxc exec ubuntu-15.04-amd64 /bin/bash

Dependencies

Beside packages that should be included in the system anyway (build-essential, gcc) a few things may be needed additionally (i will show the error code i got when trying to compile the openstore on a ubuntu 16.04.3 amd64 without it in italics)

sudo apt install build-essentials git bzr libclick-0.4-dev qt5-qmake qtdeclarative5-dev

Unfortunately, we also need ubuntu-sdk-qmake-extras which however is only provided via PPA for 14.04/16.04 here. TODO: find alternative source for this

Getting the code

Most apps (AFAIK) in the openstore have a link to their sources. Move to the sources and clone them to your local folder

​ Launchpad

you navigate to the "code" tab and the necessary command to clone is displayed, something like:

bzr branch lp:<yourapp>
# example: uNav navigation app by Marcos Costales
bzr branch lp:unav

​ Github

you click on the green "clone or download" button and copy the link (something like "https://github.com/[...].git") into the following command

git clone <your link>
# example: uMatrix messenger app by Larrea Mikel
git clone https://github.com/LarreaMikel/uMatriks.git

Compiling & Installing

So since these apps are Qt(QML) based we start with qmake. This is a symlink to qmake-qt4 and/or qmake-qt5 respectively (you can have both simultaneously, however choosing the right one is necessary for the process to work) which are actually located in (/usr/lib/x86_64-linux-gnu/qt<4 or 5>/bin/qmake). You can specifiy which qt version to use by appending a flag to the qmake command:

qmake -qt=qt<4 or 5> <yourapp.pro>
# example: openstore by Brian Douglass
qmake -qt=qt5 openstore.pro

• If "manifest.json is not found" sometime the manifest in the sources has the ending .in, to make this work just use mv manifest.json.in manifest.json inside the source folder

Once this has finished without being aborted, you can run

make install

Testing

You should now be able to test what happens when you execute the binary at (/lib/x86_64-linux-gnu/bin/<yourapp>)

cd /lib/x86_64-linux-gnu/bin/ 
./<yourapp>
# example: openstore
./openstore

Additional Ressources

• http://www.techradar.com/how-to/computing/how-to-install-ubuntu-onto-a-windows-tablet-1319489/1 (older description how to install ubuntu on x86 tablets)
• https://gist.github.com/chihchun/30fd95f9f906ab1e7731040eddc840ee (how to use Ubuntu SDK containers (15.04/16.04))
• https://sdk-images.canonical.com/releases/ (the according SDK images)
• https://stgraber.org/2016/03/30/lxd-2-0-image-management-512/ (some more info on LXD)
• http://cdimage.ubuntu.com/ubuntu-touch/vivid/daily-preinstalled/current/ (vivid preinstalled images from canonical (don't know were they are for Ubports) perhaps for LXC containers)
• https://wiki.ubports.com/wiki/Set-up-a-Clickable-working-environment-inside-an-LXC-container (ubports wiki page were LXD is also a topic...)
• https://stgraber.org/2016/03/11/lxd-2-0-blog-post-series-012/ (Stephane Grabers series on LXD)
• https://stgraber.org/2012/02/03/ever-wanted-an-armel-or-armhf-container-on-an-x86-machine-its-now-possible-with-lxc-in-ubuntu-precise/ (OLD cross-architecture container guide, using qemu-user-static)
• https://resin.io/blog/building-arm-containers-on-any-x86-machine-even-dockerhub/ (more recent cross-architecture container info, also based on static qemu)

Usefull when using a VM

since most time we just need a shell, it's usefull to easily ssh into the VM. for this purpose, you can go to the settings of the VM (in Virtualbox that is), navigate to network -> NAT (adapter 1), open the additional feature and go to "port forwarding" and add a new rule:

Name	Protocoll	HOST-IP	HOST-port	GUEST-IP	GUEST-port
ssh	TCP		3022		22

In the VM install openssh-server

sudo apt install openssh-server

and in the host you can simply do

ssh -p 3022 <user>@127.0.0.1 

Hi all,
I'm Erik from Germany and I've been following Ubuntu on my desktop since 9.04 and UT since it's beginning, bought an bq e4.5 and unfortunately sunk it in a river -.-
I've been watching UBports since it's beginning and allways wanted to contribute so i tried porting to an old tablet lying around (Samsung galaxy tab gt-p1000) however I'm not a dev so i couldn't even get it to build. Then time was running out and canonical came out with the bad news but UBports made me hope again so I want to try to help any way i can to make this project live on and succeed in the end ;-P.

For this purpose i would like to combine my introduction with a proposal to all those who like me can neither help on the code side nor with money: Why not try to help with documentation? I'll open up a new thread with details for my proposal since it is a little off-topic here...
Thanks to all those who contributed or/and are still contributing to the idea or show their solidarity!
Best regards

By the way, not 100% this topic but related to it i have posted an idea/effort to bring the phone apps to 16.04 + Yunit so we might some day actually enjoy the work on convergence on x86 hardware. (Spoiler, it does not work so far, sorry) so head over to https://forums.ubports.com/topic/514/simulating-a-ubports-16-04-on-x86-hardware-or-vm-work-in-progress if you are interested!

@Mitu , @sverzegnassi

i stumbled over this topic again after reading it with great interest when it was opened and now the team has forked UITK-1 (for documenting purposes i think) so i thought maybe it is time to talk about it again?

As far as i have seen it (yes i was stalking your github stefano ;-P) stefano has already begun with the project here, if you are still interested Mitu, maybe you can participate in the effort? I would like to help but cannot do much except perhaps gather info and trying to bring people with skills together (qed ;-)).

I also don't know whether this is old news for you but Canonical seems to have been working on the UITK-2, based on QQC2, maybe there are some things there that can be recycled?

BR, erik

HI,

there are two posts that might be of interest for you:

• https://forums.ubports.com/topic/471/x86-x86_64-tablet-or-qemu-support
• https://forums.ubports.com/topic/514/simulating-a-ubports-16-04-on-x86-hardware-or-vm-work-in-progress

HOWEVER in short there is currently no ubports available for yor tablet. If you just want to play with Linux (especially Ubuntu) i would advice to go to http://linuxiumcomau.blogspot.de/ and download the "isorepsin.sh" make it executable (in terminal type chmod +x isorespin.sh) and then download Ubuntu 16.04 or KDE Neon 16.04 as *.iso and respin (in terminal ./isorespin.sh ) them with the newest kernel and the baytrail/cherrytrail/atom enhancements (You will know what i am talking about here when you try the script ;-)). If you choose Ubuntu 16.04 and want to test the Look and Feel that also Ubports uses or will use in the future, you have to follow the yunit install guide (https://yunit.io/yunit-packages-for-ubuntu-16-04-lts-xenial/). If you choose KDE Neon, you will have the KDE environment which has more or less the same base (Qt) bu takes a different approach to convergence.
For both expect issues with your Touchscreen and maybe additional hardware! Also you will currently not be able to use the touch-friendly apps from the openstore that are used on phones. All of this may change in the (hopefully) near future so stay tuned!
Hope this helps, BR
PS: if you use the respin tool, consider donating to Ian Morrison from Linuxium! (I am not him and in no way affiliated by the way ;-D)

• A feature to pin an object with symbol to the dash to be opened with standard program assigned to the object type
  (use case: ticket for public transportation is a picture so i want a symbol for it in the dash that immediately opens the galery with this ticket)

1. Sorry if this is a replicate from before: Do you plan to target Yunit for Xenial or Unity8
2. I tried building some UT apps on desktop (Ubuntu 16.04.3 server + Yunit repos + Stable Phone Overlay PPA) and wanted to report how this goes and what works since i thought UBports is targeting Yunit... Is this an attempt that can help this project or is this nonsense that i am doing?
3. Is there a decision for future package management or in other words; would it make sense to start a Click2Snap or Click2Whatever group? (I would be interested to work in/with such group even though i have hardly any coding skills)

Thanks for your hard work and best regards,
Erik

@3arn0wl if you try this, please tell us how it went (the good, the bad and the ugly) so we can file a bug report if necessary. However i have asked John Salatas from Yunit whether this should work on 32-bits or other Ubuntu derivatives than 17.04 and he thinks it should work so go ahead and try it. If i find my old laptop + some spare time i will try as well but don't wait for me, i'm having a todo list the size of a mountain ;-D

Hi @vadrian89: You filthy scum sorry had to do this because your post is so defensive ;-D I don't think it should be since your opinion is worthwhile. However i have watched the Q&A and seem to have understood it in a different way than you since no-one ever said they would not be open to include something like monetisation options in the OpenStore. Also if 16.04 is here, snaps will work (probably) and the Ubuntu (Canonical) Snap Store will shurely be open to 1.monetisation and 2. proprietary stuff so the OpenStore can stay just as it is for 100% Open and Free (as in Speech as well as in Beer) software. I have to say that i can understand both parties, the devs that say they want some money out of their time as well as users that like to pay no money for it. But i think claiming that these are the two perspectives at hand is wrong since the bigger problem in my view is, that there are very many people out there that can not pay any money for an app they use only a very few times and some may not even have the money to pay something for their regularly used apps. Making it pay-what-you-want would generate some income, especially in a community like ours while not excluding the poor people from the party. But as i said, i can also understand that devs want some revenue out of there work, however (i am not saying that the following is good but that it is the current situation IMHO) they may for now be wrong at UBports/OpenStore because 1. the userbase is just too little (a few thousand people perhaps?) 2. very many community members (1st contact team, testers, docu team, ...) are not paid either even if they deserve it 3. Those who would join for the money would be probably be disappointed in how many people actually buy the app if it's not free/pay-what-you-want and would then go out on the internet telling everyone what a shitty platform this is and how they would advise everyone to avoid it...

That's all i wanted to say about this, i hope you don't take it as a rant or something similar but as productive criticism of your arguments. As i said i fully support your statements that also FLOSS devs should be paid (fair)! I hope you don't feel attacked, if so please contact me to think about how to improve my arguing style so it is non-agressive!

@doniks sorry i didn't really have the time to work any further but i think i can at least respind

maybe I should give it a shot. I was a bit intimidated by the length and complexity of the instructions. do you think it would work on 17.10 on x86 hw? I guess the sdk and mir would be significant challenges.

I wouldn't really recommend following these instructions yet since it seems to be a path with some serious problems: 1. Using virtualisation for running clicks like the 15.04 armhf container will result in drastical performance loss from what i've read in the meantime and 2. the armhf virtualisation seems to break on a regular basis (qemu-static) and the length is because also failed attempts are included. This is only true for the container stuff above because a PPA with yunit/mir is in the works here so 17.10 should not be a problem. (it's however 64-bit AFAIK so no 32-bit yet)

mhhmm ... when you say Unity 7 + X11 you mean .... without mir .... so which UT apps run without mir .... maybe I'm not understanding you right.

I meant that i build some apps that are currently only packaged as clicks for the phone from source in an 16.04.3 x86_64 on unity7 atop X11 which you can read about in detail here and also a short overview which apps seem to work or at least start is being set up here (btw, sorry for the confusing docu style in that repos, at some day i will fuse all those documents which talk about the same stuff into one xD). As of yet i could successfully build and start OpenStore, Clock-App and InstantFX, but i have only tested starting, resizing windows and clicking one or two buttons which is my definition of "working" ;-P. I guess they work since they rely on Qt which also works on X11 not only on mir but i don't really know that stuff.

Ah one more thing; i tried building locally with Yunit installed and interestingly there seems to be a Problem with mir so i cannot start the OpenStore (the irony is somewhat bugging me). Haven't tried with another App, i will report as soon as there is more news.

@3arn0wl

"... to just compile..." how easy is that? What steps would I need to follow?

There is a guide what to do in the offical yunit repos, however the first line says something about "only working on 17.04" but that is no imminant problem since 17.04 is supported until January and available for 32-bit PCs here.

Lubuntu will release a 32-bit LTS version in April - could Yunit be compiled on that?

I am almost 100% sure that compiling on Lubuntu 18.04 will work but i don't know how hard it will be.

@mike thanks

@doniks thx for asking, studying is taking up most of my time but once in a while i have a few minutes to test a few things.

Regarding this topic: I have made little progress that is notable, however i could successfully compile and run a few UT apps on an 16.04 x86-64 system (whitout packaging them as clicks/snaps/debs) but have run into some trouble with mir when doing this with yunit installed (with Unity 7 + X11 it works very well). I have to work up the docs a little in here and maybe next weekend or so i can give you some more usefull info

@3arn0wl the problem is not that Yunit is not running on 32-bit hardware but that it is not packaged by the Yunit team (or any other team i know) so theoretically for you there is a possibility to just compile all packages inside the official Yunit deb repo for 16.04 but for 32-bit instead of 64-bit. (No coding work necessary, you just have to use the exact same sources and compile it on a PC near you)

About your tablet: i don't know whether Yunit will be a big improvement for speed since it has not seen many performance enhancements (AFAIK). Can you give more specific info about your device (Manufacturer, Name, ID)?

64-bit should be no problem for UBports (they/we even got a 64 and 32-bit servers so that both architectures are being build for by the native architecture) and in the end of the canonicel days they even said they will only focus on 64-bit (arm64 for ARM btw) which is why only BQ M10 and Meizu Pro 5 were supposed to receive Ubuntu 16.04

Hi,

how often have you tried installing? I had this issue once with my Nexus 4 and just had to do the installtion 2 or 3 times and then it worked.... As far as i remember, when it rebooted to recovery, in the terminal that you started the flashing it should say something about writing stuff it downloaded before...

Also maybe try a second USB cable and don't move your Laptop/Phone while the whole process. I've heard of a few people with problems because of faulty cables...

Btw, you can do the following: If you only reach the Ubports Recovery, you just do the flash command without the --bootstrap and it should work from there. So assuming you are in recovery and have the cable plugged in an d the terminal open run

sudo ubuntu-device-flash --server=http://system-image.ubports.com touch --device=mako \
--channel=15.04/devel

Ah and one last thin; don't get worried the process will be

1. White background with 3 orange dots
2. Black Background with Google Logo
3. Orange Background with Ubuntu Touch slogan
   and all of them will seem to take for ever

Best of luck to you for the next time you try

@guru KDEconnect is an extremely cool app to bridge all your devices. Here is the github repo and KDE community wiki entry. In just a few words:

1. Link your PCs, Smartphones, Laptops via Wifi or Bluetooth
2. Share content (send files, share clipboard) encrypted and with nautilus (filemanager) support
3. Some nifty features for the smartphone:
   • Find my phone (click on desktop and phone will ring)
   • See notifcations, take calls, answer on messager on desktop
   • Send CLI commands/touchscreen/keyboard events to desktop
   • See phone status (battery) on desktop

Sorry for redundancy, Stefan already mentioned a few of these, i'm just a big fan of this app and would love to see it on UT

@GeekyGirl36 i am glad to help sorry for my delayed response, it sometimes takes a while for me to get some spare time for everything...

I think if you test doing this on your own is a very good idea. To set up a virtual Ubuntu you can follow this guide for example. This is generally something i can only recommend because you can, after setting up VirtualBox, download images from various flavours and see which desktop experience fits your needs the most. (if you have time i would recommend "vanilla" Ubuntu 16.04.3 which comes with unity 7, KDE Neon 16.04 for the KDE experience and maybe also Ubuntu 17.10 which uses GNOME by default as well as testing the vanilla 16.04 with the Yunit desktop installed to get the Ubports feeling) You can delete every Virtual machine(VM) after trying out a little and just create a new one for each distro so you don't get the "frankenstein" experience ;-P.

If you then decide on one of these, you can set up a new Virtual Ubuntu, copy your image and the isorespin script into shared space with that VM, chmod the script and execute it. Then burn your image to a thumbdrive (for example using https://etcher.io/) and install the Ubuntu flavour of your choice on your tablet/laptop.

@GeekyGirl36 I am no expert either but let's see if we can make this work. (i only use Ubuntu based distros on a daily basis so i have no experience with using this tool on other OSes) I know the linuxium Blog is a little bit confusing and to find the info you need is a lot harder than in any wiki so this is the page that describes the rationale behind the script and how to use it: http://linuxiumcomau.blogspot.de/2017/06/customizing-ubuntu-isos-documentation.html

On that page it says "Although it is expected to run the script on a Linux machine it also works on a Linux virtual machine on Windows". Whether Linux machine is meaning Ubuntu i cannot say, however i would recommend running a virtual machine with Ubuntu 16.04 or 17.04 and doing the respinning inside. (In the comments someone used the script on DeepinOS which is Debian based and had to do a little workaround to get it working so using a Virtual Ubuntu sounds like the least troublesome option....) You

Which OS are you working on? Perhaps i am bridleing the horse from it's back here (is this a proverb in english too?) and we should start from your point of view and not me throwing links and bits of advice at you ;-D

And how did you try opening the script?

Ah and last but not least, what do you mean by "downloading the Atom iso"?

HI,

there are two posts that might be of interest for you:

• https://forums.ubports.com/topic/471/x86-x86_64-tablet-or-qemu-support
• https://forums.ubports.com/topic/514/simulating-a-ubports-16-04-on-x86-hardware-or-vm-work-in-progress

HOWEVER in short there is currently no ubports available for yor tablet. If you just want to play with Linux (especially Ubuntu) i would advice to go to http://linuxiumcomau.blogspot.de/ and download the "isorepsin.sh" make it executable (in terminal type chmod +x isorespin.sh) and then download Ubuntu 16.04 or KDE Neon 16.04 as *.iso and respin (in terminal ./isorespin.sh ) them with the newest kernel and the baytrail/cherrytrail/atom enhancements (You will know what i am talking about here when you try the script ;-)). If you choose Ubuntu 16.04 and want to test the Look and Feel that also Ubports uses or will use in the future, you have to follow the yunit install guide (https://yunit.io/yunit-packages-for-ubuntu-16-04-lts-xenial/). If you choose KDE Neon, you will have the KDE environment which has more or less the same base (Qt) bu takes a different approach to convergence.
For both expect issues with your Touchscreen and maybe additional hardware! Also you will currently not be able to use the touch-friendly apps from the openstore that are used on phones. All of this may change in the (hopefully) near future so stay tuned!
Hope this helps, BR
PS: if you use the respin tool, consider donating to Ian Morrison from Linuxium! (I am not him and in no way affiliated by the way ;-D)