@GizmoChicken said in The road(map) explained:
But from your reply, I'm guessing that's not such a good idea.
I work in software development, but I'm sure it happens in many other fields too that there are frequently more good ideas than resources to put them into practice.
@GizmoChicken said in The road(map) explained:
Creating such an "extra-edgy" build based on nearly stock Ubuntu 20.04 would necessitate (and hopefully facilitate) a move from upstart to systemd.
I think you are answering your own question: There are a lot of pieces to rework, and somebody needs to do each of them. And there are other unrelated tasks that need to happen.
Once the move to systemd is complete, snapd could be supported.
That's a second, not insignificant, piece of work. And, as you say, will be easier after a move to systemd.
Having official snapd support for a PinePhone build would benefit those who wish to repackage clicks as snaps, and then test those snaps on a PinePhone, thereby likely accelerating efforts to repackage clicks for future “cross-platform” use.
There's a lot more to "cross-platform" than a common packaging format. Most apps packaged as snaps expect an X11 desktop: These won't "play nice" on phones.
Being based on nearly stock Ubuntu 20.04, such an "extra-edgy" build could be used as a platform onto which various aspects of UT (including aspects that must change before upgrading to Mir 2.1) could be tested individually (before being tested on a full "edge" build), which could be helpful when attempting to "walk up the stairs" associated with rebasing the full UT stack to 20.04.
This is mostly separate from the above pieces of work.
There's really only one aspects of UT that's needed for a Mir 2.x transition: A component called QtMir needs to "play nice" with MirAL. I've recently had a good discussion with @mariogrip and @UniSuperBox about how we can make that happen.
But even if we look to a time when that is done (which won't be a couple of weeks) that doesn't give a fully working Lomiri environment. There are features the mirclient API provided that need to be redeveloped for the Wayland based stack.
The good thing about is this work doesn't need a phone for development, or even Ubuntu, willing hands could contribute to this development using any Linux distro.
Maybe someone reading this thread could help?
One of the problems with moving to Wayland is that the Mir implementation of the latter lacks some of the features that were provided by the mirclient API. One such feature missing when using Wayland on the PinePhone and PineTab is "Trusted Prompt Sessions", this seems significant.
wlr_foreign_toplevel_management_unstable_v1 and xdg-desktop-portal?
@UniSuperBox said in OTA-13 call for testing:
Apologies for the lack of detail in my previous message, but the reason for the delay was an embargoed fix
No need to apologise, we recognise temporary secrecy is sometimes necessary for the good of us all.
@nexus5 the members of this community are doing what is important to them. If you need support in doing what is important to you then you'll likely find it. If you ask people to do what isn't important to them, you'll be disappointed.
I've seen an increase in chat about the Lomiri desktop recently. Is there a corresponding increase in developers interested in making it great again?
@pixelated I agree that this is the OT section, but that isn't "anything else" it is "other stuff of interest to the community".
FWIW I use 20.04 and develop both debs and snaps. There's no incompatibility between the packaging technologies.
Snaps don't normally install deb packages. (Only "classic" snaps are able to do that, but even they probably won't as they could be installed on a largely incompatible distro. E.g. Fedora and Arch don't understand apt.)
Any apt problems you have are apt problems and you are better off searching for help on a site that supports apt.
@erlend said in DRM driver - Fedora(pinephone):
And why is the UT version writing "checking using fallback method" while fedora is writing ", but continuing anyway"
That's down to getting a different error from drmCheckModesetSupported(), so likely a kernel difference.
Yes, months.
From the Mir perspective (as the Mir lead I know this bit best), there are features UT uses from the mirclient API that, currently, have no equivalent in Wayland.
Someone has to implement workarounds and/or Wayland equivalents. And there is other work the same devs (both Mir and UBports) are committed to.
Beyond Mir, there's a whole stack of changes to the OS. New versions of components, and systemd.
It's all solvable, but will take time.
Another data point: I see two (or more) unread on my M10, but none on N5 or desktop.
@Flohack Any useful investigating I can do?
@13arz for the server, Vulkan is just another way that clients draw buffers that the server doesn't care about. The only issue to address is shipping the buffer to the server. That work isn't done (or likely to be done) with mirclient, but is done with Wayland.
It should "just work" after the Wayland migration (for graphics stacks that enable Vulkan clients).
Could apt be replaced with a script directing people trying to use it outside libertine to an explanation of why it's a bad idea?
@stefwe said in Podbird reignited:
I would love to help out. But at the moment the code base is on launchpad and bzr instead of git is needed.
There's a bzr plugin for git so you don't need to learn bzr.
I asked Michael some time ago to move on github or gitlab, but he don't want.
Is that because he has no current interest in the project and can't be bothered?
I gather from other comments that the project has been unmaintained for some time. If that's the case, and assuming there are no licencing issues, then forking is the answer.
It isn't frozen in time. When the project was forked the base was the already EOL 15.04 and a big task faced by UBports was to change that to 16.04. That was done a couple of years back.
The next big task was updating other dependencies in the stack to supported upstream versions. This may never be totally complete, but is largely done in OTA-12. This was more urgent than migrating to 18.04 as 16.04 was, and is still supported.
A stated goal is to update to 20.04LTS base before 16.04 goes EOL next year.
@Nora-No said in Nexus 4: How to create a hot spot?:
can't find any hotspot setting on my nexus 4 either...
It isn't supported. RNDIS (USB tethering) is however:
In UT Tweak Tool:
HTH
Yesterday Marius shared some images of Lomiri desktop. How should developers interested in contributing to "desktop" get involved?
See the FAQ: "Can I use the APT repositories on Ubuntu Touch and install packages?"
The system partition is intentionally read-only (because of design trade-offs suited to a phone). You can create a chroot and install things there.
What does this mean for UBports? Packaging of Unity8 Desktop for Debian
@rob said in What's Inside the Black Box of Ubuntu Touch?:
@alan_g that is really helpful. Now just to help in my understanding, where, as example does one configure a QT or a GTK so use these settings?
These want to be set for the process using the toolkit. Hopefully setting them for the launch command is enough:
QT_QPA_PLATFORM=xcb ubuntu-app-launch ...
There may be further details, it's been a long time since I did any of this.