kubuntu shows "bookworm/sid" instead of 22.04

[ask-compu]

Describe the bug

for the OS line instead of showing Kubuntu 22.04.4 (jammy) it shows Kubuntu bookworm/sid (jammy)

• [YES] Does this issue still occur in the master branch? (Required)

Expected behavior

A clear and concise description of what you expected to happen. show Kubuntu 22.04.4 (jammy)

Screenshots

Please include a screenshot of your system information if the specific system environment is relevant to the bug.

If applicable, add screenshots to help explain your problem.

Config file

1. Run cp ~/.config/neofetch/config.conf conf.txt
2. Drag conf.txt here to upload it. conf.txt

Verbose log

1. Run neofetch -vv 2> neofetch.log
2. Drag neofetch.log here to upload it. neofetch.log

Additional context

Add any other context about the problem here.

[bigcalm]

The same issue is also present on stock Ubuntu 24.04 (Gnome):

[ethanholt1]

Just a prediction, I did a quick skim of the code and couldn't find the code that detects version, but I'm assuming this is it not detecting the later versions of Ubuntu as Debian for some reason, specifically the rolling release? Could be related to the fact that Ubuntu is an upstream of Debian. This might be more of a Ubuntu thing but there could be a quick fix that could be implemented.

Edit: Most likely, this is the program detecting an etc/debian_version file (which reports bookworm/sid as its version, since that's what every Ubuntu since 22 is based on) inside an Ubuntu instance, and assuming the install to be Debian. I could be wrong though.

[ask-compu]

the code that detects the version would be in the updated neofetch implementation, hyfetch seems to run this in the background and modify the output to have the correct colors

[ask-compu]

here is where it detects the ubuntu flavor, for example https://github.com/hykilpikonna/hyfetch/blob/master/neofetch#L1388

[ethanholt1]

I believe the issue is on line 1202 of the "neofetch" file. While I don't have a Kubuntu install standing by to test this, I believe that lsb_release -sd would give out "bookworm/sid" instead of the 22.04 that we're looking for, while -sv would print out 22.04. If this would work, I'll make a PR for it.

[ask-compu]

i run kubuntu, here's the results of those 2 commands

[ethanholt1]

i run kubuntu, here's the results of those 2 commands

Hmm, could you try -sr?

[ask-compu]

here ya go

[ethanholt1]

here ya go

I believe that's what we're looking for. I'll make a PR and the owner can judge if this would fix it. Thanks for your help! Edit: Upon closer inspection, I don't believe that would fix it. I'll keep looking into it and make a pull when I've found a solution.

[ask-compu]

here ya go

I believe that's what we're looking for. I'll make a PR and the owner can judge if this would fix it. Thanks for your help! Edit: Upon closer inspection, I don't believe that would fix it. I'll keep looking into it and make a pull when I've found a solution.

need to figure out what command in ubuntu gives that bookworm/sid response

[ethanholt1]

need to figure out what command in ubuntu gives that bookworm/sid response

It's possible it could still be pulling from the etc/debian_version file, because it may be incorrectly detecting Kubuntu as not Ubuntu and therefore using the Debian checks. Can you cat /etc/debian_version and also run lsb_release -si? Edit: Could also be related to /etc/os_release.

[ask-compu]

aha! i found it! it's retrieved from the file /etc/debian_version

Kubuntu 22.04 has this file and it's contents r bookworm/sid

[ask-compu]

need to figure out what command in ubuntu gives that bookworm/sid response

It's possible it could still be pulling from the etc/debian_version file, because it may be incorrectly detecting Kubuntu as not Ubuntu and therefore using the Debian checks. Can you cat /etc/debian_version and also run lsb_release -si?

[ask-compu]

need to figure out what command in ubuntu gives that bookworm/sid response

It's possible it could still be pulling from the etc/debian_version file, because it may be incorrectly detecting Kubuntu as not Ubuntu and therefore using the Debian checks. Can you cat /etc/debian_version and also run lsb_release -si? Edit: Could also be related to /etc/os_release.

hmmm i ran

                if [[ -f /etc/debian_version ]] && [[ $(lsb_release -si) != *"buntu"* ]]; then
                    . /etc/os-release
                    case $distro_shorthand in
                        on)   distro="${NAME}" ;;
                        tiny) distro="$(lsb_release -si)" ;;
                        *)    distro="${NAME} $(< /etc/debian_version) (${VERSION_CODENAME})" ;;
                    esac
                else
                    case $distro_shorthand in
                        on)   lsb_flags=-si ;;
                        tiny) lsb_flags=-si ;;
                        *)    lsb_flags=-sd ;;
                    esac
                    distro=$(lsb_release "$lsb_flags")
                fi
