I get this question a lot, why focus on making Lomiri compatible with upstream components and why are you helping getting Lomiri into different distros? Why not focus on Ubuntu Touch? Why focus on making UbuntuTouch better? Why not make device X better right now!

And for many this choice of development direction might sound weird, and I get that, it's hard to know this if you’re not a developer working on these components. So i’ll try to explain why this is the best way for us to keep going.

The fact is that, focus on making Lomiri compatible with upstream components and making it possible for Lomiri to enter more distros will make Ubuntu Touch better, and much much better in the long run. This is a long term plan to make the Lomiri stack much better.

Doing upstream work greatly improves the support to all the components we heavenly depend on, so for us to upgrade our stack (like Bluez, NetworkManager, ofono and MANY others) we really need to make our source both buildable, usable and comparable with upstream non ubuntu patched components, as we cant maintain components like canonical did, so we really need to depend on upstream fixes. and to be honest this is better then what canonical did, as you can see what state we are in due to that. A great example is bluez, we are way behind upstream here, this is mostly due to the xenial base that again is due to our stack depending on xenial specific patches that makes it impossible to just upgrade base or even bluez without doing heavy porting.

Yes there will be a period where fixes for devices won't be prioritized, but for us to fix those now and later need to fix them all over again because we just made our own little fork is a sure death for us. We need to make a sustainable road head of us and not keep working on our little buble. This has been an issue with ubuntu touch from the beginning, it was only canonical doing the work with no outside contributors, this is something we really want to avoid. We need to make Lomiri a Linux desktop environment not only a Ubuntu Touch one.

Yes devices will be prioritized, but we need to follow upstream and get up to speed with all the great fixes we simply can't use.

Once this work is done, we don't need to worry about it anymore, as keeping up with upstream will be so much easier. Most of the work is to replace the ubuntu only patches that really do not solve anything other than making it much harder for us to upgrade our base to for example 20.04 or even pull in never fixes that will fix many of our issues.

But most important of all, when we are fully compatible, we will get more distro supported, this in turn will have many more developers looking and trying out Lomiri. This will greatly improve the system as we will get more contributions! An example for this is Luca from pmOS, he has done amazing work that we all enjoy today. And we need more developers like Luca to make Lomiri more awesome! We need to get out of our little Ubuntu Touch bubble and work with the huge Linux community, this will make Ubuntu Touch SHINE

Hi all,

I'd like to start posting weekly development updates here on the forums - this is a bit of an experiment, so please let me know if you find these updates useful and what could be improved. The goal is to provide a high-level overview of our development progress.

This past week focused heavily on Noble development, with rapid changes to the image. I'm pleased to report that the latest daily build should have all hardware features working, including GPS, calling, sound, fingerprint reader, NFC, and more. We've also fixed several indicator bugs, making the 24.04 base system quite usable.

Currently, we're missing 24.04 built clicks, which is why some core apps aren't starting yet. While most of them build and run fine, we're waiting for some clickable changes to enable compilation. There are also some pending tasks related to accounts and push services, plus likely a few bugs to address.

Please test out 24.04 and report any bugs you find! Your feedback helps us improve the system.

Hi everyone,

After a brief delay caused by some medical issues on my part, I'm excited to announce that I’ve successfully developed a fully functional VoLTE implementation for Qualcomm devices. I've been using the Fairphone 5 (FP5) as my testing platform, and everything is now up and running.

I do however request some help with testing, anyone wanting to help out with that?

Hello everyone! Here is my personal points for a "perfect personal phone operative system". And I want to hear what your points is, Please let me know

The main points for "a perfect personal phone operative system" in my eyes, is Convergence, Open source, freedom, developer friendly and secure.

And the biggest one for me is freedom, where I don't get tracked everywhere I go, google knows where I am every second, and I have to ask me is this acceptable?... I really want to get out of Android, but the only thing that i'm missing is some apps. When we get anbox working right, I will fully switch. but I really hate the google tracking ting... I don't know why I have allowed it to go as far as it has now, but it kinda have been like that due to convenient.

Convergence, a phone I can connect to a monitor, mouse and keyboard and have a full desktop in front of me

Developer friendly, A phone where I can hack on how I want, a phone I can install the apps I want and a phone where I can explore what I want.

Secure, A phone I can trust can keep my personal data safe.

Open souce, A phone I can modify, contribute and hack on.

Thank you!

Hey,

So, I have done the "heavy lifting" so far, but there are still some work needed. Like getting wifi and bluetooth to work (I suspect just adding firmware will help, see example for pine: https://gitlab.com/ubports/core/rootfs-builder-debos/blob/master/pine64-common.yaml#L15). On the graphical side of things, there is still a host of bugs using the wayland session, but this will be worked on in parallel with pinephone and librem5, so this is not a raspberry specific issue. In short, when it gets fixed on pine it gets fixed on rpi too

The build "scripts" can be found here: https://gitlab.com/ubports/core/rootfs-builder-debos/blob/master/raspberrypi.yaml please send pr's here to improve the images.

Images will be built daily by the ci, they can be found here: https://ci.ubports.com/job/rootfs/job/rootfs-rpi/. flashing is really easy using etcher (https://www.balena.io/etcher/) to flash the sdcard.

This has been tested on rpi3, but should work on anything newer then 3 (as it needs arm64)

Some bugs that i saw:

• Won't start without keyboard or mouse connected
• Once unity8 has started, you need to reconnect the mouse/keyboard to make it work
• Performance using the opensource mesa drivers is still not "great"
• Needs swap
• A host of wayland session bugs

Hey,

As you may or may not have seen, i have been a bit offline last week. This was due to one of my close family member got into hospital with an serious infection, it was so bad that he got picked up by the ambulance. And since I'm living in the same house and is really close to this person, this has not been an easy week for me. This is the reason why i have been gone, but with all this said, hes now back home and in much better shape, he is still recovering but overall doing fine. and I'm slowly getting back to everything.

Thanks everyone!

Little the same as i wrote on github https://github.com/ubports/ubuntu-touch/issues/860,

Also please understand, we are a small team with a huge task, we have many moving parts and moving to a newer version of mir and unity8 at the same time is not helping, we are doing our best to make an an awesome operative system. but we are in a really busy period after taking over from canonical, we updated to xenial, we are updating mir and updating unity8 all these are huge since canonical left it all the current version far behind the latest releases, this forces us to make major changes. We are also building Halium and following the evolving of android and newer devices to be able to follow the mobile marked. At halium we are also trying to move our sensor, gps, media and camera system over to an active maintained system instead of maintaining our own. And we are also looking at merging our patched in celluar and pulse with an active maintained one. Once we move things to active maintained systems where we can work together to get to the same goal, we will then get more time to focuses on core functions.

About replacing the browser, this is an huge part for us, we are not able to maintain our own fork of chromium (oxide) that why we are forced to move the browser, this move will in fact give more time to focused on the core functions on the phone.

We are moving to newer version of pretty much every part of the system, this is a major work. Once we have done the major upgrade we will get a lot more time. And in fact we are really close go get to this point, we now are super close to finish all the mir/unity8/libhybris upgrades. And we don't have a big enough team to focus on all the bugs right now as the code may have merge errors to be able to merge with never version and to risk spending lots of time on bugs that might be fixed in newer version. that's why we are upgrading, getting our source aligned with newer sources to then focus on fixing and improving.

In fact most of these bugs comes from the canonical days, they was a much bigger team then we are right now, so we don't work at the same speed.

We are doing our best with the small team we have.

OTA 8 will include new mir and unity8 (and many other updated parts), we hope these have many of these issues fixed, but we have to expect some bugs to be included also since the upgrade is so major.

Thanks for understanding

Hello everyone!

The expected release date for Ubuntu Touch OTA-13 is Friday, Sep 4 Wednesday, September 9 Monday, September 21.

This forum post is a companion to the upcoming OTA-13 call for testing blog post.

Please post any general observations you have while testing the current image in the rc channel, as compared to OTA-12, in this thread. The current release candidate (rc) is 2020-W37

If you have any comments on any of the specific issues in the OTA-13 tracker, please post them in the issue thread so they are easier to track. OTA-13 tracker: https://github.com/orgs/ubports/projects/17

Please note that only critical and security fixes will be able to enter OTA-13 as this point, normal bug fixes and new features will need to wait for our next release. Please do not discuss normal bug fixes and new features here.

A big thank you to everyone that made this possible! I'm super happy to see these release being bigger and bigger with contribution from so many beautiful people! Thank you everyone!

• Much love!

Edit 2: On the 7th of September the release date for OTA-13 was moved from the 9th of September to the 16th of September

Edit 3: On the 15th of September the release date of OTA-13 was moved from the 16th of September to the 21st of September.

This category is only for ongoing ports, any other post will be remove or moved.

How the ports should look like
Title: "Device name (codename)"

Posts here needs to include the current status of the device, sources and how to install the device. Try to structure the post to be easy to get the information. Also add some info on how to help or contribute to improve the device.

Example:
Title: "Oneplus one (bacon)"

Port for Oneplus one,

Sources:
Kernel: link to kernel
Device: link to device configs
Halium: Link to halium-devices manifest

Status:

• Wifi: works
• ....

Install:
How to install

Hi,

This will just be a quick "how-to" upgrade your apps to 16.04

So, first off you need to update your manifest, here you need to set framework to ubuntu-sdk-16.04

Next and important step (without this your app will fail to install), you need to update your .apparmor file, here you need to set policy_version to 16.04

Here is an git diff how i did this on the ubports app:

diff --git a/com.ubuntu.ubports.apparmor b/com.ubuntu.ubports.apparmor
index 06ff04c..5f9e005 100644
--- a/com.ubuntu.ubports.apparmor
+++ b/com.ubuntu.ubports.apparmor
@@ -7,5 +7,5 @@
         "location",
         "content_exchange"
     ],

