Little update on my side and the future focus of bringing Snaps to Ubuntu Touch, the idea has changed a bit, or narrowed down to a certain degree.
We might vendor in snapd .deb packaging into UBports repos as the CI and experimentation area (with preference on not re-execing snapd from it’s snapped up updated package) for now, with custom patches applied on top to provide libhybris enablement and other compatibility changes to adapt all the DBus API namespace changes we went through between the unity8 and related interfaces, etc. Probably many more things that cannot be listed easily beforehand that would break somewhere somehow, but we need a clear path forward in this multi-disciplinary effort.
GTK4 apps currently expose an issue where RGBA gets color-swapped with the GLES renderer enabled when fullscreening an app, and the chance of it being a GTK4 issue (has worked on Qt and SDL from the get-go) is pretty high.
Otherwise, Workshops as a Flutter example works in a Desktop mode scenario. Touch-only Flutter apps would not since they don’t summon the On-Screen Keyboard yet when a text area is tapped.
For many common CLI usecases LXD went pretty well when running privileged containers (user-level containers aren’t working at the moment), also Docker failed to install properly due to AppArmor incompatibilities, which adds another reason to patching up snapd itself reasonably soon for it to work on Touch.
These are the latest gatherings of enabling Snaps on Ubuntu Touch. A bit of a possibility of coordinating that with core upstream needs in the long run would be good too.
Another round of updates here in Ubuntu Touch Snap enablement land!
Since focal OTA-3 released with preliminary Snap support (which still requires rw-mounting the rootfs and installing snapd by hand), there has been some further movement with regards to making Snaps work well on Touch.
Not only do the patches enabling snap-confine to use driver blobs (from the device vendor’s Halium side) provide GLES now with the Flutter-based Snap Store, it also neatly integrates with a freshly ported over Polkit agent on the desktop environment side of things.
Here we have the new Ubuntu Snap Store running neatly with the Lomiri (ex-Unity8) desktop, asking for the user’s permission to install an app from the store.
Another one is teaching snapd to respect the hybrid rootfs layout (classic-but-readonly rootfs with selective writable paths, locked down /etc/{passwd,groups} as a thing between Classic and Core) and treat creation of users/groups for those Snaps the “extrausers” way inside of snapd by introducing a OnTouch boolean next to OnClassic, the WSL and the Core Desktop based ones.
This allows to pull Cups directly from the Store without installation failing anymore. The last obvious missing pieces are Snaps with DBus services inside which attempt to create files in the currently-still-readonly /etc/dbus-1 paths as well as docker-support generating a conflicting AppArmor profile on old device kernels which I have reported on Launchpad already.
@beidl it was really great that @rs2009 (thanks a lot, Rudra, without you I probably had not done a trip to the AW building) has brought me to the UBPorts booth on the FOSDEM 2024 and you told me about your success with the CUPS Snap (and the use of Snap in general). Also thanks for a lot for our chat at the booth.
I have googled for the subject matter now and have found this thread.
You told me in our chat (and also it got told on Q&A episode 131, at least according to its summary) that it requires to “set a path for it in System settings” to make it work.
Could you tell what you have exactly done, perhaps in a new thread, so that I know whether I can make the CUPS Snap work better with Ubuntu Touch by doing one or another change (but only with some if (system == "Ubuntu Touch") ...). But ideally, I would not need to do any change and you could change the defaults inside Ubuntu Touch so that the CUPS Snap (and any other Snap) would work out of the box. We should avoid that Snaps are in the Snap Store in 2 versions, Ubuntu Touch and desktop distros, we should stay truly distro-independent.
Also I would like to have some write-up for the next OpenPrinting News.
@beidl explains how he made printing working with the CUPS Snap.
And he thanks everyone who made the CUPS Snap possible, without explicitly mentioning their names. This is not only me, but also Michael Sweet, author of CUPS, and numerous current and former developers of snapcraft and snapd: @mvo@zyga@sergiusens@jamesh@ijohnson@alexmurray@emitorino@degville and many more …
Update: Now, when reviewing the video for my OpenPrinting News for February, I have discovered the following comment in the live chat:
46:45 Podcast Ubuntu Portugal Til rocks!
This was right after @beidl shouting out the people who were involved in making the CUPS Snap and the “project”. The person who has posted it, probably @DiogoConstantino from Ubuntu PT/Podcast Ubuntu Portugal, wanted to shout out me. Obrigado, Diogo!
