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
>> 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
>> 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
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
BTW the existing hack is incomplete anyways because uname(2)
and /proc/version still don't lie. So what we have is a nonpredictable
with kind regards (mit freundlichem Grinsen),
Ruediger Oertel (firstname.lastname@example.org,email@example.com,firstname.lastname@example.org)
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)