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

@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

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?

Ok, found it out, was indeed an R not an A, that really is some poor font there.

The problem was solved by booting back into the original image and enabling "non OEM" images in the developer mode settings which you only see after tabbing 7 times onto the os version number somewhere in the settings (seriously, wtf). Now I can successfully flash my own images on it.

Thanks for pointing me into the right direction

Ok, so I currently use one of the BQ Aquaris E5 devices still with the Ubuntu image as my main mobile device, and it is starting to really really go on my nerves. And I guess that would not change if I reflash with UBports as the main problem seams to be the hardware which has even serious issues handling the sqlite file for the message app...

So I have this Samsung S7 lying around here with some horrible firmware of some local provider which looks like an store front O.O. I got that for almost free from the carrier and the plan was to use it for a project for a few months and that is now done and over and I have the device to do something else, like porting UBports to it.

I have never done something like this before and my first Idea was to get a feeling how you flash the device and get some already working custom rom onto the device. I tried a Lineage OS rom and I'm already stuck pretty early because "download mode" refuses to accept the rom because of "Blocked by FAP lock".

So I tried to google it and fucking hell... it is completely impossible to find any useful information about the issue with a search engine, or I don't have the correct search term to look after the actual problem. I just get a lot of noise about computer voodoo and no actual answers.

So hopefully someone here can point me into the right direction. What am I actually dealing with? I this some kind of hardware lock or is it part of the download firmware? Is there any documentation anywhere about stuff like this?

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

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

As I understand it, it will run every Linux Distro since they mainline all the drivers. So it should run Ubuntu out of the box.

But this will be a pure GNU/Linux phone, so no libhybris or halium etc needed. The question is does UBports actually work with normal Linux devices with regular Linux drivers or does it only works with libhybris?

So I don't seam to be able to contact any of the OpenStore guys. I released the click package on Github for now:
https://github.com/ZeroPointEnergy/syncthing-click/releases/tag/v0.14.31

If someone can point someone from the OpenStore guys to this thread, that would be appreciated.

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?

@doniks Thx for the info. Will join the irc channel then

Not sure if that mail even reached their mailing list since it seams to be private and I'm not sure I'm even able to post in there if I'm not a member. Does anyone know if it is ok or even possible to just add a unconfined app to the store or what the proper channels are? (Other than telegram, seriously, I don't want to join yet another of those messenger thingies).

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.

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

Looks awesome, great job!

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

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

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.

@wgarcia I think they are even open source or am I missing something? https://github.com/bq/aquaris-E5 because Linux is under the GPL and not publishing the drivers while selling the binaries would be a violation of the license terms.

I'm not sure if this is true for all the devices and all the drivers. Maybe they have a way around that like nvidia. Does anyone know more about this?

But I think even with the sources it would be a lot of work to adapt the drivers to a newer kernel version. It is a shame that all this is not just committed upstream so that newer versions of the kernel would automatically support the device like it is the case with PC hardware.

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.