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 Michal Marek:
Dne 11.12.2013 00:25, Adrian Schröter napsal(a):
Am Dienstag, 10. Dezember 2013, 21:47:27 schrieb Michal Marek:
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 :)
Only individual 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.
I 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, right? 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? bye adrian -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org