I completely agree with @NeoTheThird, I think his post is absolutely spot on.

This discussion reminds me of the wine discussions on the desktop. The reality is that people will make it work, because they have a desire to run all the software need on this phone without having to rely on a secondary device just for the odd android app.

On the desktop wine allowed me to completely ditch windows and still play games for years before steam opened their doors on Linux. I think with android we have a similar situation. The goal is to free your phone and turn it from a jailed toy into a general purpose computing device which respects the freedom of the user to run whatever he likes. It is probably not a good idea to replace apple or google just with some other guy who dictates what you can and can not do on the device you purchased.

I think the real question is if this should be a core-app. My personal opinion if I may, is that this should not be a core app and that this should always be optional as an app in the openstore. This way the purist can run his pure system and stay completely away from anything android and the pragmatist can ditch android and use ubports as his daily device while still enabled to run the odd android app he may need.

@doniks Yeah I already did that. They use a script with vmdebootstrap to build a debian , which is similar to the way the ubuntu-touch image is built. It should probably be possible to modify that script to build ubuntu-touch.

Image build script: https://source.puri.sm/Librem5/image-builder
Flash scripts: https://source.puri.sm/Librem5/librem5-devkit-tools/

The images are a bit different and have the kernel on the image itself and a boot sector from what I can tell.

I currently struggle more with figuring out how the ubuntu-touch image is built. I know the rootstock-ng is used, but I'm not sure what parameters are used on the Jenkins.

@UniSuperBox is there somewhere a list of repositories and packages (meta package or a list?) that are used to build the image? I already asked in the UBports_porting channel but got no answer so far.

@Flohack I think the important point with the baseband is that they will separate it so it does not have memory access. Baseband is seriously flawed and no amount of free firmware will ever fix that. The way purism tries to approach that problem is the separation, hardware kill-switches and ip first communication via matrix so you don't actually need the baseband if you have wifi.

They try to create a true general purpose computing device with a smartphone form factor like the laptops and pc we know. I think they are completely on the right track and that is why I already backed the campaign for a phone and the dev kit.

I really like the clean interface Ubuntu Touch offers and I'm sure there will be a way to use it on this device. I sure will try if the funding succeeds and once I get the dev kit.

So I tried to get myself a bit familiar with the packaging stuff and thought it would be a good idea to create a useful package in the process. Syncthing can sync folders between devices without the need for a cloud provider. If you are interested in testing the build script can be found here: https://github.com/ZeroPointEnergy/syncthing-click

IIRC this tool was already in the ubuntu store for a while but confined and not really useful because of that. I sent a mail to the open store mailing list for inclusion.

Hello

I have some librem5 dev-kit lying around here and maybe finally I can make some time to actually play with it. So far I just installed their Pure OS image and it isn't super overwhelming.

Has anyone in the UBports community already started with looking at a port? If not I will probably have to start from scratch. As far as I know there isn't a native device port yet or is there something similar?

Hello, my name is Andreas, I'm from Switzerland and currently use a Aquaris E5 as my mobile device. I use Linux exclusively on my Desktop for almost 17 years now (last Windows was 98 or something), mainly Gentoo for about 13 years. I'm working as a Linux systems engineer, for over 10 years now and have a lot of experience with systems automation with puppet and various other tools. So free software is basically my life

I had various linux smartphones over the years, starting with the original neo1973 from openmoko, which could barely make phone calls, which was around the time the first iphone and android devices launched. Then on to n900, Jolla and after that one died I tried an Ubuntu Touch device and using it since.

I just started to look into how one would package an application for the openstore and trying to get that working on my system. I really like how the UBports project has an enthusiastic drive and I am looking forward to see more of you all and hopefully I can contribute some stuff on my own.

It is not that simple. Android apps are written in Java against a completely different API. To port such an app to QT means a complete rewrite of the app. From what I understand, the idea of Anbox is to simply provide this APIs and the dalvik jvm in a chroot/container. All free software, it just allows you to run apps written for the Android userland on a system with a regular GNU userland.

This has all absolutely nothing to do with the problem of proprietary software. In fact there where quite a few proprietary apps in the Ubuntu store which where native apps running in the GNU userland.

The important thing here is that the OS is all free software and that the choice to give up your freedom by using proprietary software is one the user can make because he has this freedom which comes with the full control over his device in the first place. This is true with and without Anbox.

Now I recognise that the possibility to run Android apps will increase the probability that users run proprietary software on UT simply because it makes them available to the user. But they would run it anyway if they really need it but probably on a OS which does not respect the freedom of the user and may spy on you. So if they run it on UT instead of a stock Android full of proprietary spyware they at least gain control over the device they own.

For the people who want to stick to free software only, Anbox opens access to a lot more free software than they would have on UT with native apps only. This could make a big difference to make UT a viable choice as a device for them.

I also don't think this will in any way discourage people from writing native apps. The true power of UT is that it has a full GNU userland with all the tools people are used to from the desktop. But from what I see there has to be a lot of work to be done to make developing native apps viable for mere mortals again.

Sorry for the wall of text

@UniSuperBox Oh snap

@trainailleur Good points. Once I figured out how to create an ubuntu-touch image that at least boots I will definitely look at what's there for the PinePhone.

@Giiba Thanks

Also one should remember that not all Android apps are proprietary. There is in fact a huge amount of free software available as Android apps, as well as all the bits and pieces used to run those apps are all free software. So I don't think the point of relating Anbox to proprietary and non-free software is in any way valid.

@WLBI said in How to make a port?:

The thing is, that ARM CPU don't have hardware detection, so the operating system must be build exactly for only this specific device. It will not run on any other device.
That's why it's that hard, porting to different devices.

Very interesting, do you have some more info or pointers about why that limitation exists? I always thought it would be possible (but maybe very difficult) to rebase the kernel drivers from the device specific sources on a newer common kernel and use linux auto detection to discover which modules to load.

Looking forward to the update. This project is very exciting, thank you so much for all your hard work.

Here are a few questions

I think last time it was mentioned that click will stay for the foreseeable future since there are some missing features in snap. Looking at the click project on Launchpad this seams pretty unmaintained. Are there already plans how to tackle this problems and what is the way forward? Fork click? Fix snap? Are other solutions like flatpack considered or are they not an option?

Regarding app development, I'm not sure if I understand this correctly, but if you currently want to create an app you need some QT fork which supports Mir or can I just run any X11/Wayland application? If not, will this change in the future with everything moving towards Wayland?

Very interesting, I was not aware of that restriction. Thanks both of you for the explanations.

Looks like Plasma Mobile is now onboard with the project:
https://www.kde.org/announcements/kde-purism-librem5.php