Your system is unsupported - SparkyLinux 7.1 RC1

[RoonMoonlight]

Confirmations

• I searched for similar bug reports in https://github.com/Botspot/pi-apps/issues and found none were relevant.
• I tried updating Pi-Apps and the issue is still not fixed. How to update Pi-Apps?
• IMPORTANT: I promise to respond to comments on this issue and write a good bug report https://www.softwaretestinghelp.com/how-to-write-good-bug-report/

What happened?

Although it fully supports feature from Raspberry Pi OS, Pi-Apps thinks that the system is unsupported and displays warning message.

Description

SparkyLinux recently added support for Raspberry Pi, based on Raspberry Pi OS with SparkyLinux's own features. The latest version is 7.1 RC1, based on Raspberry Pi OS Lite with Sparky feature installed. Although it completely supports feature that is used by Pi-Apps, the app things that the system is broken and displays warning that the system is unsupported on first run.

What are your system specs (run the following command in your terminal)?

OS: SparkyLinux 7.1 (Orion-Belt)
OS architecture: 64-bit
Last updated Pi-Apps on: 11/12/2023
Latest Pi-Apps version: 11/12/2023
Kernel: aarch64 6.1.0-rpi6-rpi-v8
Device: Raspberry Pi 4 Model B Rev 1.5
SOC identifier: bcm2711
RAM size: 1.84 GB
Raspberry Pi OS image version:
Language: en_US.UTF-8

(Recommended) Error log? Terminal output? Debug messages?

YOUR SYSTEM IS UNSUPPORTED:
Congratulations, Linux tinkerer, you broke your system. You have made your system a FrankenDebian.
This website explains your mistake in more detail: https://wiki.debian.org/DontBreakDebian
Your current reported release (N/a) should not be combined with other releases.

[github-actions]

Hello there 👋
Thanks for submitting your first issue to the Pi-Apps project! We'll try to get back to you as soon as possible.
In the meantime, we encourage you join our Discord server, where you can ask any questions you might have.

Please respond as soon as possible if a Pi-Apps maintainer requests more information from you. Stale issues will be closed after a lengthy period of time with no response.

[theofficialgman]

You should go tell SparkyLinux that they need to fix their lsb-release package. it does not return a compatible codename (see the "N/a" in your report). This is a requirement to query the information about a distribution and we will not be adding "hacks" around bad non-compliant distributions.

Pi-Apps is warning you of the problem and your distro should correct it.

[RoonMoonlight]

I got update from the SparkyLinux author Pawol Pavroo, they are not even going to fix it as well... What should I do now?

[theofficialgman]

I got update from the SparkyLinux author Pawol Pavroo, they are not even going to fix it as well... What should I do now?

Copy paste and send them this or just link them this post.

SparkyLinux needs to fix their lsb-release package. it currently returns N/a to our variable __os_codename. Please refer to

pi-apps/api

