Am Mittwoch, 11. Dezember 2013, 10:41:17 schrieb Michal Marek:
Dne 11.12.2013 09:47, Adrian Schröter napsal(a):
Am Mittwoch, 11. Dezember 2013, 09:27:29 schrieb
Dne 11.12.2013 00:25, Adrian Schröter napsal(a):
Am Dienstag, 10. Dezember 2013, 21:47:27 schrieb
> For me and I guess most other
> developers on this list, it is actually an advantage that the kernel
> does not need itself to build.
it won't be different as like updating to a broken glibc.
Yes, and that precisely is the problem - we do not want to deal with the
bootstrap issues that the toolchain guys have to. For you, it's probably
not such a big difference if one more package becomes part of the
bootstrap set, but for us, being or not being in the bootstrap set matters.
well, since we are forced to use the distro kernel for package builds now you
have also little choice. This is just going to happen to be able to load kernel
modules, which are required meanwhile by some tools.
That's fine. I only object to forcing the bootstrap on everyone who
wants to build their kernel.
We can declare the kernel-obs-build package as "Support" package. Means, it does
not trigger any builds actively. So there would not be a bootstrap cycle.
Would that help?
The discussion where to place the OBS vm kernel
spec file will not change that.
It will just become even harder for you and everybody else get out of the
kernel-not-booting situation again :(
Well, what would most likely happen is that the automated kernel builds
in the Kernel:$branch projects would exclude the kernel-obs spec file to
avoid this situation, so the QA gain would be minimal.
Erm, actually I would object against this. Even when the spec file is not
part of kernel-sources, we should have at least the kernel-obs-build package
in these projects or the first breakage would happen in openSUSE:Factory.
(but see below first maybe :)
developers who build their kernel in the OBS/IBS would be tricked into
the bootstrap. But we have scripts even for that, so...
And they would need to know the additional manual branch call which could
be avoided when all spec files stick together.
Also it would avoid some "if $package =~ kernel; else ..." statements in
some external check scripts to handle just the kernel package differently.
actually plan to boot test each kernel pushed to the git, before
actual users see it. But failure to boot will not affect subsequent
attempts to build a fixed package. Hardware for that is ordered, it will
not cover ppc64(le|be) though, only x86_64 (unless there is already
usable qemu emulation for ppc64le?)
and how will eg a broken tool chain be detected or a broken mkinitrd?
It would not. We have enough fun with broken kernels already ;-).
I assume that we agree that such breakages should not appear first time in Factory,
So you say basically we need another QA project somewhere where all kernel & tool
chain shall be tested before submission to factory, right?
So Kernel:$branch projects stay as kernel-only projects, but the devel
project for factory will become some other project?
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org