Extra Packages (Mostly for RPi's)

ARM Installation
1

I maintain a few packages for my personal use. Since I keep them up to date I have decided to share them. To avoid this topic being closed and will not be able to update I created a folder on my googledrive and will keep it current.

https://drive.google.com/drive/folders/1bv_1ueq4WdA09HLAIqKUA3mK2RC-qoVn?usp=sharing

handbrake: This will work for all arm devices. Needs the 2 packages when installing.

zram-swap: Works on all devices x96 or arm. Uses a compressed portion of device ram. Especially good for arm devices with low ram reducing the chance of lockups and speeds up system if a swap space is currently using a swap to disk. Enable and start zram-swap.service after installing the package. The amount of swap space in ram will vary proportionally to how much ram the device has onboard.

rpi-ffmpeg:

For all RPi devices. Allows h264/h265 HW decoding for RPi4 and below devices. Allows h265 HW decoding for the pi5’s. This is a complete drop in replacement for the ffmpeg in the repo that uses the mpv in the repo. To run on X11 Desktop (I do not know how to run on others. Do not use them. One would have to do some research):

Pi4 and below for h264:

mpv --hwdec=v4l2m2m-copy --gpu-api=opengl --vo=gpu h264-video

All Pi’s for h265:

mpv --profile=fast --hwdec=auto-safe --gpu-api=opengl --vo=gpu h265-video

Current kernel & kernel-headers packages I am using. Seems to be the best here on my pi4.

2

Looks cool!

Any plan to put them on a pacman repo?

3

I did provide them in manjaro-arm’s repo but I have no access anymore to a repo.

4

I am not fluent enough in pacman to know what exactly is required but how feasible would it be to just setup some “endeavouros-arm-extra” repo?

Or alternatively, rely on some automatic building and repo tools (openSUSE’s obs some to mind)?

5

Pop the PKGBUILD’s in the AUR as ARM variants? Just make sure there’s nothing EndeavourOS specific going on in them (which I don’t imagine there would be).

6

As @Bink said AUR, I know you can make your own repos but am not sure how

7

I found this helpful when I was figuring it out:

8

Yer I was thinking more of how Trinity Desktop handle it with their own repo that needs to be added, I update official repos separate from AUR (same as anything else from other sources, helps if any issues arise to figure out where and what) (spellcheck wanted me to change figure to gunfire - a good example of to take note of what is happening)

9

AUR is for x86 PKGBUILDs. They will allow PKGBUILDs for arm but have to be able to run on x86. They used to allow just arm PKGBUILDs but a while back they purged them all. Even if they did allow PKGBUILDs one would still have to build the package locally to install them.

I can provide all of the PKGBUILDs for my packages if one wants to build them locally.Which would be optimal for the kernels due to 3rd party / DKMS modules some people use. I build them here on my x86 for the sake of speed as I do not use any out of tree modules. I had access to a 128 core build server at manjaro-arm to build them.

10

Oh wow :hushed_face:

So it is:

11

The Rpi kernels updated today to 7.0.4. I pushed them to my googledrive folder:

https://drive.google.com/drive/folders/1bv_1ueq4WdA09HLAIqKUA3mK2RC-qoVn?usp=sharing

I dug out my rockpro64 and installed a new image / kernel on it and compiled the new kernels on it as a master and my x86 as a slave using distcc. So there should not be any issues with getting 3rd party modules to work. @DrYak your battery support is built in the new kernels.

[ray@rpi ~]$ cat /proc/version
Linux version 7.0.4-1-rpi (alarm@alarm) (aarch64-unknown-linux-gnu-gcc (GCC) 15.2.1 20260209, GNU ld (GNU Binutils) 2.46) #1 SMP PREEMPT Fri May 8 02:06:20 UTC 2026

rockpro64:

[root@alarm alarm]# inxi -Fxz
System:
Kernel: 7.0.4-1-V8-WARPME arch: aarch64 bits: 64 compiler: gcc v: 15.2.1
Console: pty pts/0 Distro: Arch Linux ARM
Machine:
Type: ARM System: Pine64 RockPro64 v2.0 details: N/A serial:
CPU:
Info: 6-core model: N/A variant-1: cortex-a72 variant-2: cortex-a53 bits: 64 type: MCP
arch: ARMv8 rev: 4 cache: L1: 416 KiB L2: 1.5 MiB
Speed (MHz): avg: 600 min/max: 408/1416:1800 boost: disabled cores: 1: 600 2: 600 3: 600
4: 600 5: 600 6: 600 bogomips: N/A

12

RPi upgraded their kernels again to v7.0.5. I pushed them to my googledrive folder. Also I pushed an upstream kernel packages v7.0.5. Think of it as arch-arm’s upstream linux-aarch64 kernel on steroids. It has about 300 patches from the WARPME minimyth2 repo that enhances and supports all of the many devices that minimyth2 uses.

On my rockpro64:

[alarm@rockpro ~]$ uname -a
Linux rockpro 7.0.5-1-V8-WARPME #1 SMP PREEMPT Sat May 9 17:49:15 UTC 2026 aarch64 GNU/Linux

His patches are listed here in this file. This kernel is good for people who like to experiment. He searches the web for patches that have not made it upstream yet.

https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-7.0/Makefile

13

All kernels upgraded to v7.0.6 on my googledrive,

https://drive.google.com/drive/folders/1bv_1ueq4WdA09HLAIqKUA3mK2RC-qoVn?usp=sharing

14

Upstream has upgraded their kernel today to v7.0.8 so I have built and pushed the new linux-aarch64 it to my googledrive. RPi has not upgraded their 7.0.y tree yet. Hopefully they will do it Monday or Tuesday. They usually do not do much work on weekends.

If anyone is interested warpme added some improvement patches for radxa-dragon-q6a:

0000-drivers-base-revert-g14cf406e-to-fix-qcs6490-audio-hang.patch
0000-drivers-spi-revert-gcc34d77dd-required-by-revert-g14cf406e.patch
5204-arm64-dts-qcom-improve-support-for-radxa-dragon-q6a-v2.patch

+CONFIG_DRM_LONTIUM_LT9611=m
+CONFIG_DRM_LONTIUM_LT9611UXC=m

Not sure why they do not have the modules builtin the kernel when upstream doc says the default is “=y”. Seems to me the modules would have to be added to the initramfs to boot the way they have it. But what do I know…

My rockpro64 with new kernel via ssh:

[alarm@rockpro ~]$ inxi -Fxz
System:
Kernel: 7.0.8-1 arch: aarch64 bits: 64 compiler: gcc v: 15.2.1
Console: pty pts/0 Distro: Arch Linux ARM
Machine:
Type: ARM System: Pine64 RockPro64 v2.0 details: N/A serial:
CPU:
Info: 6-core model: N/A variant-1: cortex-a53 variant-2: cortex-a72 bits: 64 type: MCP
arch: ARMv8 rev: 4 cache: L1: 416 KiB L2: 1.5 MiB
Speed (MHz): avg: 600 min/max: 408/1416:1800 boost: disabled cores: 1: 600 2: 600 3: 600
4: 600 5: 600 6: 600 bogomips: N/A
Features: Use -f option to see features
Graphics:
Device-1: display-subsystem driver: rockchip_drm v: N/A bus-ID: N/A
Device-2: rk3399-dw-hdmi driver: dwhdmi_rockchip v: N/A bus-ID: N/A
Device-3: rk3399-mali driver: panfrost v: kernel bus-ID: N/A
Display: unspecified server: N/A driver: N/A tty: 115x24
API: N/A Message: No API data available in console. Headless machine?
Info: Tools: No graphics tools found.
Audio:
Device-1: rk3399-dw-hdmi driver: dwhdmi_rockchip bus-ID: N/A
Device-2: simple-audio-card driver: asoc_simple_card bus-ID: N/A
Device-3: audio-graph-card driver: N/A bus-ID: N/A
Device-4: audio-graph-card driver: asoc_audio_graph_card bus-ID: N/A
API: ALSA v: k7.0.8-1 status: kernel-api
Network:
Device-1: rk3399-gmac driver: rk_gmac_dwmac v: N/A port: N/A bus-ID: N/A
IF: end0 state: up speed: 1000 Mbps duplex: full mac:
Bluetooth:
Device-1: rk3399-uart driver: dw_apb_uart bus-ID: N/A
Report: rfkill ID: hci0 rfk-id: 0 state: down bt-service: not found rfk-block: hardware: no
software: no address: see --recommends
Drives:
Local Storage: total: 29.12 GiB used: 10.5 GiB (36.1%)
ID-1: /dev/mmcblk1 vendor: SanDisk model: SD32G size: 29.12 GiB type: Removable
Partition:
ID-1: / size: 27.97 GiB used: 10.37 GiB (37.1%) fs: ext4 dev: /dev/mmcblk1p5
ID-2: /boot size: 511 MiB used: 129.6 MiB (25.4%) fs: vfat dev: /dev/mmcblk1p4
Swap:
ID-1: swap-1 type: zram size: 5.64 GiB used: 0 KiB (0.0%) dev: /dev/zram0
Sensors:
Src: /sys System Temperatures: cpu: 40.0 C mobo: N/A
Fan Speeds (rpm): N/A
Info:
Memory: total: N/A available: 3.76 GiB used: 329.4 MiB (8.6%)
Processes: 194 Uptime: 3m Init: systemd
Packages: 228 Compilers: gcc: 15.2.1 Shell: Bash v: 5.3.9 inxi: 3.3.40

15

I am setting up Rclone and a script to sync from your Google Drive. Just saying.

Thanks for your work on kernel packaging, my CM5-powered laptop appreciates it.

TODO: Once I have more of this elusive thing called “Free Time™” I should look into what’s necessary to:

  • either setup a proper pacman repo so it’s possible for people like me to add this as just another source into their /etc/pacman.d
  • or setup automatic PKGBUILD building and hosting on OBS (I have more experience doing that with building SPECs into RPMs there)
16

I tried to set up a pacman repo on my googledrive using instructions on the web but could not get it to work properly.The db getting pulled down was not in the right format. I uploaded my current kernel pkgbuilds to my googledrive today.

17

A pacman repo must include these four files for your repository/mirror. As set up for EnOS

endeavouros.db
endeavouros.db.tar.xz
endeavouros.files
endeavouros.files.tar.xz

any time even the slightest change is made in the repository, these four files need to be updated and uploaded to your repository/mirror. All packages must also have an accompanying .sig file (signature file) generated for every new or updated packages.

The signature file is the hardest part. One has to create GPG keys and use them to sign the packages.

The EndeavourOS ARM repo with all the EnOS explicit packages.

Pudge

18

All new kernel packages pushed to my googledrive. Pretty big version bump: v7.0.6 ==> v7.0.9.

Update:

I installed the new kernel on my pi4 and it stopped before the login screen. I then installed the 7.0.6 kernel back and ran into the same issue. I do not have time today to check it out what is happening but seriously doubt it is a kernel issue. Probably something else that has upgraded recently. Running xfce desktop.

19

(Just confirming that 7.0.9 does works on the Rasberry CM5 inside the laptop shell. I hope you manage to solve whatever broke on your Pi4).

20

I thought it would be ok. I have not had much time to look into it but I have installed multiple kernels, downgraded mesa, updated eeprom and downgraded raspberrypi-bootloaders. The errors seem to invilve lightdm and this in Xorg.log:

[ 20.011] (II) LoadModule: “glx”
[ 20.011] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 20.012] (EE)
[ 20.012] (EE) Backtrace:
[ 20.013] (EE) unw_get_proc_name failed: no unwind info found [-10]
[ 20.013] (EE) 0: /usr/lib/Xorg (?+0x0) [0xaaaaababc578]
[ 20.014] (EE) unw_get_proc_info failed: no unwind info found [-10]
[ 20.014] (EE)
[ 20.014] (EE) Segmentation fault at address 0x8
[ 20.014] (EE)
Fatal server error:
[ 20.014] (EE) Caught signal 11 (Segmentation fault). Server aborting
[ 20.014] (EE)
[ 20.014] (EE)
Please consult the The ``X.Org`` Foundation support
at ``http://wiki.x.org

The only thing graphics wise I see so far is librsvg that updated along with qt6-svg.