<DC-IRC> <peter_d> I ran into this issue around the same time that Spectrefield must have been trying to build the RT kernel as well, I traced it down to here https://github.com/armbian/build/blob/main/lib/functions/compilation/utils-compilation.sh#L24
<DC-IRC> <peter_d> Looks like the grab_version function is totally ignoring localversion files present in the kernel tree
<DC-IRC> <rpardini> that's... true, but that's not the full story.
<DC-IRC> <rpardini> that grab_version is really only supposed to get the Makefile version
<DC-IRC> <rpardini> the problem is during _packaging_, we have hardcoded values, and completely ignore what the Makefile would have told us
<DC-IRC> <rpardini> the problem is during _packaging_, we have hardcoded values, and completely ignore what running the Makefile would have told us
<DC-IRC> <peter_d> I think (and this is me not being super confident, just trying to understand a bit of the build system) the output of grab_version gets passed back into prepare_kernel_packaging_debs which ends up puking because it uses that info to try and find the built vmlinz files
<DC-IRC> <peter_d> I think (and this is me not being super confident, just trying to understand a bit of the build system) the output of `grab_version` gets passed back into `prepare_kernel_packaging_debs` which ends up puking because it uses that info to try and find the built vmlinuz files
<DC-IRC> <peter_d> I was able to get it to build if I manually edited `$kernel_version` to add -rtXX in that file
<DC-IRC> <rpardini> also true. but we should resolve the version by running make, and not try to predict.
<DC-IRC> <rpardini> in concrete... if we run
<DC-IRC> <rpardini> `make ARCH=arm64 LOCALVERSION=-meson64 kernelrelease`
<DC-IRC> <rpardini> in concrete... if we run
<DC-IRC> <rpardini> `make -s ARCH=arm64 LOCALVERSION=-meson64 kernelrelease`
<DC-IRC> <rpardini> we get back the correct, resolved version
<DC-IRC> <rpardini> that will include the localversion_* files
<DC-IRC> <peter_d> Exactly, I was considering making a pull request but the shell code that handles running things in the make environment is a bit intimidating
<DC-IRC> <rpardini> its a work in progress, yes. in this case, since you need to capture the output, I'd go for simpler is better
<DC-IRC> <rpardini> all the other make runners are either long running or interactive, but none capture the output
<DC-IRC> <rpardini> (I think. lol)
<DC-IRC> <rpardini> actually... I left this in place for future-me to find. `kernel_version_family` is all you should need to modify
<DC-IRC> <rpardini> and that is set after kernel is built, and you have all the info. just capture from `make kernelrelease` right then and there and use in `kernel_version_family`
<DC-IRC> <peter_d> That makes sense. Is the reason it can't be directly grabbed from `make` on line 69 of `kernel.sh` because `kernel_determine_toolchain` hasn't been called yet?
<DC-IRC> <peter_d> (that looks like the place that the value of `grab_version` is initially used right after patching)
<DC-IRC> <rpardini> `grab_version` is used before even cloning the git repo
<DC-IRC> <rpardini> it really should only grab the base version from the Makefile.
<DC-IRC> <rpardini> also, before patches are applied... so no way it would ever find the localversion_xxx files.
<DC-IRC> <rpardini> I think packaging-time `kernel_version_family` is the way to go. Alternatively: `rm -f localversion-*` before running config
<DC-IRC> <rpardini> heh.
<DC-IRC> <rpardini> I guess people wanna have the `-rt3` in their unames so they know they're on RT kernel.
<DC-IRC> <rpardini> gotta, good luck. 🖖
<DC-IRC> <rpardini> gotta go, good luck. 🖖
<DC-IRC> <peter_d> Thanks for walking me through it