echo $distro

as it's own script and it resulted in Ubuntu 22.04.4 LTS

[ethanholt1]

aha! i found it! it's retrieved from the file /etc/debian_version

Kubuntu 22.04 has this file and it's contents r bookworm/sid

Okay, so it is incorrectly detecting Kubuntu as not Ubuntu. I could add a pattern to that first case statement, looking for buntu (space added because markdown) in the distro_shorthand, and if it detects that, set distro as lsb_release -sd?

[ask-compu]

need to figure out what command in ubuntu gives that bookworm/sid response

It's possible it could still be pulling from the etc/debian_version file, because it may be incorrectly detecting Kubuntu as not Ubuntu and therefore using the Debian checks. Can you cat /etc/debian_version and also run lsb_release -si? Edit: Could also be related to /etc/os_release.

hmmm i ran

                if [[ -f /etc/debian_version ]] && [[ $(lsb_release -si) != *"buntu"* ]]; then
                    . /etc/os-release
                    case $distro_shorthand in
                        on)   distro="${NAME}" ;;
                        tiny) distro="$(lsb_release -si)" ;;
                        *)    distro="${NAME} $(< /etc/debian_version) (${VERSION_CODENAME})" ;;
                    esac
                else
                    case $distro_shorthand in
                        on)   lsb_flags=-si ;;
                        tiny) lsb_flags=-si ;;
                        *)    lsb_flags=-sd ;;
                    esac
                    distro=$(lsb_release "$lsb_flags")
                fi
echo $distro

as it's own script and it resulted in Ubuntu 22.04.4 LTS

modified this further to check whether the if results in true or not

                if [[ -f /etc/debian_version ]] && [[ $(lsb_release -si) != *"buntu"* ]]; then
                    . /etc/os-release
                    echo "not ubuntu"
                    case $distro_shorthand in
                        on)   distro="${NAME}" ;;
                        tiny) distro="$(lsb_release -si)" ;;
                        *)    distro="${NAME} $(< /etc/debian_version) (${VERSION_CODENAME})" ;;
                    esac
                else
                    echo "ubuntu"
                    case $distro_shorthand in
                        on)   lsb_flags=-si ;;
                        tiny) lsb_flags=-si ;;
                        *)    lsb_flags=-sd ;;
                    esac
                    distro=$(lsb_release "$lsb_flags")
                fi
echo $distro

results in

ubuntu
Ubuntu 22.04.4 LTS

so the script SHOULD be detecting ubuntu correctly

[ethanholt1]

so the script SHOULD be detecting ubuntu correctly

Okay, so it could be related to where the version string is assembled, but I also don't know where that happens. It's quite confusing. It could maybe even be related to where the Ubuntu flavor is detected? I don't think it would be though, as that's setting it to hardcoded strings and isn't pulling anything from anywhere.

[ask-compu]

so the script SHOULD be detecting ubuntu correctly

Okay, so it could be related to where the version string is assembled, but I also don't know where that happens. It's quite confusing. It could maybe even be related to where the Ubuntu flavor is detected? I don't think it would be though, as that's setting it to hardcoded strings and isn't pulling anything from anywhere.

wait but if i manually make that if statement be true

                if true; then
                    . /etc/os-release
                    echo "not ubuntu"
                    case $distro_shorthand in
                        on)   distro="${NAME}" ;;
                        tiny) distro="$(lsb_release -si)" ;;
                        *)    distro="${NAME} $(< /etc/debian_version) (${VERSION_CODENAME})" ;;
                    esac
                else
                    echo "ubuntu"
                    case $distro_shorthand in
                        on)   lsb_flags=-si ;;
                        tiny) lsb_flags=-si ;;
                        *)    lsb_flags=-sd ;;
                    esac
                    distro=$(lsb_release "$lsb_flags")
                fi
