Ultimate cleanup of Debian/Ubuntu/POP OS/Elementary/whatever-is-using-APT and RPM based distros

In the previous exercise we have removed all the extra/unwanted/unneeded services from our distro, this time we are going to reclaim back some disk space.

First of all, why you might want to do this kind of cleanup?

We all know and laugh on Windows 10/11 disk requirements, right? But out-of-the-box Linux distros are becoming nothing better than it. And the reason for that is, distro teams are trying to squeeze as much as they can into the distribution, so most use cases will be covered. It might not sound like a bad idea, but what is the point for you, yes, specifically you, to have installed on your disk (and running as a daemon) such a thing as CUPS, if you don't even have a printer at home, right? Or having some graphical themes for your GRUB, when you don't care about bootloader beauty? Or having SNAP deamon installed and running, if you don't like vaping long-bearded hipsters and all the novelties and prefer your software to be installed from distro repo? Or why on earth you need to spare 300+ Mb on your hard drive to have "wireless-regdb" package (wireless regulatory database) for a system without WiFi?

As I mentioned, I do own an SBC which is running either off EMMC or off SD card. As you can imagine, the storage there is not endless. I wanted my OS to be as compact as it could be, without hurting much to its operation capabilities and not by paying a price of having a limited amount of applications. Quite the opposite - I want my free space to be used by the applications I use and by my own content (photos, music, videos). 

Secondly, the less free space you have on your solid state drive, no matter what generation it is, the less it will span. This might sound like a joke, unless you investigate that on your own, how SSD is operating and how writes are distributed across free blocks. Logic here is very simple, whenever you update something on your disk, the SSD controller will likely mark the storage cell occupied with your "old" data as clean, without actually cleaning it, and copy modified things around to a new storage cell. This approach is called "copy-on-write", and this is what all solid-state-drive controllers are doing, underneath the hood. So the less free space you have on your drive, the more pressure those free cells will get.

Before we begin

Your next best friend should be a tool like KDE Filelight or GNOME Baobab (recently was renamed to generic "Disk usage analyzer"). 

You open it up, and look very carefully what takes the most space on your drive. 

Delete apt cache

Unfortunately apt (a Debian-based distros package manager) has a bad habit of leaving the trash behind. It's just coded that way, so it first downloads the package to a local "cache"- your hard drive - and only then it installs it. And guess what? It doesn't give a shit to wipe out whatever remained after it. It's like if you never emptied your "Downloads" folder in Windows :) 

So we can do that manually:

apt-get autoclean
apt autoclean
apt clean

Compact the jorunal

Quite time ago, Linux distributions have switched from keeping a good old plain text log files under /var/log to something new and shiny. That something new was called journalctl. Basically that's a service which keeps up a binary log from whatever other service or software who wants to put something into system log. Binary here is a good thing in terms of space occupied, because it's using some kind of compression. But the bad thing about it, is that 90% of desktop Linux users don't even know how to look into those journalctl logs and they never do. 

If you're not a big fan of archeological digging into your old journalctl records from a month ago, I strongly suggest you to limit, how much logs can journalctl write to your hdd.

sudo journalctl --vacuum-size=100M

Delete extra locales

