On Mon, Sep 20, 2021, at 02:34, Ola Lundqvist wrote: > Hi Henrique and others > > A question about this. Can't we simply do a binary build and upload that to > solve the problem?
At least for non-ELTS, uploading a binary build typically works, and at least once I fixed such an issue by just doing a binary (arch) upload, yes. But I am not involved directly with the ELTS upload, and I don't know what's acceptable/accepted there. > On Wed, 15 Sept 2021 at 12:54, Henrique de Moraes Holschuh <h...@debian.org> > wrote: >> Hello, >> >> The microcode packages have been whitelisted for at least a decade, however >> non-free auto-building is spotty. Intel-microcode faces the same issue. I >> don't really recall if contrib is any better. >> >> This has bitten me so many times, I never do uploads of non-free >> intel-microcode or amd64-microcode missing binaries to debian-security, or >> when racing the deadline for a s-p-u. They're all source+i386+amd64. >> >> For unstable, source-only works and has worked well for a while. It likely >> works for stable as well as it should have inherited that from unstable... >> But old(*)stable, security and backports? I would not hold my breath: I'd >> have to "test the waters" first to know. >> >> On Tue, Aug 31, 2021, at 16:22, Holger Levsen wrote: >> > On Tue, Aug 31, 2021 at 01:13:28PM +0200, Philipp Hahn wrote: >> > > What needs to be done to get "amd64-micocode" in version >> > > "3.20181128.1~deb9u1" into "stretch-security"? >> > > Build it manually and upload it somewhere? >> > >> > yes. (and utkarsh is on it.) >> > >> > > Can we so something to prevent this from happening again: >> > >> > it seems security/non-free is currently not autobuilt at all, so >> > I suppose this needs to be addressed and than amd64-microcode needs to >> > be whitelisted to be autobuilt there (as any other non-free package). >> >> -- Henrique de Moraes Holschuh <h...@debian.org>
