Possibility of basing on ubuntu core?

extraymond

Re: How could Snappy Ubuntu Core be interesting for us?

This is a flashback on the original comment above.

Upon reading the recent news about ubuntu core for desktop use cases. https://ubuntu.com/blog/ubuntu-core-an-immutable-linux-desktop
I'm wondering if it's beneficial for the ubport project to do something similar? As a long time fan of the whole ubuntu touch project, I think once canonical dropped support, ubport has been taking a super huge responsibility to not only make things work, improve it when it's needed, but also to maintain the packages and transitioned it when matured. I think this huge responsibility kinda sucks the ubport team's energy from more interested features they want to invest.

I'm wondering if it's possible to build a POC of ubports that are:

port hallium into gadget/kernel snap
core20 or 22 base snap
ubport shell as a snap, provides snap slots so other app(snap) can consume it if permitted by the user
install an snap that consumes one of the slots from ubport shell snap

arubislander

@extraymond Don't you think this POC would also "suck the ubport team's energy from more interesting features they want to invest."?

extraymond

@arubislander

To be honest I don't think it should be and It would be.
For example, I have some experience running and building snaps, it's definitely something I'm pleasantly doing.
If we can utilize the userbase of snap packagers to help the ubport team, and take some of the maintenance burden from their shoulder, it might be a healthy thing for the project from my perspective. This might provide a new angle to attract more contributors to the project after all.

All in all, the point of this post is kinda reach out to someone more experience than I am, and see if someone had already tried similar stuff like the original comment above. Maybe it's not as hard as I think it would be.

alan_g

@extraymond I'd love to see this happen, but are you volunteering to work on it? Or hoping someone else does?

I've some knowledge of both Ubuntu Touch and Snaps and am willing to advise.

For anyone interested, the POC described would be a huge amount of work. Probably less than the 20.04 transition but certainly more than a few months:

Ubuntu Touch uses a custom kernel for each phone so a kernel snap would need to be maintained for each phone. I also suspect that work would be needed to have hallium "play nice" with snapd.
Anyone tackling this has a huge learning curve to surmount: You likely have as much knowledge as anyone else here about getting hallium working in a kernel snap
The base doesn't really matter for this, but I'd suggest core20 to match the 20.04 base of other UBports projects
Lomiri (the shell used by the project) is not designed to work with snap confinement, so this would involve more than "just packaging".
And "just packaging" as a snap isn't trivial for shells - I speak as one that has done it! (See below)
The only snap interface between Lomiri and "an snap" would have to be wayland (There is no Snap interface for the legacy mirclient-based IPC).
The client bit is simple, there are loads of snaps available that consume the wayland slot. However, work on transitioning Lomiri to Wayland is incomplete (it has been in progress for several years)

If you're on Ubuntu desktop, you can experiment with a couple of relevant snaps of another Mir based shell (Miriway) that I've packaged: you can install both of these on your system:

confined-shell is a strictly confined snap which is what is needed to install on Ubuntu Core; and,
miriway an unconfined snap that doesn't have to deal with the limitations imposed by strict confinement

Probably the most tractable part of this POC would be to package Lomiri as a snap. This could also be useful for Lomiri's desktop ambitions. You could get an idea of what's involved by starting with a "classic" snap modelled on miriway.

extraymond

@alan_g

Thanks for the reply! These are tremendously helpful feedback.

While kernel/gadget/hallium is a bit out of my league now, I'm playing a bit naive here and see if I can get some of the points you mentioned into some subtasks that I'm able to tackle on my own.

About the kernel/gadget part, if the POC just targeted building on one device, would something like pixel3a or failrphone4 be straight forward enough? Unfortunately without c/c++ knowledge(rust/python for me), I think the most I can do is map the various shell script into the build yaml and see what's next. Another approach I think I might try is to use the rpi4 which has ubuntu core support and try something on top of it.

The lomiri transition to wayland seems like a high priority before any of my vague assumption can happen.

I think two option I might be able to try is either:

run lomiri as it is on mir which I assume is possible with ubuntu core
learn about confined-shell and mirway and see if I can get lomiri running as a standalone snap on a ubuntu core device.

alan_g

@extraymond said in Possibility of basing on ubuntu core?:

run lomiri as it is on mir which I assume is possible with ubuntu core

If by "on mir" you mean using the mirclient IPC, then no. That won't work on Ubuntu Core.

Helpfully , that leaves you with just one option:

learn about confined-shell and mirway and see if I can get lomiri running as a standalone snap on a ubuntu core device.

Here's the code for these:

https://github.com/MirServer/confined-shell-wip
https://github.com/Miriway/Miriway

extraymond

@alan_g

Hehe got it! Thx for everything. I'm going to learn those two for now.