du -hs /usr/share/locale/*
find /usr/share/locale/ -type f -exec dpkg -S {} \; | sort -u

TODO https://serverfault.com/questions/394610/remove-a-locale-in-ubuntu/1037183#1037183

Delete extra kernels you don't need

First figure it out, what kernel you're running now:

uname -r

Check out what other kernels you have installed - the below directory usually gives a good indication about what amount of hdd is being used by kernel modules, so you can give it a second thought:

du -hs /usr/lib/modules/*

Then go ahead to remove all the kernels (and kernel-specific packages) you no longer need. Instead of 5.15.0-50 in the below example, use the kernel version from above, one by one:

apt list --installed "*5.15.0-50*"

# compose a list manually

apt purge <list of packages>

Delete snaps / flatpacks you don't use or alltogether

flatpak list

apt autoremove flatpak
rm -rf /var/lib/flatpak

snap list

apt autoremove snapd

rm -rf /usr/lib/snap

Remove the swapfile / swap partition

xxxx

Find and delete the fattest software

Unfortunately, I found no easy tool to use, how can you measure what is the storage impact of the packages you installed manually, considering all the dependencies it brought, when the dependencies are only needed to run that your package. All the GUI tools that are coming with various Desktop Environments are doing the same mistake - whenever they're calculating the size occupied by a package, they don't consider its dependencies.

So I had to make my own simple scrip: 

Debian-based distros

cat << EOF > /usr/local/bin/apt-space-used-by
#!/bin/sh
out=\$(apt-get --assume-no autoremove \$1 2>&1)
ec=\$?
if [ \$ec -eq 1 ] ; then
 size=\$(echo -n "\$out" | grep "After this operation" | cut -d' ' -f4-5)
 size=\$(echo \$size | sed -e "s/[^0-9kMG,.]//g" | tr 'k' 'K')
 echo -n "\$size\\t"
else
 echo -n "0 (cannot delete)"
fi
echo -n "\$1\\t"
dpkg-query -W -f='\${binary:Summary}\\n' \$1
EOF
chmod a+x /usr/local/bin/apt-space-used-by

# before we go any further we need to cleanout all the orphan pacakges, as they will be bothering our little script
apt autoremove

# now if you want to see what packages you installed manually will free what space
apt-mark showmanual | xargs -I % sh -c "apt-space-used-by %" | sort -h

# ... or whatever other packages which came with your distro
echo "" > /tmp/final_report.txt
dpkg-query -W -f='${binary:Package}\n' | xargs -I % sh -c "apt-space-used-by %" | tee -a /tmp/final_report.txt
cat /tmp/final_report.txt | sort -h

RHEL-based distros

cat << EOF > /usr/local/bin/yum-space-used-by
#!/bin/sh
out=$(yum --assumeno erase $1 2>&1)
echo -n "$out" | grep -qE "^Freed space:"
ec=$?
if [ $ec -eq 0 ] ; then
 size=$(echo -n "$out" | grep -E "^Freed space:" | cut -d' ' -f3-4)
 size=$(echo $size | sed -e "s/[^0-9kMG,.]//g" | tr 'k' 'K')
 echo -ne "$size\t"
else
 echo -ne "0 (cannot delete)"
fi
echo -ne "$1\t"
rpm -q --queryformat="%{SUMMARY}" $1
echo ""
EOF
chmod a+x /usr/local/bin/yum-space-used-by


# before we go any further we need to cleanout all the orphan pacakges, as they will be bothering our little script
yum autoremove

# now if you want to see what packages you installed manually will free what space
yum history userinstalled | grep -v "Packages installed by user" | xargs -I % sh -c "yum-space-used-by %" | sort -h

# ... or whatever other packages which came with your distro
echo "" > /tmp/final_report.txt
rpm -qa | xargs -I % sh -c "yum-space-used-by %" | tee -a /tmp/final_report.txt
cat /tmp/final_report.txt | sort -h

A word of caution regarding the last command. Imagine you have git installed. The "git" package brings with it a set of mandatory dependencies, it couldn't live without, like "git-man". So if you delete "git-man", it will also delete "git". This is why you will see some that both "git" and "git-man" packages will free up the same amount of disk space.

Once you figured out what you're ready to remove run:

apt autoremove <pacakgename>

Upsize your partitions

It might be the case, that you do have some unallocated space on your drive.  That's quite easy to fix. Imagine you have a disk (/dev/sda) with a single partition (/dev/sda1) and some free space after that partition. You first run lsblk to confirm what kind of layout you have, then you run parted and resize that 1st partition (/dev/sda1) to occupy 100% of remaining free space. And the cherry on a cake - you upsize the filesystem. That's it. Everything can be done online, without the need for reboot.

lsblk
parted /dev/sda
print all
resizepart 1 100%
resize2fs /dev/sda1

TODO

# remove dev packages you installed manually

apt-mark showmanual | grep -E "\-dev$" | awk '{system("sudo apt-get --dry-run purge "$1)}'

# remove 

It's safe to remove the content of your trashbin:
~/.local/share/Trash

See also what kind of programs you might have already deleted, but they left behind their traces:
~/.local/share

Like in my case I had some trails left by Konqueror (browser) I was experimenting with, and then used "apt remove" instead of "apt purge"
It's just me being not very carefull, but there's a good thing about it, we can pick up all such traces in one go:

dpkg --get-selections | awk '$2=="deinstall" {system("sudo apt-get --dry-run purge "$1)}'
dpkg --get-selections | awk '$2=="deinstall" {system("sudo apt-get -y purge "$1)}'

Total failure: trying to run Retroarch on Orange Pi 4 LTS using stock Linux "OrangePi OS 3.0.0" and Armbian

Retro Gaming on Orange Pi 4 LTS?

I was misfortune enough to buy a SBC (single board computer) called "Orange PI 4 LTS". At first, it looked very promissing - it was having quite a powerfull multicore cpu and built-in BT, WiFi, Ethernet, HDMI and had onboard 16 Gb eMMC chip flashed with some debian (or ARMbian) based linux called "Orange PI OS", but the vendor also provides custom builds of Debian, Ubuntu and Android. What could go wrong? I thought of myself as of experienced linux user, knowing my ways around and knowing how to google things.

The idea behind the purchase was to try this machine out for few simple tasks:

• self hosted photo service like Photoprism, Piwigo, Lychee, Plex, Librephotos or Nextcloud
• retro gaming device, so I could hook up couple of cheap bluetooth gamepads and play along with my little wee in console games I never played, because I had a PC from my first grade in school :)

The unfortunate thing I discovered, that most of the "retro gaming distros" (like Batocera, Recallbox, RetrOrangePi, Lakka) are not supporting this board, which is having ARM CPU Rockchip RK3399. To be entirely honest, some of them are having custom builds to support a very close SBC - RockPro64, which is also RK3399 based, but given it's having a different chip which implements Wifi and Bluetooth - I won't have thouse on my board. I also seen URLs for Orange PI 4 LTS builds on some forums/email threads, so I was bit optimistic.

I decided to start with retroarch, as essentially it's used in number of gaming distros, but eventually I don't like dedicated distros, like game dedicated distros, and having a general purpose distro which I can occasionally use for gaming was looking like a better option to me.

In this post i tried to summarize all the pain you have to walk through to get something like Retroarch working on this shitty machine.

Some Orange PI 4 LTS Specs

CPU RK3399 
4 Gb DDR4 RAM
16 Gb EMMC
WiFi 5 + Bluetooth provided by some rare chip CDW.20U5622-00
GPU Mali T860
• Supports OpenGL ES1.1/2.0/3.0/3.1,OpenVG1.1,OpenCL,DX11
• Support for AFBC

More specs here - http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/orange-pi-4-LTS.html

Official wiki - http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_4_LTS

Official PDF documentation - https://drive.google.com/file/d/1VnZOfpgrmUapTpcx77PhwJ808eCvkGrE/view?usp=sharing

Official linux images (and other downloads) - http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-pi-4-LTS.html

Stop reading it here

Hello there. It's older and wiser me speaking to you from future. Please don't take it close to heart whatever you'll read below. It was me just gaining my own experience with Linux @ desktop after a very very very long break of 15 years. 

 

Most of the problems I was having were eventually solved. Just read other posts from this blog, especially this and this.

An attempt to make it straightforward - "Retroarch on Orange Pi OS 3.0.0" - FAILED

At first I just installed Retroarch with APT and it didn't work. I mean it started up but then right after it was crashing. I had to play a bit and ran it from terminal with --verbose option to see what is going wrong. The trick was - that shitty Retroarch had installed its one config file to usual to me location like /etc/retroarch/retroarch.cfg but when I was running it under my own non-root user, it was generating a fucking new config file under ~/.config/retroarch/retroarch.cfg. So whatever changes I was trying under /etc/ were all wasted, because it wasn't even looking them up. Great job, retroarch developers! Why to bother to deploy that pesky config file in /etc/ with package first of all, if it's not even being used?

Anyways the issues with the retroarch running on out-of-box Orange Pi OS 3.0.0. were more or less overcame by:

• changing the default "skin" from "xmb" to "rgui". That was really unexpected thing
• setting the videodriver from "gl" to "sdl2"  (for some reason OpenGL drivers didn't quite work in that bollocks "Orange PI OS")

So I got at my hands very nice looking Retroarch, which appeared to me just a useless menu . No matter what librerto cores I tried - from internet, from apt - nothing worked. Every time it was the same shit - "segmentation fault", whenever I tried to run some game using retroarch core. I gave up trying

Another attempt to make it - other conventional emulators ("Higan on Orange PI OS") - SUCCEEDED

I was damned pissed off to see Higan and few other emulators I installed through apt were working just fine. Oh those retroarch developers, I love you. I don't know what kind of shit you were smoking, but its ain't for good.

So what then? I don't like the idea of using old-facioned window of Higan with my keyboard and mouse to start the game first, so I can use bluetooth gamepad for gaming. It's like I need to have 3 devices nearby after switching on the PC instead of having just one. So I still needed to make that shitty Retroarch (or any suitable replacement) to work

Retroarch flatpak on Orange PI OS - FAILED

At this point I started to think it might be something wrong with the retroarch package itself, given higan was working just fine. As I already learnt there were some signs to it, like not all the "skins" were working. I decided to give it a try and install it via modern blows-and-whistles thing called  "flatpack". By the way I love the idea, it's much more advanced compared to all regular package managers in distros and it's really a future of software distribution because it solves all this integration hell of ordinary linux distros. Here's what you need to do (see https://github.com/flathub/org.libretro.RetroArch):

flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak install --user -y flathub org.libretro.RetroArch
flatpak run org.libretro.RetroArch

./.var/app/org.libretro.RetroArch/config/retroarch/retroarch.cfg
core_updater_buildbot_cores_url = "https://buildbot.libretro.com/nightly/linux/armhf/latest/"
https://buildbot.libretro.com/nightly/android/latest/arm64-v8a/

The funny thing is, this version works just fine, but it also missing "cores". I tried few repos with retroarch cores, but coudln't find cores for ARM64 working with my linux anywhere on internet yet. 

Welcome to the fucking world of ARM, which is told to be a future of computer industry, but it's all again down to missing software and pesky linux compatibilities issues. I know exactly why ppl are stick to x86 - because of all this shit.

GLXInfo on Orange PI

orangepi@orangepi4-lts:~$ glxinfo | grep version

server glx version string: 1.4

client glx version string: 1.4

GLX version: 1.4

    Max core profile version: 4.5

    Max compat profile version: 3.1

    Max GLES1 profile version: 1.1

    Max GLES[23] profile version: 3.2

OpenGL core profile version string: 4.5 (Core Profile) Mesa 20.3.5

OpenGL core profile shading language version string: 4.50

OpenGL version string: 3.1 Mesa 20.3.5

OpenGL shading language version string: 1.40

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.3.5

OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

    GL_EXT_shader_implicit_conversions, GL_EXT_shader_integer_mix, 

Upgrade Mesa3d by building them from the very last source - FAILED

At some point I spoiled something with my videodrivers. Mesa drivers there kind a worked at the beginning, but then I started to have problems with them after a number of  experiments and additional packages being installed. Like initially glmark2-es2 tool was working, but then it stopped:

orangepi@orangepi4-lts:~$ glmark2-es2 
arm_release_ver of this libmali is 'r18p0-01rel0', rk_so_ver is '4'.Error: eglInitialize() failed with error: 0x3001
Error: eglInitialize() failed with error: 0x3001
Error: main: Could not initialize canvas

I thought there might be some relation to my failed attempts to make any of the libretro cores working in RetroArch (they all were failing with segfault), so I decided to attempt to upgrade that whole shitty Mesa3d drivers (follow https://docs.mesa3d.org/install.html for full instructions):
Install prereq:

apt install meson ninja-build
meson --version
ninja --version

Download and build mesa: (there might be newer version already)

cd
mkdir MESA
cd MESA
wget https://archive.mesa3d.org//mesa-22.1.5.tar.xz
tar xf mesa-22.1.5.tar.xz
rm mesa-22.1.5.tar.xz
# uncomment mnaually deb-src lines in /etc/apt/sources.list
apt-update
apt-get build-dep mesa
cd mesa-22.1.5/
mkdir installdir
export MESA_INSTALLDIR=`pwd`/installdir

# originally it was just
# meson builddir/ -Dprefix="$MESA_INSTALLDIR"
# but then I looked for panfrost support page - https://docs.mesa3d.org/drivers/panfrost.html
meson setup --wipe builddir/ -Dprefix="$MESA_INSTALLDIR" -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=panfrost -Dllvm=disabled
ninja -C builddir/ install
LD_LIBRARY_PATH="$MESA_INSTALLDIR/lib64" glxinfo

So the above fails on running "meson" (a kinda replacement for ./configure scripts in other open source projects) with this:

Dependency libdrm_nouveau found: NO found 2.4.104 but need: '>=2.4.109'
Run-time dependency libdrm_nouveau found: NO (tried cmake)

meson.build:1620:4: ERROR: Invalid version of dependency, need 'libdrm_nouveau' ['>=2.4.109'] found '2.4.104'.

A full log can be found at /home/orangepi/MESA/mesa-22.1.5/builddir/meson-logs/meson-log.txt

So in my shitty distro, the latest version of libdrm_nouveau is indeed 2.4.104 and given it's some kind of interface library of the actual shit which is compiled into kernel I cannot move ahead without updating kernel. I hate linux.

An attempt to install the most recent Armbian - SUCCESS

I have given up the idea of making that "Orange Pi OS 3.0.0" frankenstain to work, so I decided to flash an SD card with this armbian image to see if things are working fine there - https://www.armbian.com/orange-pi-4-lts/

It worked just fine, I managed to boot my Orange PI 4 LTS from SD card, to which I flashed the Armbian XFCE image with "balena etcher" exactly how instruction says. Te original "Orange PI OS" stayed on EMMC. I'll prob return to it bit later. The first thing I did is usual apt upgrade ; apt upgrade . Interestingly though, that the distro is having like zillion of different APT repos connected by default, and packages are coming to it from all over the place, like from Ubutntu, Armbian and handful of personal package archives (PPAs). So during that "apt upgrade" phase, some package attempted to override /etc/issue and /etc/issue.net files. Funny.

But now I got Armbian 22.05.4 running linux kernel 5.15-52

Checking OpenGL drivers on Armbian until I  mess with it

export DISPLAY=:0.0 glmark2 - works perfectly

root@orangepi4-lts:~# glxinfo | grep -i version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Version: 22.3.0
    Max core profile version: 3.1
    Max compat profile version: 3.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL core profile version string: 3.1 Mesa 22.3.0-devel (git-b731be2 2022-08-06 jammy-oibaf-ppa)
OpenGL core profile shading language version string: 1.40
OpenGL version string: 3.1 Mesa 22.3.0-devel (git-b731be2 2022-08-06 jammy-oibaf-ppa)
OpenGL shading language version string: 1.40
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 22.3.0-devel (git-b731be2 2022-08-06 jammy-oibaf-ppa)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
    GL_EXT_shader_implicit_conversions, GL_EXT_shader_integer_mix, 

Running RetroArch on Armbian - FAILED

It's not an entire failure thought. I manged to apt install it right from connected ubuntu repo, and it did startup even with that default "skin" (they call it "menu driver") which didn't work on "Orange PI OS". I installed some cores with apt:

$ apt list --installed | grep libretro-

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libretro-bsnes-mercury-accuracy/jammy,now 094+git20160126-3build1 arm64 [installed]
libretro-bsnes-mercury-performance/jammy,now 094+git20160126-3build1 arm64 [installed]
libretro-core-info/jammy,jammy,now 1.4.1+git20170210-1 all [installed]
libretro-snes9x/jammy,now 1.53+git20160522-1build1 arm64 [installed]

... but none of them working properly. It looks like this, whenver you attempt to run any game from retroarch, the app shuts down with this shit printed to console:

retroarch --verbose
...
[INFO] [GL]: VSync => on
[INFO] [EGL]: eglSwapInterval(1)
[INFO] Written to playlist file: /home/bugman/.config/retroarch/content_history.lpl
*** longjmp causes uninitialized stack frame ***: terminated
Aborted (core dumped)

Given the very last message in the log is related to VSync - I tried to switch that beast off, but it still getting printed like it's own. Oh those RetroArch developers. Another fucking bug. Did I tell you how I hate all that already?

Running Higan on Armbian - FAILED

This shit was very unexpected, because higan was working just perfectly in Orange PI OS. I installed it from apt and whenever I try to open a game ROM with it I get:

$ higan 

*** longjmp causes uninitialized stack frame ***: terminated

Aborted (core dumped)

I definitely need to investigate it further. Looks like on this Armbian the error message "longjmp causes uninitialized stack frame" is just the same as "segmentation  fault" on  Orange PI OS

I ran it under gdb and when it's about to crash the gdb prints this:

Thread 1 "higan" received signal SIGUSR1, User defined signal 1.

0x0000fffff6baf200 in ?? () from /lib/aarch64-linux-gnu/libc.so.6

And just in case, I tried to turn off audio and all possible combinations of Video driver (some of them were not working at all, like OpenGL).

Raised this one - https://github.com/higan-emu/higan/issues/190

The version I have on Armbian is:

$ apt policy higan

higan:

  Installed: 106-2build2

  Candidate: 106-2build2

  Version table:

 *** 106-2build2 500

        500 http://ports.ubuntu.com jammy/universe arm64 Packages

        100 /var/lib/dpkg/status

Building higan from sources - IN PROGRESS

wget https://github.com/higan-emu/higan/archive/refs/tags/v110.zip

unzip v110.zip

apt-get install build-essential libgtk2.0-dev libpulse-dev \

    mesa-common-dev libgtksourceview-3.0-dev libcairo2-dev libsdl1.2-dev \

    libxv-dev libao-dev libopenal-dev libudev-dev

(it actually requires gtksourceview-2.0 - but it's not in APT repos, so with 3rd version it doesn't compile)

root@orangepi4-lts:~# cd /tmp/higan-110/

root@orangepi4-lts:/tmp/higan-110# make -C higan

make: Entering directory '/tmp/higan-110/higan'

Targeting higan ...

make: sdl2-config: No such file or directory

make: sdl2-config: No such file or directory

Compiling ../hiro/hiro.cpp ...

Package gtksourceview-2.0 was not found in the pkg-config search path.

Perhaps you should add the directory containing `gtksourceview-2.0.pc'

to the PKG_CONFIG_PATH environment variable

No package 'gtksourceview-2.0' found

In file included from ../hiro/core/core.cpp:8,

                 from ../hiro/hiro.cpp:5:

../hiro/core/../gtk/header.hpp:34:12: fatal error: cairo.h: No such file or directory

   34 |   #include <cairo.h>

      |            ^~~~~~~~~

compilation terminated.

make: *** [../hiro/GNUmakefile:73: obj/hiro-gtk2.o] Error 1

make: Leaving directory '/tmp/higan-110/higan'

Need to find that lib or its replacement, or to take the same version installed to my system (v106 instead of v110). This is also what I got as a reply to my https://github.com/higan-emu/higan/issues/190 ticket - to build it myself

Building MESA/panfrost on Armbian

As days are passing by, I'm getting more and more knowledge about all this videodrivers topic. I was given with a good lead, that Orange PI OS is using Mali drivers in MESA, not the Panfrost ones. I checked what kind of drivers are used now in Armbian - and it was Panfrost, but the version of Mali itself was bit worrying 22.3.0-devel 

Thus I decided to take my chance and build Mesa once again, this time all libraries were there and I managed to do that. Here're the comparison results of Mesa 22.3.0-devel (the  one, which came out of the box) and the version I've built - 22.1.5:

bugman@orangepi4-lts:~/MESA/mesa-22.1.5$ LD_LIBRARY_PATH="$MESA_INSTALLDIR/lib/aarch64-linux-gnu/" glmark2 

=======================================================

    glmark2 2021.02

=======================================================

    OpenGL Information

    GL_VENDOR:     Panfrost

    GL_RENDERER:   Mali-T860 (Panfrost)

    GL_VERSION:    3.1 Mesa 22.1.5

=======================================================

[build] use-vbo=false: FPS: 114 FrameTime: 8.772 ms

[build] use-vbo=true: FPS: 129 FrameTime: 7.752 ms

[texture] texture-filter=nearest: FPS: 144 FrameTime: 6.944 ms

[texture] texture-filter=linear: FPS: 119 FrameTime: 8.403 ms

[texture] texture-filter=mipmap: FPS: 126 FrameTime: 7.937 ms

[shading] shading=gouraud: FPS: 125 FrameTime: 8.000 ms

[shading] shading=blinn-phong-inf: FPS: 131 FrameTime: 7.634 ms

[shading] shading=phong: FPS: 114 FrameTime: 8.772 ms

[shading] shading=cel: FPS: 146 FrameTime: 6.849 ms

[bump] bump-render=high-poly: FPS: 138 FrameTime: 7.246 ms

[bump] bump-render=normals: FPS: 143 FrameTime: 6.993 ms

[bump] bump-render=height: FPS: 166 FrameTime: 6.024 ms

[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 141 FrameTime: 7.092 ms

[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 131 FrameTime: 7.634 ms

[pulsar] light=false:quads=5:texture=false: FPS: 139 FrameTime: 7.194 ms

[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 119 FrameTime: 8.403 ms

[desktop] effect=shadow:windows=4: FPS: 126 FrameTime: 7.937 ms

[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 118 FrameTime: 8.475 ms

[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 119 FrameTime: 8.403 ms

[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 119 FrameTime: 8.403 ms

[ideas] speed=duration: FPS: 120 FrameTime: 8.333 ms

[jellyfish] <default>: FPS: 132 FrameTime: 7.576 ms

[terrain] <default>: FPS: 27 FrameTime: 37.037 ms

[shadow] <default>: FPS: 126 FrameTime: 7.937 ms

[refract] <default>: FPS: 57 FrameTime: 17.544 ms

[conditionals] fragment-steps=0:vertex-steps=0: FPS: 175 FrameTime: 5.714 ms

[conditionals] fragment-steps=5:vertex-steps=0: FPS: 160 FrameTime: 6.250 ms

[conditionals] fragment-steps=0:vertex-steps=5: FPS: 164 FrameTime: 6.098 ms

[function] fragment-complexity=low:fragment-steps=5: FPS: 156 FrameTime: 6.410 ms

[function] fragment-complexity=medium:fragment-steps=5: FPS: 123 FrameTime: 8.130 ms

[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 135 FrameTime: 7.407 ms

[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 154 FrameTime: 6.494 ms

[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 119 FrameTime: 8.403 ms

=======================================================

                                  glmark2 Score: 128 

=======================================================

bugman@orangepi4-lts:~/MESA/mesa-22.1.5$ glmark2 

=======================================================

    glmark2 2021.02

=======================================================

    OpenGL Information

    GL_VENDOR:     Panfrost

    GL_RENDERER:   Mali-T860 (Panfrost)

    GL_VERSION:    3.1 Mesa 22.3.0-devel (git-8bffd60 2022-08-08 jammy-oibaf-ppa)

=======================================================

[build] use-vbo=false: FPS: 114 FrameTime: 8.772 ms

[build] use-vbo=true: FPS: 136 FrameTime: 7.353 ms

[texture] texture-filter=nearest: FPS: 185 FrameTime: 5.405 ms

[texture] texture-filter=linear: FPS: 170 FrameTime: 5.882 ms

[texture] texture-filter=mipmap: FPS: 158 FrameTime: 6.329 ms

[shading] shading=gouraud: FPS: 148 FrameTime: 6.757 ms

[shading] shading=blinn-phong-inf: FPS: 141 FrameTime: 7.092 ms

[shading] shading=phong: FPS: 142 FrameTime: 7.042 ms

[shading] shading=cel: FPS: 150 FrameTime: 6.667 ms

[bump] bump-render=high-poly: FPS: 149 FrameTime: 6.711 ms

[bump] bump-render=normals: FPS: 140 FrameTime: 7.143 ms

[bump] bump-render=height: FPS: 120 FrameTime: 8.333 ms

[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 134 FrameTime: 7.463 ms

[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 160 FrameTime: 6.250 ms

[pulsar] light=false:quads=5:texture=false: FPS: 124 FrameTime: 8.065 ms

[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 119 FrameTime: 8.403 ms

[desktop] effect=shadow:windows=4: FPS: 119 FrameTime: 8.403 ms

[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 119 FrameTime: 8.403 ms

[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 119 FrameTime: 8.403 ms

[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 119 FrameTime: 8.403 ms

[ideas] speed=duration: FPS: 120 FrameTime: 8.333 ms

[jellyfish] <default>: FPS: 129 FrameTime: 7.752 ms

[terrain] <default>: FPS: 27 FrameTime: 37.037 ms

[shadow] <default>: FPS: 114 FrameTime: 8.772 ms

[refract] <default>: FPS: 59 FrameTime: 16.949 ms

[conditionals] fragment-steps=0:vertex-steps=0: FPS: 119 FrameTime: 8.403 ms

[conditionals] fragment-steps=5:vertex-steps=0: FPS: 123 FrameTime: 8.130 ms

[conditionals] fragment-steps=0:vertex-steps=5: FPS: 153 FrameTime: 6.536 ms

[function] fragment-complexity=low:fragment-steps=5: FPS: 151 FrameTime: 6.623 ms

[function] fragment-complexity=medium:fragment-steps=5: FPS: 152 FrameTime: 6.579 ms

[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 135 FrameTime: 7.407 ms

[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 160 FrameTime: 6.250 ms

[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 153 FrameTime: 6.536 ms

=======================================================

                                  glmark2 Score: 132 

=======================================================

As you can see, -devel drivers are giving slightly better performance, but it was just a single run of benchmark. But from the outcome perspective, it didn't change a bit - both higan and retroarch are keep failing the same way they did with "longjmp causes uninitialized stack frame".

Sidenote - some flags you can affect MESA drivers

https://docs.mesa3d.org/envvars.html

Sidenote on using Bluetooth joystick/gamepad on Linux

evtest - can be installed from packages, a handy tool to make sure your Bluetooth joystick / gamepad works fine. Mine was working fine and was found under /dev/input/event10

I prefer to test hardware in some lightweight dedicated testing tools like this, to make sure at least it can be detected and works normally, before moving to something bigger. I quite frequent google things like "how to ensure X is working?" or "how can I get to know B is being detected". This whole topic is very new to me, as I was running Linux on servers for a couple decades, but my desktop experience with all the desktop grade hardware like printers, scanners, usb camers, videocards, bluetooth and wifi is very limited

Surprisingly my own Bluetooth gamepads (some $15 cheap Defenders) were successfully paired in linux and were working just fine.

retrorangepi

https://pcminipro.ru/os/pervyj-zapusk-i-pervaya-nastrojka-retrorangepi/ [ERROR] [XVideo]: Failed to find valid XvPort or format. libmali-midgard-t86x-r18p0-x11/now 1.9-1 arm64 [installed,local]

Sidenote on why I hate APT so much or accidental removal of important packages I cannot reinstall

Be careful while using shity debian-based distros with its shitty apt. I installed some package (can't even remember what) via apt and installed all the dependencies. They all were listed in apt log on a screen. So far so good. But later I decided to remove that package, but dependencies it installed before were not removed. I took them from the log and ran "apt remove xxx xxx" command. What happened then, it started to remove some extra packages I didn't ask him to, like below mentioned "orangepi-config". The issue was is that the shitty "Orange Pi OS" distro doesn't have all its packages in the repo, so there's no chance to restore it back with using apt again.

root@orangepi4-lts:~# apt remove libsdl2-dev libboost-system-dev libboost-filesystem-dev libboost-date-time-dev libboost-locale-dev libfreeimage-dev libfreetype6-dev libeigen3-dev libcurl4-openssl-dev libasound2-dev libgl1-mesa-dev build-essential cmake fonts-droid-fallback
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  cmake-data g++ g++-10 gir1.2-ibus-1.0 libblkid-dev libboost-atomic1.74-dev libboost-atomic1.74.0 libboost-chrono1.74-dev libboost-chrono1.74.0 libboost-date-time1.74-dev libboost-date-time1.74.0 libboost-filesystem1.74-dev
  libboost-filesystem1.74.0 libboost-locale1.74-dev libboost-locale1.74.0 libboost-serialization1.74-dev libboost-serialization1.74.0 libboost-system1.74-dev libboost-system1.74.0 libboost-thread1.74-dev libboost-thread1.74.0
  libboost1.74-dev libbrotli-dev libdbus-1-dev libegl1-mesa-dev libffi-dev libfreeimage3 libfreetype-dev libgles-dev libgles1 libglib2.0-dev libglib2.0-dev-bin libglvnd-dev libibus-1.0-5 libibus-1.0-dev libice-dev libilmbase25
  libirrlicht1.8 libjxr0 libleveldb1d liblua5.1-0 libmount-dev libopenexr25 libopengl-dev libopengl0 libpcre16-3 libpcre2-dev libpcre2-posix2 libpcre3-dev libpcre32-3 libpcrecpp0v5 libpng-dev libpq5 libpulse-dev libraw20 librhash0
  libselinux1-dev libsepol1-dev libsm-dev libsndio-dev libspatialindex6 libstdc++-10-dev libudev-dev libwayland-bin libwayland-dev libxcursor-dev libxfixes-dev libxi-dev libxinerama-dev libxkbcommon-dev libxrandr-dev libxrender-dev
  libxss-dev libxt-dev libxv-dev libxxf86vm-dev python3-distutils python3-lib2to3 uuid-dev x11proto-input-dev x11proto-randr-dev x11proto-scrnsaver-dev x11proto-xf86vidmode-dev x11proto-xinerama-dev zlib1g-dev
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  build-essential cmake fonts-droid-fallback libasound2-dev libboost-date-time-dev libboost-filesystem-dev libboost-locale-dev libboost-system-dev libcurl4-openssl-dev libeigen3-dev libfreeimage-dev libfreetype6-dev libgl1-mesa-dev
  libsdl2-dev minetest minetest-data orangepi-config
0 upgraded, 0 newly installed, 17 to remove and 0 not upgraded.
After this operation, 73.3 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 205716 files and directories currently installed.)
Removing orangepi-config (3.0.0) ...
Removing build-essential (12.9) ...
Removing cmake (3.18.4-2+deb11u1) ...
Removing minetest (5.3.0+repack-2.1+deb11u1) ...
Removing minetest-data (5.3.0+repack-2.1+deb11u1) ...
Removing fonts-droid-fallback (1:6.0.1r16-1.1) ...
Removing libsdl2-dev:arm64 (2.0.14+dfsg2-3+deb11u1) ...
Removing libasound2-dev:arm64 (1.2.4-1.1) ...
Removing libboost-date-time-dev:arm64 (1.74.0.3) ...
Removing libboost-filesystem-dev:arm64 (1.74.0.3) ...
Removing libboost-locale-dev:arm64 (1.74.0.3) ...
Removing libboost-system-dev:arm64 (1.74.0.3) ...
Removing libcurl4-openssl-dev:arm64 (7.74.0-1.3+deb11u2) ...
Removing libeigen3-dev (3.3.9-2) ...
Removing libfreeimage-dev (3.18.0+ds2-6) ...
Removing libfreetype6-dev:arm64 (2.10.4+dfsg-1+deb11u1) ...
Removing libgl1-mesa-dev:arm64 (20.3.5-1) ...
Processing triggers for bamfdaemon (0.5.4-2) ...
Rebuilding /usr/share/applications/bamf-2.index...
Processing triggers for desktop-file-utils (0.26-1) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for gnome-menus (3.36.0-1) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for mailcap (3.69) ...
Processing triggers for fontconfig (2.13.1-4.2) ...
^C

Adding keys for PPA

If your apt is complaining on not being able to verify the key of the repo you just added to /etc/apt/sources.list or /etc/apt/sources.list.d/ like this:

GPG error: http://armbian.12z.eu/apt buster InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 93D6889F9F0E78D5

... the easiest would be to open that repo in your web browser to see if there's a key file lying around somewhere on a top, it should be named like something.key. Download that file and run:

apt-key add ~orangepi/Downloads/armbian.key

Now you're free to run your apt command once again.