echo $distro

then it results in the output neofetch seems to be giving

not ubuntu
Ubuntu bookworm/sid (jammy)

[ethanholt1]

then it results in the output neofetch seems to be giving

not ubuntu

Ubuntu bookworm/sid (jammy)

So the issue is within that if statement, then. Maybe if you remove that second asterisk from != *"buntu"* it would run as intended. I believe wild cards in Bash don't include nothing, I think?

[ask-compu]

then it results in the output neofetch seems to be giving

not ubuntu

Ubuntu bookworm/sid (jammy)

So the issue is within that if statement, then. Maybe if you remove that second asterisk from '!= "buntu "'it would run as intended. I believe wild cards in Bash don't include nothing, I think?

but the problem is if i run it as is outside of the neofetch script it gives the correct result, it only gives the incorrect result if i force the if statement to be true, and i'm running it via bash script.sh

[ethanholt1]

then it results in the output neofetch seems to be giving

not ubuntu

Ubuntu bookworm/sid (jammy)

So the issue is within that if statement, then. Maybe if you remove that second asterisk from '!= "buntu "'it would run as intended. I believe wild cards in Bash don't include nothing, I think?

but the problem is if i run it as is outside of the neofetch script it gives the correct result, it only gives the incorrect result if i force the if statement to be true, and i'm running it via bash script.sh

This might be a crackpot theory, but maybe if you force the script to run in Bash instead of just sh (via #!/bin/bash) it may work as intended. Try running the script as normal with sh and Bash and see if they return the same thing.

Bash is very strange with the single and double brackets.

[ask-compu]

then it results in the output neofetch seems to be giving

not ubuntu

Ubuntu bookworm/sid (jammy)

So the issue is within that if statement, then. Maybe if you remove that second asterisk from '!= "buntu "'it would run as intended. I believe wild cards in Bash don't include nothing, I think?

but the problem is if i run it as is outside of the neofetch script it gives the correct result, it only gives the incorrect result if i force the if statement to be true, and i'm running it via bash script.sh

This might be a crackpot theory, but maybe if you force the script to run in Bash instead of just sh (via #!/bin/bash) it may work as intended. Try running the script as normal with sh and Bash and see if they return the same thing.

hmm the neowofetch script has a bunch of header stuff

#!/usr/bin/env bash
# vim: noai:ts=4:sw=4:expandtab
# shellcheck source=/dev/null
# shellcheck disable=2009 disable=2153 disable=2154 disable=2243 disable=2244 disable=2317

i'm gonna try adding all of this to the top of my test script and then running it via ./script.sh

[ask-compu]

ok here's the script i'm testing with now

#!/usr/bin/env bash
# vim: noai:ts=4:sw=4:expandtab
# shellcheck source=/dev/null
# shellcheck disable=2009 disable=2153 disable=2154 disable=2243 disable=2244 disable=2317
                if [[ -f /etc/debian_version ]] && [[ $(lsb_release -si) != *"buntu"* ]]; then
                    . /etc/os-release
                    echo "not ubuntu"
                    case $distro_shorthand in
                        on)   distro="${NAME}" ;;
                        tiny) distro="$(lsb_release -si)" ;;
                        *)    distro="${NAME} $(< /etc/debian_version) (${VERSION_CODENAME})" ;;
                    esac
                else
                    echo "ubuntu"
                    case $distro_shorthand in
                        on)   lsb_flags=-si ;;
                        tiny) lsb_flags=-si ;;
                        *)    lsb_flags=-sd ;;
                    esac
                    distro=$(lsb_release "$lsb_flags")
                fi
echo $distro

the result of running it via ./script.sh is

ubuntu
Ubuntu 22.04.4 LTS

and the result of running it via sh script.sh is

