Thanks Scott.
Glad to hear that this is under control.
On Thu, 29 Feb 2024, Scott Kitterman via clamav-users wrote:
On February 29, 2024 12:56:47 PM UTC, Andrew C Aitchison via clamav-users
<[email protected]> wrote:
I haven't fully understood this yet, but Debian is planning a flag-day
on 29 March to fix the y2038 bug on 32bit systems (possibly excluding
intel).
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063130
Since clamav uses libmspack it is listed at
https://tracker.debian.org/pkg/libmspack
(under "action needed/Marked for autoremoval on 29 March:")
as being affected:
Version 0.11-1 of libmspack is marked for autoremoval from testing
on Fri 29 Mar 2024. It is affected by #1063130. The removal of
libmspack will also cause the removal of (transitive) reverse
dependencies: c-icap-modules, cabextract, clamassassin, clamav,
clamsmtp, clamtk, cyrus-imapd, dtrx, e2guardian, evolution-ews,
forensics-extra, libclamunrar, lutris, msttcorefonts, open-vm-tools,
pg-snakeoil, playonlinux. You should try to prevent the removal by
fixing these RC bugs.
which suggests that because libmspack will have an incompatible change
(source?) packages that use it will be dropped (from 32bit systems ?)
*unless* they are updated too.
The discussion suggests that some other distributions that
still support 32bits are not planning to fix y2038 for 32bit.
Not sure what the implications are for Ubuntu, but the next release
- 24.04 LTS, "Noble Numbat" - will have 15 years paid support, which
is beyond the y2038 bug.
I guess that the ClamAV and the Debian packages will need to be given
separate consideration.
Ubuntu is also doing the same transition. The developer who is coordinating
this in Debian is also doing it for Ubuntu, although I don't know their
schedule.
There is nothing end users need to worry about. If you are running a 64 bit
architecture (which is almost everyone), then your sys already uses 64 but time
and there should be no 2038 worry.
I understand that other distros are dropping support for 32 but. We are
planning to retain it in Debian, but switch to 64 bit time, which breaks the
ABI. This necessitates library package renames and a bunch of other stuff that
end users will never directly see.
We are keeping 32 bit time for i386 to support compatibility with proprietary
packages from outside Debian that can't be rebuilt. Our research indicated
that virtually all current i386 usage is as an additional architecture on amd64
systems to support such software. This is not ideal, but the only choices were
to keep such working, albeit with 2038 problems, or to make the change to 64
bit time and have it not work at all.
The auto removal notices that you're seeing are a transient aspect of how
Debian handles serious bugs and not any kind of an indication of intent not to
have these packages in a future release.
As long as upstream keeps clamav working on 32 bit architectures, we should be
able to support it.
Scott K
_______________________________________________
Manage your clamav-users mailing list subscription / unsubscribe:
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/Cisco-Talos/clamav-documentation
https://docs.clamav.net/#mailing-lists-and-chat
--
Andrew C. Aitchison Kendal, UK
[email protected]
_______________________________________________
Manage your clamav-users mailing list subscription / unsubscribe:
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/Cisco-Talos/clamav-documentation
https://docs.clamav.net/#mailing-lists-and-chat