-    "policy_version": 1.3
+    "policy_version": 16.04
 }
diff --git a/manifest.json.in b/manifest.json.in
index 10c8bc7..8af6c2d 100644
--- a/manifest.json.in
+++ b/manifest.json.in
@@ -10,5 +10,5 @@
     },
     "version": "1.6",
     "maintainer": "UBports <jan@ubports.com>",
-    "framework" : "ubuntu-sdk-15.04.6"
+    "framework" : "ubuntu-sdk-16.04"
 }

Finally build for 16.04 using clickable

clickable -k 16.04

That's it, your app should work in 16.04

Hello guys!

This is will just be a quick development update.

So the last ~2 weeks the development has been really slow, this is due to me having some personal issues i had to take care of that had be unable to do anything. So that is why it has been kinda quiet from both me and development on my side.

But don't worry, i'm somewhat back now and will hopefully be fully back in ~1 week

Xenial (phone) is still in the scope, I was expecting to be done with all the backlog bugs and most of the ota-4, but i was also expecting to have the first xenial rc landed, but due to my issues I have not been able to complete this.

Unity8 is still in the scope, but has a lower priority then xenial (phone). Unity8 is somewhat broken on bionic due to Ubuntu (upstream) have removed the mir patch from mesa, this means none of the apps will work. We have to change this to using the wayland protocol for all the apps. But on top of this mir has bumped the abi/api version for miral so we have do some some work to get things building again. We will hopefully get this working quickly! (at least before bionic release :))

We also want to make a architecture overview of Ubuntu touch including sources and build instructions for the different parts that powers Ubuntu touch. This will both be nice for Developer and Users alike. Please contact if you want to help out with making this

And lastly,
I want to do a call our for help with development, If there is any of the areas you want to work on/help with please don't hesitate to contact me if you need help getting started.

Thanks you!
You guys rock!

The reason why you got banned is because you was rude to other people on the forum, THIS IS NOT IN ANY WAY ACCEPTED BEHAVIOR, you got an warning for this. Even though you got an warning you got into a discussion with one of the admins in which you there proceeded to be straight up rude to the admin, this resulted in a BAN. END OF DISCUSSION!

Call now do work on the latest release
also camera is somewhat working on arm64.

And you can now install it with the installer

