Bug 1106829 - Kernel:HEAD is lacking dtb-* 4.19-rc1 packages
Kernel:HEAD is lacking dtb-* 4.19-rc1 packages
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
aarch64 openSUSE Factory
: P5 - None : Normal (vote)
: ---
Assigned To: Michal Suchanek
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-09-01 10:53 UTC by Andreas Färber
Modified: 2018-10-01 19:10 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Färber 2018-09-01 10:53:57 UTC
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.
Comment 1 Michal Suchanek 2018-09-10 16:21:25 UTC
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.

Anyway people complained that dtbs litter non-arm kernel builds and cause noarch packages to be built on the slow arm builders so I disabled dtb generation for archs that are not built.
Comment 2 Andreas Färber 2018-09-10 17:31:46 UTC
(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. 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.
Comment 3 Michal Suchanek 2018-09-10 20:56:10 UTC
(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.

> 
> 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.
Comment 4 Andreas Färber 2018-09-10 21:33:26 UTC
(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.

> > 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.
Comment 5 Michal Suchanek 2018-09-10 21:48:03 UTC
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.

???

> 
> 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.
Comment 6 Michal Suchanek 2018-09-10 21:49:22 UTC
"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.
Comment 7 Andreas Färber 2018-09-10 22:02:04 UTC
(In reply to Michal Suchanek from comment #6)
> "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.
Comment 8 Andreas Färber 2018-09-10 22:58:53 UTC
(In reply to Michal Suchanek from comment #5)
> 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=a6a88d1e3ba86a84891b47c112cd040715fb623f
+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.
Comment 9 Michal Suchanek 2018-09-11 13:24:53 UTC
(In reply to Andreas Färber from comment #8)

> > 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?
Comment 10 Michal Suchanek 2018-09-28 08:00:09 UTC
Pushed PR to master. Please reopen if you observe issue with 4.20.
Comment 11 Michal Suchanek 2018-10-01 19:10:53 UTC
(In reply to Andreas Färber from comment #8)
 
> 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.