neotest.sh: 5: [[: not found
ubuntu
Ubuntu 22.04.4 LTS

(neotest.sh is the actual filename i'm using)

[ask-compu]

i also tried putting it in ~/.local/bin, the same place neowofetch is stored, renaming it to just neotest without the extension so i can run it the EXACT same way neowofetch is run and it still gives the correct result!!

[ethanholt1]

i also tried putting it in ~/.local/bin, the same place neowofetch is stored, renaming it to just neotest without the extension so i can run it the EXACT same way neowofetch is run and it still gives the correct result!!

This is black magic. So the issue is with the if statement incorrectly responding as true, when it should be false. We know the file /etc/debian_version always exists on all Ubuntu versions, so that can't be the issue. That means that the second half is the issue. Thing is, we aren't entirely sure what part of the second half is broken. Try running the entire script in your version of bash (with the modifications to echo the outputted version) and run it and see if it's the same issue.

[ask-compu]

i also tried putting it in ~/.local/bin, the same place neowofetch is stored, renaming it to just neotest without the extension so i can run it the EXACT same way neowofetch is run and it still gives the correct result!!

This is black magic. So the issue is with the if statement incorrectly responding as true, when it should be false. We know the file /etc/debian_version always exists on all Ubuntu versions, so that can't be the issue. That means that the second half is the issue. Thing is, we aren't entirely sure what part of the second half is broken. Try running the entire script in your version of bash (with the modifications to echo the outputted version) and run it and see if it's the same issue.

just did this, it resulted in the "not ubuntu" echo being triggered, so something else in the script is somehow changing the result of that if statement

[ethanholt1]

just did this, it resulted in the "not ubuntu" echo being triggered, so something else in the script is somehow changing the result of that if statement

Just curious; what's inside your /etc/os_release file? It seems to be pulling commands from there, for something.

[ask-compu]

ok i've narrowed it down further, it's definitely the second half of that if statement that is the problem

 if [[ -f /etc/debian_version ]]; then
                    echo "debian_version exists"
                fi
                if [[ $distro_shorthand != *"buntu"* ]]; then
                    echo "distro shorthand not ubuntu"
                fi

i added this to the neowofetch script above the existing if statement and it resulted in both echoes being true

if i echo $distro_shorthand above the if instead it results in off

[ask-compu]

WAIT why is the script i'm getting from pip install hyfetch showing

                if [[ -f /etc/debian_version ]] && [[ $distro_shorthand != *"buntu"* ]]; then
                    echo "not ubuntu"
                    . /etc/os-release
                    case $distro_shorthand in
                        on)   distro="${NAME}" ;;
                        tiny) distro="$(lsb_release -si)" ;;
                        *)    distro="${NAME} $(< /etc/debian_version) (${VERSION_CODENAME})" ;;
                    esac
                else
                    echo "ubuntu"
                    case $distro_shorthand in
                        on)   lsb_flags=-si ;;
                        tiny) lsb_flags=-si ;;
                        *)    lsb_flags=-sd ;;
                    esac
                    distro=$(lsb_release "$lsb_flags")
                fi

instead of

                if [[ -f /etc/debian_version ]] && [[ $(lsb_release -si) != *"buntu"* ]]; then
                    . /etc/os-release
                    case $distro_shorthand in
                        on)   distro="${NAME}" ;;
                        tiny) distro="$(lsb_release -si)" ;;
                        *)    distro="${NAME} $(< /etc/debian_version) (${VERSION_CODENAME})" ;;
                    esac
                else
                    case $distro_shorthand in
                        on)   lsb_flags=-si ;;
                        tiny) lsb_flags=-si ;;
                        *)    lsb_flags=-sd ;;
                    esac
                    distro=$(lsb_release "$lsb_flags")
                fi

that difference right there is the bug!!!

[ask-compu]

lemme try modifying neowofetch to match the neowofetch in the github repo and see if that gives the correct result

[ask-compu]

aha! that fixed it! so the version of the neowofetch file from pip doesn't match the version in this repo

[ethanholt1]

ok i've narrowed it down further, it's definitely the second half of that if statement that is the problem

 if [[ -f /etc/debian_version ]]; then

                    echo "debian_version exists"

                fi

                if [[ $distro_shorthand != *"buntu"* ]]; then

                    echo "distro shorthand not ubuntu"

                fi

i added this to the neowofetch script above the existing if statement and it resulted in both echoes being true

if i echo $distro_shorthand above the if instead it results in off

