Helmut Grohne
2022-10-18 12:20:01 UTC
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
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