@developerbayman @kugiigi @libremax @lsitongia @moem ok sorry, got a bit sidetracked there, lets come back to the actual diagram bayman posted because i think we kinda blew past it and it deserves a proper look so whats actually being proposed here the framing is mesa-style — and thats not just vibes, mesa is a genuinely good analogy. mesa spent like 15 years being the "open graphics driver layer" while proprietary blobs were still everywhere, replacing subsystem by subsystem, vendor by vendor, until one day there just... wasnt a reason to use the blob anymore. no big bang. no single "we did it" moment. just a gradient the diagram is proposing exactly that for halium. not "kill halium by tuesday", more like — make each new port depend on it a little less than the last one. track the gradient. call it halium-thin eventually, then upstream-first thats actually a solvable problem framing. unlike "eliminate halium" the AI cold water thing i posted that ai takedown saying "its all or nothing, the kernel cliff is real, blobs break when you swap kernels" and thats... correct? like, if you try to run android camera blobs on a mainline kernel they'll crash, the abi doesnt match, end of story but i dont think that actually kills the idea. because the diagram isnt proposing you gradually blend kernels. its proposing you replace the userspace pieces that depend on halium, one at a time — audio via pipewire/droid modules, modem via modemmanager, graphics via drm/kms and mesa — so that by the time a device lands on a mainline kernel, halium is already mostly hollow. the kernel swap is still a hard cut, but youve already done the hard work before you get there postmarketos have been doing exactly this for years. and in december 2024 they got actual working cameras on the pixel 3a and fairphone 5 under mainline linux, no android blobs, using libcamera with a software isp. not great quality yet, "retro appeal" as they put it lol, but it works. that was considered a major breakthrough so the cliff is real, the gradient is also real. both things are true what the roadmap gets right phase 1 — make UT feel permanent is actually the most underrated part standardise the boot bundle, own the OTA properly, hide the halium install jargon from users. this is boring infrastructure work but its the stuff that makes every port less fragile. the current situation where you tell users "install ubuntu touch, but first downgrade to android X" is just not a good look and its fixable phase 2 — thin the compatibility layer is where the real meat is audit each subsystem. keep on android, bridge temporarily, or replace with native. this is basically what the postmarketos device category system does — they move devices from testing to community to main based on exactly this kind of subsystem checklist. its proven to work phases 3 and 4 are aspirational but not fantasy. fairphone 5 already has working calls, audio, and cameras on mainline linux via postmarketos. thats basically a phase 3 device today. it took years of work from linaro contributors and community folks, but it got there the GKI angle nobody mentioned one thing worth flagging: google's generic kernel image initiative (mandatory since android 12 for devices on kernel 5.10+) is actually a quiet tailwind here pre-GKI, up to 50% of android device kernel code could be completely out-of-tree vendor junk. GKI pushes that stuff into loadable modules with a stable interface, so the core kernel is much closer to upstream linux. that makes halium porting on newer devices more reproducible and the eventual mainline jump smaller this only helps for android 12+ devices obv, doesnt fix the old device pile. but for anything new its a meaningful structural improvement the reference device thing the diagram says "choose a few reference devices with good unlock paths and strong upstream interest" this is just correct and postmarketos proves it. the fairphone 5 got so much mainline attention partly because fairphone actively cooperates with upstream developers and partly because it was a target worth spending time on. the result is that its now basically a showcase device for what mainline mobile linux can do UT picking one or two devices to treat like this — not "we support everything forever" but "these specific devices are our reference, they will be properly upstream, everything else is best-effort" — would probably change the project's trajectory more than any technical work what the diagram doesnt fully address couple things i think are worth raising: CI against real hardware — postmarketos specifically called out in their governance work that getting reference boards and real phones into their CI so regressions get caught before ports diverge is a priority. UT doesnt seem to have this at all. every port is essentially maintained by whoever ported it. a shared CI backbone for the reference devices would be a significant upgrade the lomiri on debian path — as I mentioned this. if the goal is upstream-first, lomiri running on debian/bookworm on a mainline device is kind of already that? its worth tracking how close that is to being a daily driver, because it might be the actual phase 4 path rather than a separate project the modem situation — modemmanager is already the upstream linux standard for this, its in active development (got gps-without-sim in 2024, working on cell broadcast alerts), and replacing ofono/rilmodem with it on halium devices is probably the single most achievable subsystem swap in the near term tl;dr the diagram is a solid plan, the AI critique attacked a version of the idea that wasnt actually being proposed, and there's a bunch of prior art (postmarketos, fairphone 5 mainlining, mesa analogy, GKI) that suggests the general approach is sound the hard part isnt the architecture. its bandwidth, CI, and picking the reference devices and actually committing to them anyway, thats my read on it. sorry again for the digression earlier

What a waste of everyone's time. Is it really that hard to delete everything (so it doesn't happen again under a different username) and block the user? Sorry if I sound harsh.

https://wiki.lineageos.org/devices/lavender/

@arubislander what does that have to do with ai ? The analysys is not valid for a given discussion ? It pollutes the thread with actual factual analisys, overview, in plain english, and solid suggestions on actions ? What is the point of this discussion if giving opinions that using ubtouch with one hand is not a use case, is not polluting, but giving structured analysys is ? Where is this analysis wrong ? Or this is like "solid humans club (no llms allowed)"? You know it can write in the way that you'll will never be able to tell if its human or not, right ? Such as even this reply could be ai crafted with all misspellings and writing style, and so on(which is not). But I havent instructed it to do it, I use it where see fit, and I was open and honest about it with you. I suggest to not fight this battle with the tool. If its producing irrelevant results, tell me where are they, in a manner of discussion that is. I'll try to adjust, if its still not useful I'll stop using it as not fitting tool for the job

this problem may be related to your hardware. Try running with --disable-gpu and --disable-gpu-sandbox to see if it works

@k.nacke im finally back with the tablet, can you teach me how to port a device

i am doing a app for this in the future called pysync ...i may rename it for UT ...hmmm UT-sync?? .....the app is built but very broken right now and not a priority ...it will do the same thing as syncthing ...well i hope anyways UT design can throw a wrench into things

@Escain this is precisely what i am experiencing as well on fp5! @devs please fix!

@Kadafi that is all very strange.

@oldbutndy currently only the Pine64 devices that have a UT port do not require halium. These devices all run a 'mainline' kernel (I put mainline within quotes, because actually no device, and hardly any distro even, runs a pure mainline kernel. Most kernels in the real world come with patches to improve operations on their expected execution environment. These kernels can track mainline more easily though, this is true) Unfortunately there is currently no maintainer for any of the Pine64 devices, and they are therefore stuck on focal with not yet functioning OTA updates. EDIT: I had forgotten about the Raspberry Pi port, which is also mainline. And I guess the PDK image could also be counted.

@grenudi said: @oldbutndy said: Do you use claude for coding, as well as analysis / summary of things ? Yes. I want to advise you to own that execute button on any ai, especially claude, he loves to jump straight into execution, create ton of how to, code snippets fixes and so on, burning your tokens like a teenager his life. Own execution button ... ... Maybe you already know all that so sorry for the unasked advise. THANK YOU. I REALLY appreciate your insight on this. Always open to advice. I did not know it. I asked Claude, it answered. Got C++ code working (TFT LCD, WiFi NTP, RTC, SD micro, SDI temp sensor, LiPo monitor, etc). But I had no idea how many tokens I used. Then yesterday: Slow/No reply - then something like: " you have to wait until 8 pm." - HARD STOP - Ohhh, OK.

@oldbutndy said: google quick search gets it wrong, and Dive Deeper gets it wrong, but people find UT device page and critical info NOT obvious, and new people waste time & money @oldbutndy Maybe it will be possible to establish CI/CD pipeline from gitlab that will populate a "tested features" table from commints from testers forks provet and merged. Or there are even easier tools for such pipeline, as it involves no code ondy results from testers. Maybe ubports already uses something similar to it like 'ig projects have, and something got lost in the process. Dont know where to direct these qustions tho, just thinking outloud. But doing those test results tables by hand is very tedious and error prone

@libremax @vlad-nirky @domubpkm @moem the person asking that question is not its own fault for not piecing togethere the answer himself, its a pattern, you can dismiss a person, but you can not dismiss a pattern. Rather than answearing the question here, maybe we can look at what can be done so that such questions will be answered before they land on the forum ? Making a page "where the thing are for ubuntu touch and where they are headed" and making a link to in surely visible for all new comers. For example. You've pointed out resources including merge messages, maybe it will be helpful to place links those references and explanations somewhere in one place, for newcomers to see. I dont know what exactly needs to be done for it, but we can disscuss that here, and maybe this itself will be tangiable way for @marcellotogg to participate, or for anyone else who's asking the same question right now

@Futura Wow, that's disappointing.

@Kadafi I have a FP5 and the 2FA app you are talking about installs without problem. Maybe it's because I'm on stable while by using daily you are exposing yourself to any fleeting update bug. The usual cause of this problem is network error. Try to download the click by hand using Morph QT6 browser and visiting open-store.io. If you can't download it, either your network is blocking somehow or your install is hosed (I have already warned you against this possibility, I'm still not convinced by your counter-arguments...) If you can, navigate to the resulting file and try to install it from there using the store app.

actually this is been a few months coming

@AndroFree NEVER AND I MEAN NEVER RELOCK YOUR BOOTLOADER! .... i do not trust the xaiomi unlock process that much ...not a fan at all

@grief493 I see you have the right mindset for all this, better than the one I had when I was trying ubtouch, so I doubt my report will be of any use to you, you seem to have a sense of direction on your own. Anyway, thank you for your attention, and its a pleasure to see such a collective contribution mindset that you present. Best of luck!