So the issue is with the second half, then. Since lsb_release -si outputs Ubuntu, that should return as false. But it doesn't. Possibly try assigning the output of that command to a variable, then putting that variable in the second half instead of the command directly? Edit: Try changing *buntu* to look for just "Ubuntu". That may fix it, and hopefully won't break compatibility with other Ubuntu spins, since I believe they all report as Ubuntu, and they're individually detected later on in the script.

[ask-compu]

here, see the difference?

[ethanholt1]

aha! that fixed it! so the version of the neowofetch file from pip doesn't match the version in this repo

So this issue is just because of PIP's hyfetch package being outdated then? I guess that's interesting.

[ask-compu]

ok i've narrowed it down further, it's definitely the second half of that if statement that is the problem

 if [[ -f /etc/debian_version ]]; then

                    echo "debian_version exists"

                fi

                if [[ $distro_shorthand != *"buntu"* ]]; then

                    echo "distro shorthand not ubuntu"

                fi

i added this to the neowofetch script above the existing if statement and it resulted in both echoes being true if i echo $distro_shorthand above the if instead it results in off

So the issue is with the second half, then. Since lsb_release -si outputs Ubuntu, that should return as false. But it doesn't. Possibly try assigning the output of that command to a variable, then putting that variable in the second half instead of the command directly?

i found the problem, it's that the pip version of neowofetch is outdated and checks $distro_shorthand instead of lsb_release -si

[ethanholt1]

aha! that fixed it! so the version of the neowofetch file from pip doesn't match the version in this repo

So this issue is just because of PIP's hyfetch package being outdated then? I guess that's interesting.

I guess this should be closed and the repo owner alerted that the package is outdated. Or it may not even be oudated, just the fixing change isn't incorporated into a release yet.

[ask-compu]

i figured out why, it seems pip is using the current RELEASE of this repo, but there's been updates to the repo since that release and one of those updates already fixes this bug

[ethanholt1]

i figured out why, it seems pip is using the current RELEASE of this repo, but there's been updates to the repo since that release and one of those updates already fixes this bug

That's what I believed to be the case. Either way, thanks for your help. I'll try and stick around and fix more issues now that I'm semi-familiar with the code-base.

[ask-compu]

aha! that fixed it! so the version of the neowofetch file from pip doesn't match the version in this repo

So this issue is just because of PIP's hyfetch package being outdated then? I guess that's interesting.

I guess this should be closed and the repo owner alerted that the package is outdated. Or it may not even be oudated, just the fixing change isn't incorporated into a release yet.

yes, in the meantime this bug can be quick fixed simply be replacing the contents of ~/.local/bin with the contents of https://github.com/hykilpikonna/hyfetch/blob/master/neofetch

[ask-compu]

actually that only fixes neowofetch, somehow the hyfetch command retains the bug, so another file needs replacing somewhere

[ask-compu]

aha there's another neowofetch at ~/.local/lib/python3.10/site-packages/hyfetch/scripts/neowofetch and this is the one hyfetch uses, so that ALSO needs to be replaced with the contents of https://github.com/hykilpikonna/hyfetch/blob/master/neofetch

replacing both files fixes both neowofetch and hyfetch

worth noting the python3.10 part of that path may be different depending on the python version in use

[ethanholt1]

actually that only fixes neowofetch, somehow the hyfetch command retains the bug, so another file needs replacing somewhere

Isn't the neowofetch command just an alias for Hyfetch? There's a neowofetch submodule in /hyfetch/scripts that links back to the main code, so that's just what I'm assuming.

[ask-compu]

actually that only fixes neowofetch, somehow the hyfetch command retains the bug, so another file needs replacing somewhere

Isn't the neowofetch command just an alias for Hyfetch? There's a neowofetch submodule in /hyfetch/scripts that links back to the main code, so that's just what I'm assuming.

check my last comment

[ethanholt1]

aha there's another neowofetch at ~/.local/lib/python3.10/site-packages/hyfetch/scripts/neowofetch and this is the one hyfetch uses, so that ALSO needs to be replaced with the contents of https://github.com/hykilpikonna/hyfetch/blob/master/neofetch

replacing both files fixes both neowofetch and hyfetch

worth noting the python3.10 part of that path may be different depending on the python version in use

