core: inspect: make kernel version work with arch

[amorenoz]

Current KernelVersion seems to assume that, after the os build version directly follows the minor version, e.g: 6.2.14-300.fc38.x86_64.

However, that is not true for some OSs, such as arch whose kernel versions look like 6.4.12-arch1-1.

This patch tries to find the first parseable number in the trailing '-'separated strings and uses that as build number.

Fixes: #241

[vlrpl]

Current KernelVersion seems to assume that, after the os build version directly follows the minor version, e.g: 6.2.14-300.fc38.x86_64.

However, that is not true for some OSs, such as arch whose kernel versions look like 6.4.12-arch1-1.

This patch tries to find the first parseable number in the trailing '-'separated strings and uses that as build number.

Fixes: #241

Thanks, @amorenoz, I think this fixes it (hopefully can be confirmed by the reporter).

Just to add some bits to the discussion (not related to the change, but in general related to the version), e.g. the following:

6.2.12+generic
6.2.12*

still fail. Those can be easily generated with:

LOCALVERSION="+generic" make

and I guess these should also succeed (at least not prevent users from running the tool). In general, given (from kernel's Makefile):

VERSION = x
PATCHLEVEL = y
SUBLEVEL = z
EXTRAVERSION =

I'm not sure about the assumptions we can make on EXTRAVERSION and separators. I think it's okay to consider "x.y.z" (also from the Makefile):

KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)

but I'm not convinced a '-' or '.' is the next to expect (apparently, for EXTRAVERSION any separator should be added). The first failing example above resembles something plausible (although admittedly peculiar and probably unlikely), e.g. '+' is used for "+debug" images.

Of course, some of the usages of this may potentially lead to things like 6.2.3foo, but still this is something we might want to decide whether to consider or not (e.g. ignore it as it is too unlikely).

[pspacek]

I confirm it works with Arch kernel 6.4.12-arch1-1. In fact this was the only piece missing, I've tested trivial collection with -p generic and output via sort and it also works. In other words, this PR makes retis usable on Arch - thank you!