[Bug 1106829] New: Kernel:HEAD is lacking dtb-* 4.19-rc1 packages
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829 Bug ID: 1106829 Summary: Kernel:HEAD is lacking dtb-* 4.19-rc1 packages Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: msuchanek@suse.com Reporter: afaerber@suse.com QA Contact: qa-bugs@suse.de CC: agraf@suse.com, dmueller@suse.com, mbrugger@suse.com, yousaf.kaukab@suse.com Found By: --- Blocker: --- It seems that in absence of enabled aarch64, armv7hl and armv6hl configs the respective dtb-*.spec files no longer get generated and built. Once I updated the aarch64 config and tar'ed it up, dtb-aarch64.spec (but not the others) got generated. Those .dtb data files have no hard dependency on the kernel itself and should always be built please. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829
Andreas Färber
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829#c1
--- Comment #1 from Michal Suchanek
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829#c2
--- Comment #2 from Andreas Färber
What's the point if you don't have an ARM kernel to match these DTBs? It's not like the dtbs are either backward or forward compatible.
They are supposed to be compatible. EBBR increases the need for that. In several cases I test new dtb with old kernel while building - it often works. In any case, when someone complains, please CC me on the bug or talk to me. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829#c3
--- Comment #3 from Michal Suchanek
(In reply to Michal Suchanek from comment #1)
What's the point if you don't have an ARM kernel to match these DTBs? It's not like the dtbs are either backward or forward compatible.
They are supposed to be compatible.
Supposed to, right.
EBBR increases the need for that.
In several cases I test new dtb with old kernel while building - it often works.
You are building anyway so how long does the dtb build take? For me building dtbs was always really fast.
In any case, when someone complains, please CC me on the bug or talk to me.
I think the reason was the azure kernel. Either way not building dtbs for non-arm kernels is a nice cleanup. I do not really see a compelling use case for the kernelless dtbs so I don't want to revert to building dtbs always. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829#c4
--- Comment #4 from Andreas Färber
(In reply to Andreas Färber from comment #2)
(In reply to Michal Suchanek from comment #1)
What's the point if you don't have an ARM kernel to match these DTBs? It's not like the dtbs are either backward or forward compatible.
They are supposed to be compatible.
Supposed to, right.
EBBR increases the need for that.
In several cases I test new dtb with old kernel while building - it often works.
You are building anyway so how long does the dtb build take? For me building dtbs was always really fast.
It's the zypper part that's superfluous. Let me formulate it more drastically: We have not had our former dtb-source package integrated into kernel-source for you to tell us that you don't want to build our packages anymore. That is simply unacceptable.
In any case, when someone complains, please CC me on the bug or talk to me.
I think the reason was the azure kernel. Either way not building dtbs for non-arm kernels is a nice cleanup. I do not really see a compelling use case for the kernelless dtbs so I don't want to revert to building dtbs always.
These packages have always been built for armv6hl, armv7hl and aarch64 only, and they are not noarch packages, so I don't see any connection to azure kernels or other architectures. You have not given any compelling reason for your unilateral change, it was not discussed beforehand, so please revert to the previous state and if there's a problem we can then discuss how to fix it properly. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829#c5
--- Comment #5 from Michal Suchanek
(In reply to Michal Suchanek from comment #3)
(In reply to Andreas Färber from comment #2)
(In reply to Michal Suchanek from comment #1)
What's the point if you don't have an ARM kernel to match these DTBs? It's not like the dtbs are either backward or forward compatible.
They are supposed to be compatible.
Supposed to, right.
EBBR increases the need for that.
In several cases I test new dtb with old kernel while building - it often works.
You are building anyway so how long does the dtb build take? For me building dtbs was always really fast.
It's the zypper part that's superfluous.
???
Let me formulate it more drastically: We have not had our former dtb-source package integrated into kernel-source for you to tell us that you don't want to build our packages anymore. That is simply unacceptable.
They get built in sensible scenarios.
In any case, when someone complains, please CC me on the bug or talk to me.
I think the reason was the azure kernel. Either way not building dtbs for non-arm kernels is a nice cleanup. I do not really see a compelling use case for the kernelless dtbs so I don't want to revert to building dtbs always.
These packages have always been built for armv6hl, armv7hl and aarch64 only, and they are not noarch packages, so I don't see any connection to azure kernels or other architectures.
The kernel project gets all architectures for which packages exist - otherwise they would not build. That means that x86-only projects like the ones for azure branches suddenly grow arm architectures if dtbs are to be built without arm configs.
You have not given any compelling reason for your unilateral change, it was not discussed beforehand, so please revert to the previous state and if there's a problem we can then discuss how to fix it properly.
You have not described any problem in enough detail so that it can be fixed. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829#c6
--- Comment #6 from Michal Suchanek
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829#c7
--- Comment #7 from Andreas Färber
"Kernel:HEAD is lacking dtb-* 4.19-rc1 packages" is totally not true.
Kernel:HEAD is built for all architectures so includes all dtb packages as well.
Read again, it was totally true: No dtb-*.spec files were generated from .in and no dtb-* packages either. What is right now at -rc3 is irrelevant to this -rc1 report. We will run into again for 4.20+ because the kernel maintainers disable all arm configs for each -rc1 update. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829#c8
--- Comment #8 from Andreas Färber
The kernel project gets all architectures for which packages exist - otherwise they would not build. That means that x86-only projects like the ones for azure branches suddenly grow arm architectures if dtbs are to be built always.(In reply to Andreas Färber from comment #4)
(In reply to Michal Suchanek from comment #3)
(In reply to Andreas Färber from comment #2)
(In reply to Michal Suchanek from comment #1)
What's the point if you don't have an ARM kernel to match these DTBs? It's not like the dtbs are either backward or forward compatible.
They are supposed to be compatible.
Supposed to, right.
EBBR increases the need for that.
In several cases I test new dtb with old kernel while building - it often works.
You are building anyway so how long does the dtb build take? For me building dtbs was always really fast.
It's the zypper part that's superfluous.
???
provides:multiversion(dtb) allows me side-by-side installation via zypper up. I have a whole farm of different boards that I test openSUSE arm kernels on, so thoughtlessly pushing more work on me is not nice.
Let me formulate it more drastically: We have not had our former dtb-source package integrated into kernel-source for you to tell us that you don't want to build our packages anymore. That is simply unacceptable.
They get built in sensible scenarios.
For ARM I define which scenarios are sensible, and I've already explained that building dtb packages independent of kernel-foo is sensible.
In any case, when someone complains, please CC me on the bug or talk to me.
I think the reason was the azure kernel. Either way not building dtbs for non-arm kernels is a nice cleanup. I do not really see a compelling use case for the kernelless dtbs so I don't want to revert to building dtbs always.
These packages have always been built for armv6hl, armv7hl and aarch64 only, and they are not noarch packages, so I don't see any connection to azure kernels or other architectures.
The kernel project gets all architectures for which packages exist - otherwise they would not build. That means that x86-only projects like the ones for azure branches suddenly grow arm architectures if dtbs are to be built without arm configs.
Now that's a more concrete description, thanks. Proposed solution: Distinguish whether config.conf lists them as !needs_updating or whether they're disabled or simply not present at all: https://kernel.suse.com/cgit/kernel-source/tree/config.conf?h=SLE15-AZURE - arm64/default - arm64/vanilla https://kernel.suse.com/cgit/kernel-source/commit/?id=a6a88d1e3ba86a84891b47... +arm64 -!needs_updating arm64/default +arm64 -!needs_updating arm64/64kb +arm64 -!needs_updating arm64/vanilla Note that when I run tar-up.sh and upload my kernel to OBS, it builds x86_64 etc. kernels that I don't need, too. So maybe extending those scripts to allow limiting the architectures enabled would be another independent idea?
You have not given any compelling reason for your unilateral change, it was not discussed beforehand, so please revert to the previous state and if there's a problem we can then discuss how to fix it properly.
You have not described any problem in enough detail so that it can be fixed.
See comment #0: For previous kernel versions the dtb packages got built also after your colleagues disabled our arm configs. That way, zypper up gave me the new .dtb files. For 4.19-rc1 they did not get built (regression). They only got built again after my commits re-enabling the updated configs (removing -!needs_updating) got merged. Please revert the change to the packaging scripts. Expected behavior: Whenever there are armv6hl, armv7hl or aarch64 kernel configs available, disabled or not, the corresponding dtb-{armv6l,armv7l,aarch64}.spec files shall get generated and a corresponding package to build them. Note that on a separate branch like SLE15-AZURE you can easily disable the whole dtb magic on that specific branch, without messing up master branch for me. You could generalize that to: We don't need dtb-* packages on SLE* branches. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829#c9
--- Comment #9 from Michal Suchanek
You have not described any problem in enough detail so that it can be fixed.
See comment #0: For previous kernel versions the dtb packages got built also after your colleagues disabled our arm configs. That way, zypper up gave me the new .dtb files. For 4.19-rc1 they did not get built (regression). They only got built again after my commits re-enabling the updated configs (removing -!needs_updating) got merged. Please revert the change to the packaging scripts.
That's a description of an actual issue that can be fixed.
Expected behavior: Whenever there are armv6hl, armv7hl or aarch64 kernel configs available, disabled or not, the corresponding dtb-{armv6l,armv7l,aarch64}.spec files shall get generated and a corresponding package to build them.
Note that on a separate branch like SLE15-AZURE you can easily disable the whole dtb magic on that specific branch, without messing up master branch for me. You could generalize that to: We don't need dtb-* packages on SLE* branches.
Do we not? Where do the dtbs for SLE images come from? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829#c10
Michal Suchanek
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829
http://bugzilla.opensuse.org/show_bug.cgi?id=1106829#c11
--- Comment #11 from Michal Suchanek
Note that when I run tar-up.sh and upload my kernel to OBS, it builds x86_64 etc. kernels that I don't need, too. So maybe extending those scripts to allow limiting the architectures enabled would be another independent idea?
FTR tar-up.sh has -a option for selecting an architecture for ages already. If you want to select multiple architectures feel free to merge the scripts branch where the script is updated to allow that. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com