So it is what I assumed it to be. Regardless, this issue has been solved. Thanks for your help, again!

[ask-compu]

also for those who don't want to replace files, just wait until the next version of hyfetch is released and then just update hyfetch, the issue will be fixed

[adrianvg]

Hello all!

I'd like to add that when I run hyfetch I get different OS results depending on user:

root@tyr
.',:clooo:  .:looooo:.          --------
.;looooooooc  .oooooooooo'         OS: Ubuntu bookworm/sid (jammy) x86_64

adrian_vg@tyr
.:oyyyyyyyyyyyyyyyyyyo:`           ---------
-oyyyyyyyodMMyyyyyyyysyyyyo-         OS: Kubuntu bookworm/sid (jammy) x86_64

I did a plain vanilla install with pip and just chose the default settings for my normal user as well as root.

Not sure what info you'd need if you want to look into this - please let me know if you need anything specific!

Also, thanks for keeping the neofetch legacy alive with hyfetch!

[ask-compu]

Hello all!

I'd like to add that when I run hyfetch I get different OS results depending on user:

root@tyr
.',:clooo:  .:looooo:.          --------
.;looooooooc  .oooooooooo'         OS: Ubuntu bookworm/sid (jammy) x86_64

adrian_vg@tyr
.:oyyyyyyyyyyyyyyyyyyo:`           ---------
-oyyyyyyyodMMyyyyyyyysyyyyo-         OS: Kubuntu bookworm/sid (jammy) x86_64

I did a plain vanilla install with pip and just chose the default settings for my normal user as well as root.

Not sure what info you'd need if you want to look into this - please let me know if you need anything specific!

Also, thanks for keeping the neofetch legacy alive with hyfetch!

that's just due to how it detects ubuntu flavors, the actual system is the same for all ubuntu flavors so it uses certain files/folders in the user's home folder for detection, which the root user doesn't have, u shouldn't be running this as root anyways

[adrianvg]

Hello all! I'd like to add that when I run hyfetch I get different OS results depending on user:

root@tyr
.',:clooo:  .:looooo:.          --------
.;looooooooc  .oooooooooo'         OS: Ubuntu bookworm/sid (jammy) x86_64

adrian_vg@tyr
.:oyyyyyyyyyyyyyyyyyyo:`           ---------
-oyyyyyyyodMMyyyyyyyysyyyyo-         OS: Kubuntu bookworm/sid (jammy) x86_64

I did a plain vanilla install with pip and just chose the default settings for my normal user as well as root. Not sure what info you'd need if you want to look into this - please let me know if you need anything specific! Also, thanks for keeping the neofetch legacy alive with hyfetch!

that's just due to how it detects ubuntu flavors, the actual system is the same for all ubuntu flavors so it uses certain files/folders in the user's home folder for detection, which the root user doesn't have, u shouldn't be running this as root anyways

Aha, thanks! I actually did remove it from root soon after, didn't see the need there. Was just trying out different bits of software to replace the original neofetch.

Why, however, shouldn't this be run for root? Security issues or some such?

[ask-compu]

Hello all! I'd like to add that when I run hyfetch I get different OS results depending on user:

root@tyr
.',:clooo:  .:looooo:.          --------
.;looooooooc  .oooooooooo'         OS: Ubuntu bookworm/sid (jammy) x86_64

adrian_vg@tyr
.:oyyyyyyyyyyyyyyyyyyo:`           ---------
-oyyyyyyyodMMyyyyyyyysyyyyo-         OS: Kubuntu bookworm/sid (jammy) x86_64

I did a plain vanilla install with pip and just chose the default settings for my normal user as well as root. Not sure what info you'd need if you want to look into this - please let me know if you need anything specific! Also, thanks for keeping the neofetch legacy alive with hyfetch!

that's just due to how it detects ubuntu flavors, the actual system is the same for all ubuntu flavors so it uses certain files/folders in the user's home folder for detection, which the root user doesn't have, u shouldn't be running this as root anyways

Aha, thanks! I actually did remove it from root soon after, didn't see the need there. Was just trying out different bits of software to replace the original neofetch.

Why, however, shouldn't this be run for root? Security issues or some such?

because nothing should be run as root unless absolutely necessary, and this doesn't need root to run