Lines 3252 to 3305 in 08e8643

	# first check if lsb_release has an upstream option -u
	# if not, check if there is an upstream-release file
	# if not, check if there is a lsb-release.diverted file
	# if not, assume that this is not a ubuntu derivative
	# use mapfile to temporarily store release info for speed
	if [ -z "$__os_id" ] || [ -z "$__os_desc" ] || [ -z "$__os_release" ] || [ -z "$__os_codename" ]; then
	if lsb_release -a -u &>/dev/null; then
	# This is a Ubuntu Derivative, checking the upstream-release version info
	mapfile -t os_u < <(lsb_release -s -i -d -r -c -u)
	export __os_id="${os_u[0]}"
	export __os_desc="${os_u[1]}"
	export __os_release="${os_u[2]}"
	export __os_codename="${os_u[3]}"
	mapfile -t os < <(lsb_release -s -i -d -r -c)
	export __os_original_id="${os[0]}"
	export __os_original_desc="${os[1]}"
	export __os_original_release="${os[2]}"
	export __os_original_codename="${os[3]}"
	elif [ -f /etc/upstream-release/lsb-release ]; then
	# ubuntu 22.04+ Linux Mint no longer includes the lsb_release -u option
	# add a parser for the /etc/upstream-release/lsb-release file
	source /etc/upstream-release/lsb-release
	export __os_id="$DISTRIB_ID"
	export __os_desc="$DISTRIB_DESCRIPTION"
	export __os_release="$DISTRIB_RELEASE"
	export __os_codename="$DISTRIB_CODENAME"
	mapfile -t os < <(lsb_release -s -i -d -r -c)
	export __os_original_id="${os[0]}"
	export __os_original_desc="${os[1]}"
	export __os_original_release="${os[2]}"
	export __os_original_codename="${os[3]}"
	unset DISTRIB_ID DISTRIB_DESCRIPTION DISTRIB_RELEASE DISTRIB_CODENAME
	elif [ -f /etc/lsb-release.diverted ]; then
	# ubuntu 22.04+ Pop!_OS no longer includes the /etc/upstream-release/lsb-release or the lsb_release -u option
	# add a parser for the new /etc/lsb-release.diverted file
	source /etc/lsb-release.diverted
	export __os_id="$DISTRIB_ID"
	export __os_desc="$DISTRIB_DESCRIPTION"
	export __os_release="$DISTRIB_RELEASE"
	export __os_codename="$DISTRIB_CODENAME"
	mapfile -t os < <(lsb_release -s -i -d -r -c)
	export __os_original_id="${os[0]}"
	export __os_original_desc="${os[1]}"
	export __os_original_release="${os[2]}"
	export __os_original_codename="${os[3]}"
	unset DISTRIB_ID DISTRIB_DESCRIPTION DISTRIB_RELEASE DISTRIB_CODENAME
	else
	mapfile -t os < <(lsb_release -s -i -d -r -c)
	export __os_id="${os[0]}"
	export __os_desc="${os[1]}"
	export __os_release="${os[2]}"
	export __os_codename="${os[3]}"
	fi
	fi

for more information on how this is set and what is expected output for distributions.

[theofficialgman]

Anyway the issue is very clear
They replace the /usr/lib/os-release file with their own contents but did not write in it the required output for lsb_release to parse. There is NO fix we can do for this on our end or want to do. This is a distro maintainer problem and they should fix it.

lsb_release code that obtains the info and returns the output:

# Load release info from standard identification data files
[ -f /usr/lib/os-release ] && os_release=/usr/lib/os-release
[ -f /etc/os-release ] && os_release=/etc/os-release
[ "${LSB_OS_RELEASE-x}" != "x" ] && [ -f "$LSB_OS_RELEASE" ] && os_release="$LSB_OS_RELEASE"
[ "${os_release-x}" != "x" ] && . "$os_release"

...

if $show_codename ; then
	display_line "Codename" "${VERSION_CODENAME:-n/a}"
fi

sparky bad os-release info

PRETTY_NAME="SparkyLinux 7.1 (Orion-Belt)"
NAME="SparkyLinux"
VERSION_ID="7.1"
VERSION="7.1 (Orion-Belt)"
ID=sparky
ID_LIKE=debian
HOME_URL="https://sparkylinux.org/"
SUPPORT_URL="https://sparkylinux.org/forum/"
BUG_REPORT_URL="https://sourceforge.net/p/sparkylinux/tickets"

as you can clearly see, there is NO VERSION_CODENAME variable in their file, hence why the output is n/a

additionally, since sparky is modifying the ID from debian to sparky as well as the VERSION_ID from 12 to 7.1 they really should be putting VERSION_CODENAME as Orion-Belt (their "custom" name that they list already). The original distribution derived (bookworm) os-release information should then be provided in another location like is done in Pop!_OS or Linux Mint in either /etc/upstream-release/lsb-release or /etc/lsb-release.diverted file locations with an example of the correct information shown below:

DISTRIB_ID=Debian
DISTRIB_RELEASE=12
DISTRIB_CODENAME=bookworm
DISTRIB_DESCRIPTION="Debian GNU/Linux 12 (bookworm)"

[Botspot]

@RoonMoonlight, maybe also try sending the link of this github issue to the author of SparkyLinux. If you have not already done this, it might help.

[pavroo]

updated sparky's base-file and added upstream's lsb-release
will see...

[RoonMoonlight]

Thanks! Hope Pi-Apps should work better now...