Offline
@pparent the strong reaction around apt is because what you are trying has been tried, we've been around for almost a decade which has yielded results.
for this i invoke "Chesterston's fence", behind that fence is apt, you are looking for a way to tear down the fence. But the real question is, why hasn't this fence been removed in the past decade? Spoiler: it is not due to a lack of trying
@pparent i'm not inviting you to fight, i'm inviting you to help you learn how it all works so you don't have to fight the system and run into issues we don't have the energy to help with.
many people don't read disclaimers, they see something someone publish, they use it. see open-store.io for a good example: clicking the bug icon tells them "don't do a bug report here, do it on click this button to go to the issue tracker. the amount of bug reports on the open store and missing on the actual issue tracker speaks for itself.
P.s. i have a feeling you haven't been reading my full posts because they are too long, so i again implore you to join either telegram or matrix, the more of the community can jump in to give all the proofs and data that you want, including why apt is not very suitable for general use. I'd explain the architecture of UT but that would explode my post you'd most likely not read the whole thing and as such not learn much from it.
given apt is such a core system component that UT uses in a very specific way— So if you absolutely insist on apt then you should at least first learn how updates work on UT. case in point: due to the architecture of Ubuntu Touch sudo apt upgrade has a very real chance of making your phone unbootable. I have seen this happen a couple of times already in the my past 7 years of assisting people in the community.
One good way to learn these things is by interacting with the people building the system, our main groups are at t.me/ubports and #ubports:matrix.org. I won't bore you with the tens of telegram groups and tens of matrix rooms i'm in— if you do join, the community will point you to the appropriate groups as necessary
@pparent I base my analysis on 7 years of helping people in the community debug issues and the time we've wasted because they ignored all warnings given. And not just my experience, but of many in the community.
You are free to do what you want sure, but know that as a developer you're decisions impact users and the community at large. If problems, new and old, will you take personal responsibility for all of them? will you be the one to assist them 24/7? Because the community cannot given our current size and the work that still has to be done.
This path has been taken many times as can be seen in almost a decade of history in the over 50 telegram groups. I have take this path aswell crackle is something that is came to be after all those different attempts. Which again, i don't want to promote too hard— but i do encourage you to at least try it and see if it can fit the usecase you are trying to fill with apt. Why ignore the effort that has already been done, to solve the case of "installing packages via the terminal"? Sure it isn't apt but does that have to be? We now have access to over 120,000 packages, which includes everything apt has to offer. Wouldn't it be better to concentrate on finding packages that don't work and figure out why they don't?
again, don't go the route of enabling apt. It simply not suited due to the way Ubuntu Touch is build. You will run into issues that we cannot help with. Even if you don't personally do, users of whatever you're cooking up will run into those issues. We cannot help with those issues not for lack of technical skills but for lack of time and people, there are other things we can focus our time and energy on. There is plenty we can fix to allow running packages you normally install with apt.
For people who want to install packages, you'd normally use apt for, i would like to suggest crackle instead. I don't want to push to hard on it, as it is something i wrote with the help of some in the community. I don't want to be like those companies praising their own products to sell it to you.
Crackle was born from the need to install packages but the lack of apt. It is the final result from experiments since 2018 which now 7 years and counting. The script itself started 4 years ago, and evolved quite a bit to get where we are now. At first it was wrapped around apt downloading packages and installing them into the home directory via various settings and environment variable, it worked fine for vim, git and even tailscale. But nowhere near the 80,000 packages ubuntu offers. Nobody, none of the people complaining about the lack of a way to install packages, even tried to help adapting more packages. Now 4 years later it uses nix and it works for all the packages i have tried. I even managed to install cargo and pipx with crackle, someone even managed to install flatpak— i have yet to find a package that plainly does not work. And there are over 120,000 packages to test.
I don't want to be over-confident but for this occasion i'll dare say that if a package installed with crackle doesn't work after installation, it would not have worked when installed with apt either— that is, is not an issue with crackle, but something we miss in UT— which is where can then focus our time and energy; improving UT's integration into the rest of the linux ecosystem
Once upon a time Ubuntu Touch used upstart, now we use systemd
Once upon a time Ubuntu Touch had its own display protocol, now we're moving towards Wayland
Once upon a time we had xmir, now we have xwayland
Once upon a time we had only libertine, now we have both snap and nix support
Once upon a time nix couldn't work on UT due to technical limitation, today it just works
Step by step integration work is done, to allow apps like firefox to work seamlessly
wait, did i just say nix just works, why did i then even mention crackle? am i a shill after all? well i can't deny i am biased, but one thing i noticed is that nobody talks about nix as a universal package manager and i think i know why, It is a completely different experience.
Since crackle was already a wrapper around apt, it was already close in experience to apt. So since i just swapped the "backend", it brings an apt-like experience to nix.
Yesterday i had a feeling i was forgetting something else you can without apt and without a writable rootfs. And today i know what it was: cargo! nvm! jekyll! all these package managers just work on UT! I completely forgot about it since i haven't touched it in a while but my personal website was made on UT
p.s. installing crackle is a one liner as shown in the readme, on UT that oneliner only works if your rootfs is NOT remounted as readwrite
@pparent trust me, it happened, the issue is way more complicated than you think. If you can think of it, it likely has been tried in the last 8 years (i call this rule 53)
Also i edited my answer a bit with some more tidbits, like you are doing now, feel free to check. But i really reccomend joining us on matrix or telegram
People who are calling Ubuntu Touch "locked down" due to the immutable nature are unfortunately too focussed on apt there is at this moment 2 alternative that lets you install the entire repetoire of linux packages all 120,000 of them (apt in contrast has access to about 80,000 of them) if you so wish—- see the links i included in my answer. You have a lot of control under UT, it just a different paradigm that departs from traditional package managers.
That is why we're not going to solve this with "make apt usable out of the box" but rather with "What are people trying to install, what are they trying to achieve?"
This "i cannot apt therefore locked down" is a good example of the XY problem
The user is trying to solve a problem, (say use vim) think they have to use apt to install a package to do it (sudo apt install vim) and then fight the system to make apt work
while there may be a better way (crackle install vim)
Why not mount an overlayfs over "/" and pivot_root in the environment of the user terminal? Like this the user could do whatever they want in their terminal without any risk of breaking the rest of the system (the overlay would not apply outside of the user terminal). On top of that it would reduce the tendency of advanced users (or not so advanced) to remount rw the filesystem to install small utilities with apt. It would also allow for more experimentation on the system with the possibility of a reset at any moment. And it could allow to install deb with less restriction on partition size as the overlay could use more space than the original system partition.
This has already been done aaaaaand it breaks when files underneath change making the phone essentially unbootable.
I think that not being able to install packages with apt in terminal can be frustrating for many new users who expect to escape a locked-down environment like Android, and find complete freedom in Ubuntu Touch. And somehow the first thing we tell them is that they should not do apt commands, it can be frustrating for newcomers and give the impression that it's actually another locked-down system. And we may loose users that way.
Ubuntu Touch is NOT a locked down system, just because apt is unavailable. It is a immutable distro just like the likes of steamos, fedora silverblue, microos among other next generation desktops
Things you can do on UT that you can't on a locked down system like android:
the basic operation of apt is:
This last part means it any path matches, it will just overwrite that, and this can go very wrong very fast if you don't keep in mind how updates are handled on Ubuntu Touch.
The real question we should asking isn't "how do we make apt work on immutable distros like Ubuntu Touch?" but rather "What am i trying to install with apt?" Chances are you can install it with snap or crackle, yes the same crackle i used to repackage firefox for UT. They will function the same as if you were install them with apt— if they are not functioning as expected, that isn't due to the "lack of apt" but rather that it needs integration work on UT
does this mean apt is useless on UT? Nope, there is little tool called ubports-qa which uses apt to install Merge Request from gitlab directly on your phone for your testing pleasure. Remember when i said "if you don't keep in mind how updates are handled on Ubuntu Touch''? This is a part of that, and to avoid unneccesary breakage you are advised to not run this tool on eithe the stable or rc channels only on the dailies(noble) or devel(focal)
BTW are you on telegram (t.me/ubports) or matrix (#ubports:matrix.org) some of these things are much easier to explain in real time vs a forum like this, there is a lot we can help you learn about ubuntu touch and what crazy experiments have been done— that would this post wayyyy longer than it already is
@Keli I have lancelot with the same kernel, both sim cards are detected for me
I am on 24.04-1./x daily but not the latest, could try on the latest daily?
@JayH said in VoLTE Implementation For Google Pixel 3a/3a XL:
Granted, I'm not keeping completely current but I didn't think halium was the current/accepted/approved/supported/??? method of porting any more? I thought it was all being compiled into the kernel and done?
fwiw Halium is still used, It is just that it is no longer needed to build halium itself
@pparent that's an interesting tweak— curious to see the effect
@pparent if you are going to improve the app further, there is one more idea you can try; whatsapp web's service workers.
If we can figure out the service workers, we can potentially get notifications even without being unsuspended
codec looks the same to me, youtube just works for me on noble—
I think i'll need some logs to understand what is wrong
@pparent if it works out of the apparmor context, perhaps one needs to look at the apparmor profile
Another example of local notifications is dekko: https://gitlab.com/dekkan/dekko which is also confined if memory serves— sans the need for a background service
you can also just tap and hold for the context menu, then it should work again
@pparent the SMS app is a local notification i think, since it works there—
did you include the application id in your dbus call? https://t.me/UbuntuAppDevEN/106721
I've also brought your thread to the attention of the group https://t.me/UbuntuAppDevEN/107491
thanks to the help of @ChromiumOS-Guy crackle is now not only able to set up nix home-manager, but also install, update, remove and list packages using nix home-manager:
https://github.com/tuxecure/crackle/releases/tag/v0.5.2
for cli applications they all seem to work so far, sans minor warnings (looking at you tailscale)
for gui applications i have not figured out how to get it be picked up by the drawer, but early reports show them launching fine from the terminal so far
So for anyone wanting to test it out, now the time to test out and see how far we can push the boundaries
@ChromiumOS-Guy thanks again, i'll take a look and test it out further
actually now i think about it, updates are easy enough with home-manager:
nix-channel --update
home-manager switch
The "challenge" is more in figuring out how we add and remove entries under home.packages in ~/.config/home-manager/home.nix
@ChromiumOS-Guy said in snap pop crackle! ....and nix!? The future of crackle:
@Fuseteam first let me say this is awesome, second if you want help I want to contribute to this.
I used nixos for while before switching to FreeBSD is has been a joy, so I say this with confidence this is finally the point where we can actually use UT as a full on linux distribution, the influx of packages here will be amazing.if you don't mind aside from reading up on the code, I will make a UI QML app so end users can just pick and install/uninstall primitive but any UI is better then terminal when walking.
looking forward to seeing a repo on gitlab.
thanks, the script above is all that's needed to setup nix on UT on the latest focal devel.
I agree with the UI idea, i believe it would be best if we add a plug in system-settings like so: https://gitlab.com/ubports/development/core/lomiri-system-settings/-/merge_requests/437
if you rather see the setup script on gitlab you can find it here: https://gitlab.com/tuxecure/crackle-apt/crackle/-/blob/v0.5/crackle
note that that's the only file i have so far, i'll be building that out further, based on the earlier iteration which can be found in the bash branch= but that's just for a cli interface
I'm unsure atm how we will handle actual package management throught the UI tho but i'd say we can worry about that after we can at least setup nix via the UI