[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

another attempt at Y2038



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.

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.

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?

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?

minor changes:
 * gmp: build-id and #define __GMP_CFLAGS
 * guile-3.0: build-id and recorded build path

unclear:
 * fribidi: only libfribidi-bin changes, probably harmless

ftbfs:
 * zlib: see earlier

starts using symbols such as __stat64_time64, __ioctl_time64:
 * acl
 * attr
 * base-passwd
 * bash
 * blt
 * bsdmainutils
 * bzip2
 * c-ares
 * curl
 * dash
 * debianutils
 * dpkg
 * e2fsprogs
 * expat
 * file
 * flex
 * fontconfig
 * freetype
 * fuse
 * glib2.0
 * gnupg2
 * gpm
 * groff
 * hostname
 * icu
 * jansson
 * jemalloc
 * keyutils
 * kmod
 * krb5
 * libassuan
 * libatomic-ops
 * libbsd
 * libcap2
 * libdebian-installer
 * libev
 * libevent
 * libgc
 * libgcrypt20
 * libice
 * libksba
 * libmd
 * libnsl
 * libpng1.6
 * libsepol

starts using large file symbols, but no time64 symbols:
 * libffi

starts using symbols such as above, but also changes C++ symbols:
 * apt

unreproducible for other non-time reasons:
 * binutils

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.

Please Cc me in replies as I am not subscribed.

Helmut


Reply to: