Dne 11.12.2013 10:54, Adrian Schröter napsal(a):
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?
If I upload a new kernel to my project, the previous, possibly broken, kernel-obs-build will be used, won't it? In that case, "Support" won't help.
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?
Yes. I only do not like the bootstrap (or whatever you call it) in all projects that build the kernel.
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?
That can certainly be done. I didn't think much about Factory in my previous email, but more about the released products and SLE betas. The factory kernels are nowadays submitted by a daily cronjob, so a _separate_ staging project which does the bootstrap makes sense here. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org