[opensuse-packaging] post-build-checks, uname -r is broken
Hi, even I've realized that "uname -r" is broken on any openSUSE build repo. It's because the post-build-checks package symlinks an uname.sh script which does not report the running kernel version anymore but a version string from arbitrary text files or installed kernel sources. What is the reason why we have this dirty hack? If any package would need to know a kernel source version then it should certainly not use uname to get it. Thus we should rather fix that package instead of breaking uname. Is there any chance to remove that uname.sh? I'm fighting since months with some kind of kernel related odd behavior, now I see that all my debugging scripts, etc. were totally useless. That's annoying. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, Mar 23, 2016 at 09:19:43PM +0100, Ruediger Meier wrote:
even I've realized that "uname -r" is broken on any openSUSE build repo.
It's because the post-build-checks package symlinks an uname.sh script which does not report the running kernel version anymore but a version string from arbitrary text files or installed kernel sources.
What is the reason why we have this dirty hack?
IMHO the reason is that while regular OBS builds use a full virtual machine for build now, it wasn't always so and even now, local builds use only a chroot. The result would then depend on kernel version of the build host. For example, the system I'm doing most of my local osc builds on would report 3.12 kernel while the actual target systems range from 2.6.16 to 4.5.0.
If any package would need to know a kernel source version then it should certainly not use uname to get it. Thus we should rather fix that package instead of breaking uname.
That sounds like a nice goal but doing such cleanup globally sounds like quite a lot of work. Work someone should do first. Michal Kubeček -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 23 March 2016, Michal Kubecek wrote:
On Wed, Mar 23, 2016 at 09:19:43PM +0100, Ruediger Meier wrote:
even I've realized that "uname -r" is broken on any openSUSE build repo.
It's because the post-build-checks package symlinks an uname.sh script which does not report the running kernel version anymore but a version string from arbitrary text files or installed kernel sources.
What is the reason why we have this dirty hack?
IMHO the reason is that while regular OBS builds use a full virtual machine for build now, it wasn't always so and even now, local builds use only a chroot.
The result would then depend on kernel version of the build host. For example, the system I'm doing most of my local osc builds on would report 3.12 kernel while the actual target systems range from 2.6.16 to 4.5.0.
Yes and this is correct and wanted behavior. For example a test-suite might skip (or include) certain tests depending on the _running_ kernel. The kernel version can be used to guess about kernel _runtime_ bugs or features.
If any package would need to know a kernel source version then it should certainly not use uname to get it. Thus we should rather fix that package instead of breaking uname.
That sounds like a nice goal but doing such cleanup globally sounds like quite a lot of work. Work someone should do first.
I guess there is almost no existing use case for this broken behavior. Even for packages which want to report the build host kernel version in their --version output, like $ xyz --version "xyz 1.2.3, built on Linux 3.2.1" are wrong, because it's simply not true that it was built on Linux 3.2.1. BTW the existing hack is incomplete anyways because uname(2) and /proc/version still don't lie. So what we have is a nonpredictable mix. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 23.03.2016 um 21:57 schrieb Ruediger Meier:
On Wednesday 23 March 2016, Michal Kubecek wrote:
On Wed, Mar 23, 2016 at 09:19:43PM +0100, Ruediger Meier wrote:
even I've realized that "uname -r" is broken on any openSUSE build repo.
It's because the post-build-checks package symlinks an uname.sh script which does not report the running kernel version anymore but a version string from arbitrary text files or installed kernel sources.
What is the reason why we have this dirty hack?
IMHO the reason is that while regular OBS builds use a full virtual machine for build now, it wasn't always so and even now, local builds use only a chroot.
actually these hacks go back a very long way and the main "ab-"users of this were the proprietary graphics drivers. From that view, I'm perfectly fine with finally getting rid of this ugly hack.
The result would then depend on kernel version of the build host. For example, the system I'm doing most of my local osc builds on would report 3.12 kernel while the actual target systems range from 2.6.16 to 4.5.0.
Yes and this is correct and wanted behavior.
For example a test-suite might skip (or include) certain tests depending on the _running_ kernel. The kernel version can be used to guess about kernel _runtime_ bugs or features.
well, here I'm not so sure. What matters is absolutely not the running kernel, because even in current build environments where the running kernel for the VM often matches the kernel the distribution will be running on, there is no guarantee at all that it actually matches. - the kernel might just be too broken to be used to run the VMs, yes this has happened before and especially if you look at this cross architectures it is by far not even a rare case. - some architectures are still not completely running with virtualisation or with native virtualisation. This case is getting more and more rare, especially with architectures dying out that never had a real port of virtualisation, but on the other hand every young architecture at the time of their appearance has had issues with native full virtualisation. After all these words: what matters is not the kernel that happens to be running at build time but the kernel that will be running on the system where the tool/library/application being built will be running. But all this is more the conceptual side. The uname hack is just that: an old hack that was needed at the time when it was written (many years ago), but we should have gotten rid of it for quite a while already.
If any package would need to know a kernel source version then it should certainly not use uname to get it. Thus we should rather fix that package instead of breaking uname.
That sounds like a nice goal but doing such cleanup globally sounds like quite a lot of work. Work someone should do first.
I guess there is almost no existing use case for this broken behavior. Even for packages which want to report the build host kernel version in their --version output, like
$ xyz --version "xyz 1.2.3, built on Linux 3.2.1"
are wrong, because it's simply not true that it was built on Linux 3.2.1.
BTW the existing hack is incomplete anyways because uname(2) and /proc/version still don't lie. So what we have is a nonpredictable mix.
cu, Rudi
-- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@suse.com,ro@suse.de,bugfinder@t-online.de) ------------------------------------------------------------------------- Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)
On Thursday 24 March 2016, Ruediger Oertel wrote:
Am 23.03.2016 um 21:57 schrieb Ruediger Meier:
On Wednesday 23 March 2016, Michal Kubecek wrote:
On Wed, Mar 23, 2016 at 09:19:43PM +0100, Ruediger Meier wrote:
even I've realized that "uname -r" is broken on any openSUSE build repo.
It's because the post-build-checks package symlinks an uname.sh script which does not report the running kernel version anymore but a version string from arbitrary text files or installed kernel sources.
What is the reason why we have this dirty hack?
IMHO the reason is that while regular OBS builds use a full virtual machine for build now, it wasn't always so and even now, local builds use only a chroot.
actually these hacks go back a very long way and the main "ab-"users of this were the proprietary graphics drivers. From that view, I'm perfectly fine with finally getting rid of this ugly hack.
The result would then depend on kernel version of the build host. For example, the system I'm doing most of my local osc builds on would report 3.12 kernel while the actual target systems range from 2.6.16 to 4.5.0.
Yes and this is correct and wanted behavior.
For example a test-suite might skip (or include) certain tests depending on the _running_ kernel. The kernel version can be used to guess about kernel _runtime_ bugs or features.
well, here I'm not so sure. What matters is absolutely not the running kernel, because even in current build environments where the running kernel for the VM often matches the kernel the distribution will be running on, there is no guarantee at all that it actually matches.
I don't think so. A test-script may only work if a particular syscall is available. This syscall exists for all kernels, say >3.14. If the running kernel has the wanted version then ok ... run the test. If not ... then it has to skip the test because it would fail. In this case we may miss that test run for the final distro kernel. But there is no way to test it without having the distro kernel or any other kernel > 3.14 running.
[...] But all this is more the conceptual side. The uname hack is just that: an old hack that was needed at the time when it was written (many years ago), but we should have gotten rid of it for quite a while already.
This would be nice. BTW I've made some more tests and have to admit that uname.sh usually does _not_ report wrong versions because there is no such file /.kernelversion neither in chroot nor on OBS build hosts. So it should be 100% safe to remove the hack (at least for all packages which do not require kernel-source). cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (3)
-
Michal Kubecek -
Ruediger Meier -
Ruediger Oertel