Re: another attempt at Y2038
On Tue, Oct 18, 2022, at 12:48 PM, Helmut Grohne wrote:
> Hi,
>
> I was also wondering about this Y2038 thingy and did some experiments.
> I'm reporting what I found to document it, but don't see much actionable
> stuff here. Many thanks to Arnd Bergmann for his input.
Thanks a lot for taking a look here, this is very promising, compared
to my attempt from 2020.
> Attempt #1: rebootstrap
>
> Given that I develop rebootstrap, attempting to use it for a time64
> bootstrap seemed quite natural. I've been talking to this with Steve
> multiple times including DC22. The question was how to plug it in. In
> the end I went for Arnd's suggestion to set DPKG_*_APPEND variables to
> modify dpkg-buildflags. Not every package uses these flags, but a
> majority do. For a survey, this is probably good enough.
>
> Things went somewhat far. The first issue was zlib. There isn't much to
> say about it: https://github.com/madler/zlib/issues/447
>
> Then the libprelude build failed with symbol issues. It happens to build
> a C++ library and its symbols are dependent on time types. Unsurprising.
> This is a case where we do break ABI.
Just for my understanding: what would be the correct way to handle this,
under the assumption that the new symbol names that dpkg-shlibdeps
found are the ones we want? Is there a way to flag both the time32
and the tim64 set of symbols as correct, or would we have to have a
per-architecture list of expected symbols for the new (still to be
decided) architecture name?
> Then it occured to me that not failing does not imply not being affected
> right? You can break ABI without failing the build. So as a detection
> method this has a significant risk of false negatives.
>
> For just bootstrapping an incompatible time64 armhf, this method should
> mostly just work. Would someone like to have the resulting .debs? What
> would do with them?
I think Wookey wants to do a build of a much larger set of packages
as a feasibility study to show that a rebuild actually survives running
with time set to 2038+, before a decision is made about how and when
this becomes an official release target.
> Attempt #2: reproducible
>
> My other favourite QA tool is reproducible builds. So how about building
> and comparing binary packages?
>
> Unfortunately, build flags participate in build ids. That directly
> implies a high risk of false positives and/or manual work.
>
> Without further ado, here we go.
>
> .debs unchanged:
> * base-files
> * db-defaults
> * coreutils
> * diffutils
> * findutils
> * libonig
> * libidn
> * libidn2
> * libpipeline
> * libpthread-stubs
> * libsm
> * gzip
>
> Question: How many of these ignore dpkg-buildflags?
coreutils definitely should have changed, given that 'ls'
prints timestamps.
> After this sample, it became clear that this method is also not very
> helpful. While it shows that basically everything is affected, it
> doesn't give a good handle on ABI breakage either.
I think it's safe to say that most packages will be affected in
some way. Packages that only use glibc and no other libraries could
be converted separately, but this is not helpful in the end since it
does not get any closer to converting libraries that export
modified interfaces. As far as I remember, I could show (using
pattern matching on header files) that about half the libraries
in Debian will require have an ABI change, but a much higher number
of packages depend on at least one library aside from glibc that
changes like this. To actually get this done, everything must be
rebuilt, and in order to coexist with existing binaries, this
requires a new architecture name and target triplet.
Arnd
Reply to: