It would be one of our team members.
The team member would copy and maintain the PKGBUILD in our gitlab.
Thanks! my pine phone came two days ago, and I will be looking into exactly what you have posted, I just need to get some bug reporting done first.
My pine phone worked with only a few glitches the fist day, so I downloaded updates the second day and now almost every app is crashing and I get lots of black screen with a blinking cursor in the upper right I am still trying to learn “the way of the Linux”. Since there are not any stack traces or dumps as far as i can see I may need to take debugging to a deeper level just to report where and what bugs are going on.
Thanks again!
1 Like
Hey, so I’m considering buying the Pro¹ X from F(x)tec, but I first wanted to get an idea of if it’s possible to install Manjaro ARM with Phosh on the device. Also, if it is, is it possible to make a bootable micro SD card?
If none of this is presently possible where can I start to contribute? I know next to nothing at the moment.
As far as I know, the device does not have mainline linux support or uboot support.
1 Like
Currently we have been testing ways to boot Manjaro arm on Android devices over halium so far we were able to boot but no gui is available atm as we need hwcomposer which will take time.
It will work but it is a slow process as we dont have enough resource and time for testing and development.
I would love to recieve sample devices first as currently someone from halium team is helping test on his test device.
Thanks for asking.
3 Likes
Sadly, the best I have that I could afford to part with is a sentimental, cracked S8 that would cost about as much to repair as a refurbished one would cost.
I would definitely reach out to F(x)tec to see about getting a sample device, if you think it would help development for their device. I imagine that having some help on supporting a popular Distro like Manjaro would be something that they’d be interested in, since they seem to be leaning into the community and Linux angles of their phone with the newest revision.
Sure if you have any contacts there then do talk to them.
Yes that’s true.
Let me know if you get any response from them.
Good luck.
Does the recent news of Plasma-Mobile dropping halium support affect this?
No.
We don’t use halium yet but it is being tested for Android devices.
Maybe we can get lomiri to work with halium.
Could these packages below be added to the ARM repo as these are in the x64 gnome profile and are architecture independent as far as I can determine.
manjaro-gnome-assets
manjaro-gdm-theme
manjaro-gnome-extension-settings
manjaro-gnome-postinstall
manjaro-gnome-settings
We don’t do profiles the same way as x86 does. 
They also probably has other dependencies that do not exist on ARM.
I’ve checked the dependencies, they all seem to be present in the ARM repo and according to the .BUILDINFO the above packages have pkgarch = any and seem to set some variables and setups that are present in the official Gnome edition.
Is there a way to manualy add them so I could test run this?
I’ve also found these two: gnome-layout-switcher & manjaro-gnome-tour are specific for X64, and can not be added, and I seem to recall a post from a team member about not building these for ARM.
1 Like
These are built by x86 maintainer and we do not have their signature in arm keyring.
These will have to be maintained by someone for arm side and as gnome is very sluggish on arm devices due to no proper gpu support while gtk still making using of cpu is most cases and arm soc are not that powerful to handle such heavy load on cpu. Some reasons why we don’t take interest in gnome yet.
Yes download them manually from the x86 repo and then install it using
sudo pacman -U PKGNAMES
It will install it only if the pkgarch=any for all the pkgs and when all their deps are available in the arm repo.
Try this and let us know.
Good Luck.
2 Likes
The theme for GDM is applied correctly that makes me happy. some succes today!
Summary
$ sudo pacman -U manjaro-gdm-theme-20201005-1-any.pkg.tar.zst
loading packages...
resolving dependencies...
looking for conflicting packages...
Packages (1) manjaro-gdm-theme-20201005-1
Total Installed Size: 0.93 MiB
:: Proceed with installation? [Y/n] y
(1/1) checking keys in keyring [######################] 100%
(1/1) checking package integrity [######################] 100%
(1/1) loading package files [######################] 100%
(1/1) checking for file conflicts [######################] 100%
(1/1) checking available disk space [######################] 100%
:: Processing package changes...
(1/1) installing manjaro-gdm-theme [######################] 100%
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Manjaro GDM theme install
manjaro-gnome-assets : dependency issues that cannot be solved by me tonight and i’m not that commited.
Summary
$ sudo pacman -U manjaro-gnome-assets-20201017-1-any.pkg.tar.zst
loading packages...
resolving dependencies...
warning: cannot resolve "manjaro-gnome-settings", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "manjaro-gnome-extension-settings", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-arcmenu", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-dash-to-dock", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-appindicator", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-dash-to-panel", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-pop-shell", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-material-shell", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-gsconnect", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-desktop-icons-ng", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-unite", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-gamemode", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-wallpapers", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "manjaro-base-skel", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "qgnomeplatform", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "illyria-wallpaper", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "manjaro-wallpapers-18.0", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "manjaro-gdm-branding", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "nerd-fonts-noto-sans-mono", a dependency of "manjaro-gnome-assets"
:: The following package cannot be upgraded due to unresolvable dependencies:
manjaro-gnome-assets
:: Do you want to skip the above package for this upgrade? [y/N] n
Manjaro-gnome-extention-settings has no extention files to edit since they are not installed.
Summary
$ sudo pacman -U manjaro-gnome-extension-settings-20201121-1-any.pkg.tar.zst
loading packages...
resolving dependencies...
looking for conflicting packages...
Packages (1) manjaro-gnome-extension-settings-20201121-1
Total Installed Size: 0.00 MiB
:: Proceed with installation? [Y/n] y
(1/1) checking keys in keyring [##########################################################] 100%
(1/1) checking package integrity [##########################################################] 100%
(1/1) loading package files [##########################################################] 100%
(1/1) checking for file conflicts [##########################################################] 100%
(1/1) checking available disk space [##########################################################] 100%
:: Processing package changes...
(1/1) installing manjaro-gnome-extension-settings [##########################################################] 100%
Optional dependencies for manjaro-gnome-extension-settings
manjaro-gnome-settings-20.2
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Compiling Community GSettings XML schema files...
No schema files found: doing nothing.
No schema files found: doing nothing.
No schema files found: doing nothing.
manjaro-gnome- postinstall wil regenerate all locales, killed the install, will try on fresh image tomorow
manjaro-gnome-settings has a file conflict.
Summary
$ sudo pacman -U manjaro-gnome-settings-20201121-1-any.pkg.tar.zst
loading packages...
resolving dependencies...
looking for conflicting packages...
Packages (1) manjaro-gnome-settings-20201121-1
Total Installed Size: 0.04 MiB
:: Proceed with installation? [Y/n] y
(1/1) checking keys in keyring [##########################################################] 100%
(1/1) checking package integrity [##########################################################] 100%
(1/1) loading package files [##########################################################] 100%
(1/1) checking for file conflicts [##########################################################] 100%
error: failed to commit transaction (conflicting files)
manjaro-gnome-settings: /etc/skel/.config/mimeapps.list exists in filesystem
Errors occurred, no packages were upgraded.
I’m learning alot about making a working image, thank you for the tips, the tools and patience answering my questions, where would I start to read when i want to know more about profiles, overlay, skel directories and how it all ties together? I’ve been looking at the wiki and assumed the process was roughly similar
Gnome does seem slowish, but running from a sd card. once I am happy enough with my settings (and unable to further adjust because I lack the knowledge/time) I’ll run with it and see how it goes. So far I’m enjoying myself immensely with this
2 Likes
People don’t give sd cards enough credit. Sure, they top out in the 45MB/s range for unbuffered read/write on my RPI4, but their 4k random read speed is upwards of 10+ TIMES the speed of a HDD’s assuming you got a good card. The random read speed is what really affects the feel of a system. Combine that with the fact that you can do cached writes and re-reads of common files in the GB/s range until you fill buffers, and you’ve got a pretty darn good experience. Don’t do 4k video editing on them, sure, or run large databases, or a file server and expect speeds faster than the sd card can read, but for just an OS, web browser, all that jazz, the SD card isn’t slowing you down most likely.
Gnome is just… SLOW on arm. It’s GPU intensive, demands composition, and isn’t light weight compared to plasma and most of the other environments. That’s not to say it’s a fat pig, but arm in the SBC SoC ream is really good at showing you which pig is indeed larger 
1 Like
So GDM would be doable.
That’s a lot of package we would have to maintain to get that one package working.
Yeah, again, the extensions would have to be packages we would maintain.
Can you tell what package (if any) contains that file with pacman -Qo /etc/skel/.config/mimeapps.list?
It would make the ’ Gnome experience’ look a bit more like the x86 if using gdm.
Then better not make the effort, my assumptions where not correct (besides the GDM theme) and gnome is not performing as wel as other options . So until this improves and there is enough demand there would be no reason to add them.
$ pacman -Qo /etc/skel/.config/mimeapps.list
error: No package owns /etc/skel/.config/mimeapps.list
check on main machine:
$ pacman -Qo /etc/skel/.config/mimeapps.list
/etc/skel/.config/mimeapps.list is owned by manjaro-gnome-settings 20201121-1
so it also depends on a package that would be extra work for no benefit.
Hi, thanks for this overview! I’m trying to build an up to date image of Lomiri for the PinePhone and I’m starting to understand more and more of the process. Some things are not clear to me yet, some help would be appreciated:
- How do I properly install packages that I built with
buildarmpkginto the rootfs? A lot of packages for Lomiri depend on each other and I would like to use my updated builds for the build process instead of the outdated ones in the ARM repository that are being pulled automatically as dependencies. I thought the-ioption forbuildarmpkgwould do exactly that, but it seems this only takes packages I have on my machine (in/var/cache/pacman/pkg/)? - This makes me wonder about the same question for
buildarmimg, will I be actually able to use my manually built packages with-ifor building an image in the end or did I misinterpret that option? - Apart from manjaro-arm-tools, are there ways of interacting with the build environment/rootfs that I keep reusing with
buildarmpkg -k? A couple of times I ran into the problem that after starting a build (Building xyz ...) nothing happened forever (for hours) and I had to manually kill the process (Ctrl+C told me that the user aborted, butbuildarmpkgstill didn’t finish). After that my build environment (reused with-k) was useless, I kept getting the messagepacman is currently in use. So I had to use a new environment which had to pull all the dependencies again, always takes a while. - Say I manage to update everything properly and get a working image, how does the process of contributing work? Do I just push my commits/updated PKGBUILDs, then someone looks at them and if it is considered alright, a new package will be built remotely and updated in the repos?
- Some packages changed their name upstream. What’s the best way to handle that? I changed the downstream name accordingly, but would it have to be marked somewhere what old package this new package replaces? Would the repo name have to be changed?
Sorry for all those questions, but I’m curious to learn and hope someone can help!
I will try my best to explain:
When creating an image, you would need to use the -i flag of buildarmimg. It only supports adding 1 local package though.
It’s just a regula rootfs/chroot, so you could chroot into with any of the usual means, as long as you have qemu-user-static installed.
It sounds like you ware in the process of updating the entire Lomiri stack. This should not be done locally with our tools. It’s simply not what they are designed to do. What you would want to do is adding all the packages you build with buildarmpkg to an online repository. You can then add that repository to your buildarmimg command with the -k flag, like buildarmimg -k https://mynewrepo.domain.com/$branch/$repo/$arch/.
That will make buildarmimg use the repo you designated as it’s first source when installing packages.
If you do manage to build and test it all, you would need to somehow submit these new working PKGBUILD’s to us, so we can update our gitlab and have our CI build the images.
Yes. This is done in the PKGBUILD with the replaces=() line. In there you put it’s old package name.
And yes, we will have to change the gitlab repo name to also match the new name.
1 Like