Am Mittwoch, 11. Dezember 2013, 11:39:21 schrieb Michal Marek:
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.
Right, and that is actually the goal here that the kernel behaves exactly as all the other packages. You could disable that though via the "useforbuild" disable flag (and quite soon this flag will have also an effect afterwards).
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.
hm, this is how we work with all other packages, except the kernel. We want to use the build result to be able to verify it. And given our test driven development model, we want to see the effect before we merge submissions. We could even add some kind of additional QA package beside and, for example, check the kernel interface (eg. POSIX compliance) if we have such tests.
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.
So, in effect this staging project would replace Kernel:HEAD as devel project for openSUSE:Factory? -- 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