On Thu, 2021-05-27 at 10:50 +0200, Paul Gevers wrote: > Control: tags -1 moreinfo > > Hi, > > On 17-05-2021 02:12, Ben Hutchings wrote: > > Please unblock package broadcom-sta > > > > [ Reason ] > > Fix the unusable broadcom-sta-source package. > > > > [ Impact ] > > It is not possible to build a package using module-assistant and the > > version of broadcom-sta-source in bullseye. However, dkms and > > broadcom-sta-dkms can be used as an alternative. > > > > [ Tests ] > > Only the build processes are being changed. I tested that: > > - broadcom-sta can be built from source > > - module-assistant can build a module package from broadcom-sta-source > > for the current kernel version in bullseye (5.10.0-6-amd64) > > - the resulting binary module package looks like a module package > > built from broadcom-sta-source in buster, modulo version changes > > * I wonder, broadcom-sta has seen quite some uploads the last couple of > years and debhelper is even in oldstable newer than the version > mentioned. How were all these uploads possible? broadcom-sta has always properly declared its debhelper compatibility level. Earlier it was done through debian/compat, then since version 6.30.223.271-13~exp1 through a versioned B-D on debhelper-compat. module-assistant creates a source and binary packages for modules using a template that's included in packages such as broadcom-sta-source. That template was not updated along with broadcom-sta itself, so was missing a debhelper compatibility level since version 6.30.223.271-13~exp1. This probably wasn't noticed because DKMS is now more popular than module-assistant. > * What is/was the behavior of debhelper if the compat level was not > specified? In the freeze we don't want debhelper compat bumps unless the > package is proven to have no delta regardless of the old-vs-new level. It's a fatal error. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity.
Attachment:
signature.asc
Description: This is a digitally signed message part