[Wiki] How to contribute to Manjaro ARM

The theme for GDM is applied correctly :slight_smile: 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 :slight_smile:

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 :wink:

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 buildarmpkg into 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 -i option for buildarmpkg would 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 -i for 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, but buildarmpkg still didn’t finish). After that my build environment (reused with -k) was useless, I kept getting the message pacman 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

Thank you very much, that was very helpful!

I tried that, but it didn’t work. Looking at the source code of the tools (which luckily was much easier to understand than I thought) cleared things up a lot. Seems like the local package needs to be in the same directory where buildarmpkg is run, because if you supply a path (which I did) it gets parsed together with the package name later on which results in a non existent path.

Great, I should have checked that, makes it a lot easier.

Yes, I am trying to update the entire stack (might take a while …). I wasn’t aware of the -k flag, thanks. I’ll try to build my own local repo then with repo-add (just found out about that) and modify buildarmimg to have it copied into the rootfs since I don’t have a domain where I could host a repo.

Thank you for the quick reply!

1 Like

Hi,

@Strit @linux-aarhus I don’t find in the repo the Manjaro-arm-tools 2.10.3 with the so practice Calamares as new First Time Setup tool for the arm devices, it mean if someone build an image with the Manjaro-arm-tools 2.10.2 Calamares is not present at first boot…

Linux-aarhus is not Helmut Stult ? If I’m wrong I’m sorry…

Correct. He is not. Helmut seems to have stepped down as a maintainer, so the package probably won’t be updated until someone takes it over. Maybe @Yochanan or @oberon will take over Helmuts old packages?

1 Like

Hi,

Did you managed to get a functionnal Lomiri distro by any chance?

No the lomiri team got busy with other priorities. We should be able to build it again with the new patches but it will still at the same stage where it was left.

I’m trying to compile a dts file for my TV box into a dtb but I’m not sure how exactly to do this from
my x86_64.
I got the linux package and I can compile it for ARM but I’d like a simple way to just compile my dts , make some modifications, compile and test again all the while keeping the patches that are coming from the linux package.
Hopefully I’ve explained this clearly enough.

Please check manajro wiki page of amlogiv tv boxes. One of the contributor and documented hours to build own dtb.