One point i want to add, is that we might want to remove the "Ubuntu logo" since for this exact reason we are limited. Things that we want to include yumi on might be approved each time, like if we want to have it on the pinephone for example. We also want to move into debian and other distros, so a removal of the logo would be a good move in my opinion.

Yumi itself can be used by anyone, that was one of the main point when it was made, but i see now adding the ubuntu logo was a mistake.

@doniks Yes there will be a transition phase, we wont "just remove" oxide The phase time really depends if and how many apps it breaks, since we keep Ubuntu.Web we really hope the transition would be minimal.

What i meant with 100% QtWebEngine is that every part that is "pre-installed" like browser, web container etc would be moved over, not that we would remove oxide.

Ubuntu.Web will still exist and will not go anywhere, It will still be based on oxide until oxide is removed, once oxide is removed it will be moved over to QtWebEngine so it will continue to work (unless it uses oxide only apis)

The oxide api will be removed at some point, when is still unsure. We would need to go over and see how many apps use this raw, and how many apps will break as an result of this. We will also try our best to create a compat layer to be able to make the transition without breaking apps (like webapps+)

So i have good news here! So after last thing got pushed for OTA4, i got more time to work on this, and I got some progress! after merging upstream and some more hacking I have got it working on qcom devices! It will still take time to be something usable for daily use, but i will push some test images this week. After OTA4 is out we will put more work into making anbox smooth and ready for daily driving.

@Jackl said in PinePhone:

2 Being a privacy oriented phone, it would be cool a physical switch to turn off the module, and maybe the cameras, microphone. I dont trust very much the module stand-by state.

It will have physical switched for all those

@Jackl said in PinePhone:

• 3 The display manager should be i3 or lxde (kde or gnome would be f00l(no offence ubports)) and the OS arch or debian. All the always-running apps should be gtk2.

gtk on phones is a bad idea. It's not designed for low end hardware nor is it designed to work on a phone form factor. Why do you want gtk?
Qt has superior performance on embedded, ARM based devices. Also LXDE is moving to LXQT which is qt based.

UBports does not use kde or gnome, we use unity8 that's crafted specifically to work on phones and desktop alike, based on qt.

i3 would be hard to use? no keyboard?

But you can run whatever you want there is debian builds already for it, and i know other project are working on it as well, like arch, plasma mobile, etc.

@Jackl said in PinePhone:

4 I hope that the pinephone 2 will use a mediatek or qualcomm soc. Not a surprise a battery of 3000 mAh.

It will use the allwinner a64

Hi all,

So since we are all stuck at home, me and Alfred had a thought, lets create a online hacking group where we can get together have a good time and just hack on Ubuntu touch. there is no topic but we want to float around with porting and focal hacking. We will start 17.04.2021 17 UTC and carry as long as we want.

We will be over at https://whereby.com/ubports-chat

Hello everyone!

So, with the resent news about Microsoft buying Github https://www.theverge.com/2018/6/3/17422752/microsoft-github-acquisition-rumors the question have been raised to me if we should move to Gitlab. We will for sure talk about this in our Developer meeting today, so I decided to post this to see what the community things before making a decision. This has to be an Developer decision, but at the same time we do bug reporting on Github too so community input is extremely important. So please give your input on if we should move or not.

To move to Gitlab will have no major drawbacks, we will only gain extra functions like direct CI on Gitlab. Gitlab has all the existing functions we use on Github. Gitlab is even opensource which is a big plus! (github is not opensource) Importing will also be no extra job, Gitlab has already automated tools to import everything from Github (issues, pr, wiki, repos etc). And for infrastructure using Gitlab is no problem plugins etc for Gitlab already exists (https://jenkins.io/doc/pipeline/steps/gitlab-plugin/) So from my side there is no reason to not use Gitlab.

vote here: http://www.strawpoll.me/15829621

I myself strongly dislike this, and do not trust Microsoft, so I have moved all my personal things to gitlab! Also the irony asking someone to create a bug report for our project on a Microsoft platform is weird.

This look really nice but it look little too much like google play. But i would love to see a similar design but using more suru design instead of material.