Hello h2,

Latest antiX-15-beta3 uses the base packages from devuan, but smxi does not detect antiX as a debian based distro.

This is feedback from a tester.

sgfxi gets past the distro type testing it does if I create a /etc/debian_version file with the following: (and I didn't need to make any changes to the /etc/lsb-release file)

$ cat /etc/debian_version
8.0

I think antiX used to have a /etc/debian_version file (antiX-15-beta2 did), but it looks like it's been replaced by the /etc/devuan_version file in antiX-15-beta3

$ cat /etc/devuan_version
jessie

So I think either the /etc/debian_version file needs to be added back to antiX-15, or maybe h2 needs to add support for Devuan distros to smxi/sgfxi.
Back to top

you have to look in /etc and find all files that have version/release in them.

That's what inxi looks for. However, that more advanced distro detection logic is NOT used in smxi/sgfxi, because they really don't care what the distro is specifically, it's either a supported system base or it's not, ie, smxi doesn't support anything from ubuntu no matter what, and never will. sgfxi does. So in those, the actual info about what distro shows reflects more on smxi/sgfxi simply not having that specific file id internally, those are white ilsted, ie, I have add special cases to smxi manually, one at a time, unless they are debian and use os-release and show the real distro name in os-release. all a real pain, and extra painful to realize is STILL not easy or fixed or stable in 2015, which in my opinion now means it never will be, since it only takes about 2 hours to think of all the possible ways distros need to be id'ed, then create a standard that supports all those, and has even more options for unthought stuff, then is released a standard, ie, NOT os-release.

The debian_version is the LAST thing used if nothing else is found, well, except for /etc/issue, one of those are the last ones. But that's inxi, which has an absurdly complicated way to id distros, because it supports or tries to support all the non standardized ways people have come up with to make id'ing a distro as hard and irregular as humanly possible, to no benefit to anyone, ever. Definitely my pet peeve from doing stuff that tries to id distros.

First is a valid os-release, or lsb-release, as long as the distro is listed in inxi to be valid there (some distros are derived from primary distros, but whoever designed that os-release format (poettering I think, who can be counted on to f#ck up anything he touches, even with what are his hopefully good intentions), anyway, os-release is flawed by design since whoever designed it was stupid enough to not think about derived distros from the release, ie, they were probably a redhat employee I believe, and in the redhat world, there's just redhat and fedora.

The key there was the failure to include SYSTEM_BASE as well, which sgfxi/smxi use internally because anyone with a brain knows that distros are often derived from a core distro, like ubuntu/xubuntu, etc, so you need to know the actual system base, like redhat, fedora, arch, debian, ubuntu, the base being defined by the primary package pool that the distro is built out of, or any derived distro.

So the os-release file, which was supposed to be the actual standard, was a stupid idea that failed before it even came into existence, since redhat employees are so blind to anything outside of redhat that they should never be allowed to create any standards (what package manager version are they on now in the latest release? I can't remember, yum is gone, the new one is there, because, well, rpm has always and will always suck, and no amount of lipstick can ever make that pig look good.)

So this cr#p is way more complicated than it should be, which is sort of pathetic in 2015 to be honest.

lsb release, already dropped, os-release, flawed by design, thus still no actually valid distro id format, which, given we are talking about a text file (well, until poettering decides that no file at all are needed, and shoves everything into useless binary blobs in systemd, as he strives to make gnu linux free software into cr#p windows like corporate garbage, by copying everything bad that windows does, like a binary init system, aka, the windows registry, so just wait, systemd will try to pull things like etc/fstab, /etc/os-release, etc, into itself, making linux garbage, and not unix anymore, like osx, which just resembles unix, but is actually just another variant corporate sh#t operating system.

sgfxi and smxi do not do nearly as intricate work in terms of distro ids, they know some distro id files, they try to read I think os-release, but really the bug is in os-release, then the bug is still using the deprecated distro release /etc file, though that itself is required because of the flawed design of os-release syntax, which fails to see the reality of derived distros, and account for them rationally, something that could have been done easily with two more lines, maybe 3, or data, like:

SYSTEM_BASE="debian"
SYSTEM_BASE_VERSION="wheezy"
SYSTEM_BASE_NU="8.0"

then have all the types work together, so that any linux could identify itself both for cosmetic type purposes, for distro specific purposes, but then also for core package management, system management, purposes, but we can't have that now, it might impede against redhat profits, since it would make all linux systems actually predictable and easier to manage.
Back to top

Thanks h2 for the info.

A very quick reply for now (lack of time), but I can get back and give more details tomorrow (Greek time).

Devuan /etc/os-release is a symbolic link to ../usr/lib/os-release
so I don't know if that causes any issue or not.
Here is the content.



antiX also has these files in /etc: lsb-release, antix-version, devuan_version

lsb-release


devuan_version


antix-version


I'll get you a better log output when I get some time and I try to install nvidia drivers using smxi/sgfxi. If I use the debian way with siduction repo enabled, it is fine, but the 'nvidia way' fails.
(kernel is a custim antiX 4.0.4)

Laterz
Back to top

www.devuan.org/, I thought that sounded familiar, of course I have to make all my stuff support it, i hate systemd, worst thing I've ever seen in gnu/linux, and first to make me seriously believe that windows is no longer a particularly bad choice, unless we can terminate the systemd sh#t, or, at VERY worst, take total control of that project away from corporate self interested redhat, and into an independent linux project like the kernel is now.

So I have to support devuan, there's no option for me, just let me know all the relevant files that you can find, and their content, if there is more than you listed.

Anything, no matter how small, I can do to help alternatives to systemd sh#t I will do.
Back to top

Please note, inxi, smxi, sgfxi, and svmi, all now support or should support devuan, but also note that because this detection test runs very early in the scripts (and this is why in general it's not actually a very good idea to mess with central id files like debian_version etc), the scripts cannot in most cases update themselves before triggering the error, so you have to force the update, either via -U, which may work, or via wget:

wget -O /usr/local/bin/smxi smxi.org/smxi

and so on, actually only smxi needs that if you start sgfxi and svmi from smxi internally, since smxi does the updating, not the scripts themselves.

inxi now also should recognize devuan, and fall back to the os-release if present, I think anyway.

I believe smxi, sgfxi, and svmi will work, inxi I'm not positive about because the debian id is tricky there, and support for os-release wasn't consistent, so it will I think work but I can't swear to it, in latest inxi now.
Back to top

/usr/local/bin/smxi: line 2794: syntax error near unexpected token `}'
/usr/local/bin/smxi: line 2794: `}'
Back to top

sorry, stupid, I forgot to test it, grrr, there was a code typo, to fix this, wget the new smxi, sorry about that.
Back to top

smxi now fixed.

For 32 and 64 bit antiX-15 (devuan-core), no more issues re recognition that antiX is 'Debian' based.

sgfxi installed nvidia just fine on 32 bit with 4.0.5 kernel, but fails on 64 bit with the same kernel version (siduction kernel has the same issue on my box).

I'll post the details in the forum when I get time to test it out, probably on Friday.

Thanks for adding devuan!
Back to top

thanks for the reminder, and nudge.

While I have very little real world hope that anything will come of the devuan fork, too few real man hours is my guess, I still think it's a good idea to at least try to not destroy the ability of linux to be a unix like operating system.
Back to top