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.