On 2022-11-10 08:37, Paul Gevers wrote: > Hi, > > On 09-11-2022 23:02, Aurelien Jarno wrote: > > Unfortunately I am not sure we want to do that, as we don't know if this > > GCC version incompatibility (that seems specific to s390x, at least in > > the utox context) will also happen for the next GCC version. > > I noticed yesterday that the previous build of check was done with gcc-10, > so not the previous gcc. Apparently mixing gcc-10 check and gcc-11 glibc was > "fine". > > > Now if we consider it will break again, the more elegant solution would > > be to change check to use dynamic linking instead of static linking. > > Alternatively we can export the GCC version used to compile GLIBC (for > > instance providing libc6-gcc11 or libc6-gcc12) and add some code in > > check to add a depends on that. A simpler way would just be to add a > > depends on the major glibc version (so libc6 (>> 2.36), libc6 (<< 2.37)) > > as we *tend* to change the GCC version used at the same time than the > > major version (at least for sid, not true for experimental). > > So maybe we (Release Team and glibc maintainers) should ignore this issue > for now. At least, not create overly complicated solutions outside of check, > just to accommodate only that package. >
That's indeed the best, it just mean we should carefully look at autopkgtest on new glibc versions, and look for real issues among the flaky tests. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: PGP signature
