On Fri, 2025-12-26 at 14:31 +0100, Sebastian Andrzej Siewior wrote: > On 2025-12-26 12:53:30 [+0100], Emilio Pozuelo Monfort wrote: > > I just noticed an issue while testing the update: src:rustc-web is > > not > > available on armel/mips* (it couldn't be bootstrapped because > > upstream no > > longer provides prebuilt stage0 binaries for those), so the new > > clamav won't > > be available on those architectures. I tried to build clamav with > > the older > > rustc by lowering the requirement in .cargo/vendor/*/Cargo.toml > > (see > > attached patch), but I encountered issues at least in the `half` > > crate, > > e.g.: > > So what does firefox-esr do here? They don't build on armel and > mips*. > clamav needs roughly 1GiB of memory with the database and everything > and > with the "latest" asynchronous loading of signatures it doubles the > amount during the "update phase". Looking at the docs > https://docs.clamav.net/manual/Installing/Docker.html#memory- > ram-requirements > it says > > Minimum: 3 GiB > > Preferred: 4 GiB > > these numbers are more than armel boxes have equipped. My armel box > has > 512MiB. It is no fun to additional swap to compensate for this. > The only loss here might be mips64el but I doubt that someone > seriously > is using it there. > Based on this I would suggest to simply remove it on those > architectures > rather than not having any security updates in future. > > > error[E0658]: use of unstable library feature 'stdsimd' > > --> /build/clamav- > > 1.4.3+dfsg/.cargo/vendor/half/src/binary16/arch/x86.rs:44:18 > > | > > 44 | let retval = _mm_cvtph_ps(vec.assume_init()); > > | ^^^^^^^^^^^^ > > | > > = note: see issue #48556 > > <https://github.com/rust-lang/rust/issues/48556> > > for more information > > > > I don't know how to proceed from here. > > If this is the only problem, you could go to src/binary16/arch.rs and > simply remove and "mod x86" and "x86_64" + "x86" references. You need > to always go to the _fallback one and avoid any "support". > This would use the generic software implementation avoiding x86's > SIMD support for floating point. If this is the only problem, it > would the price to pay to remain available on armel and mips*. > > I don't know what the implications are if you downgrade the other > libraries…
Is there any update / a plan here? Regards, Adam
