From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cheddar.halon.org.uk (cheddar.halon.org.uk [93.93.131.118]) by sourceware.org (Postfix) with ESMTPS id C3AF5385840F for ; Sat, 12 Nov 2022 20:23:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C3AF5385840F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=wookware.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=wookware.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wookware.org; s=cheddar; h=In-Reply-To:Content-Type:MIME-Version:References :Message-ID:Subject:Cc:To:From:Date:From:Reply-To:Subject: Content-Transfer-Encoding:Content-ID:Content-Description:X-Debbugs-Cc; bh=+nff9mQRe2Mz/Kk443bJXpX/mAXHiwv2wka9oSVloJo=; b=xDxUx+XGje3ToFfYZljyDgvyyA gUczoz6UxKS10vs3BrJZ7K8atsTO7zCCUH29y5ASUxlTPf9woG4F3JrUNFXHa97u+hokQXAIhweXT AjEZXh7m2dGVWfA2ujcvvao9nCK965IAvqNq0kJVsWTDYlk6Y6JHBwdJnJc6A+ejECWrSz+OH4V89 ggHcXYUXOa+AKpusVQU4FVxKZZJmGs6kpJswENG3cjAf0OYOkH+bCbInM1EP1D2M8pNOWbBlaE6oo 1oubS4GydcJw934lP7Bm5+mm9PoGjIs2NaeWXvHj2XiXj+T3/6mkZLm7PPfo3wUv9cqw+2dFjVeUn ztfO8Eww==; Received: from wookey by cheddar.halon.org.uk with local (Exim 4.92) (envelope-from ) id 1otx29-0007Ti-FW; Sat, 12 Nov 2022 20:23:21 +0000 Date: Sat, 12 Nov 2022 20:23:21 +0000 From: Wookey To: Paul Eggert Cc: Bruno Haible , Zack Weinberg , Sam James , Florian Weimer , Carlos O'Donell via Libc-alpha , autoconf@gnu.org, c-std-porting@lists.linux.dev, toolchain@gentoo.org, bug-gnulib@gnu.org, Arnd Bergmann Subject: Re: On time64 and Large File Support Message-ID: <20221112202321.GO27919@mail.wookware.org> References: <6953747.nAD6y4vbrC@nimes> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Q2LtEObxj4fS/vxA" Content-Disposition: inline In-Reply-To: Organization: Wookware User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --Q2LtEObxj4fS/vxA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2022-11-12 11:15 -0800, Paul Eggert wrote: > On 2022-11-12 10:50, Bruno Haible wrote: > > I'm saying > > "tiny" because we are still 15 years away, and new releases of the (not > > many) affected packages are likely to come in the next 1-2 years. >=20 > Not so "tiny", I'm afraid. My department is still running a server with > libraries and executables that are over 17 years old. Nobody disagrees with the idea that 2038 fixes are now fairly urgent if we want to avoid real-world stuff breaking in 15 years time. That has been increasingly clear for the last few years. But the point here is that we need a bit of co-ordination and a plan, particularly for binary distros. This isn't a minor change that should just happen to people because there was an autoconf upgrade. Or at least I don't think it is. My assumption is that if you just turned it on in random packages as they were uploaded, there would be very serious (unacceptably bad) breakage - we need to co-ordinate sets of matching-ABI packages to upgrade together, and the worry is that the matching set is 'most of the distro'. Now, I'm not yet sure if just having autoconf 2.72 will actually break things. AIUI, these changes only apply where LFS (-D_FILE_OFFSET_BITS=3D64) is turned on, so in Debian at least, where that is not the default on 32bit arches, maybe this is OK. But probably quite a lot of packages already enable LFS so they are suddenly going to get a new ABI if they expose timet anywhere? https://codesearch.debian.net/search?q=3DAC_SYS_LARGEFILE&perpkg=3D1 shows 163 pages of hits, and a quick peruse suggsts that AC_SYS_LARGEFILE is used by a lot of packages (as you might expect - this transition has been going on for many years). And just having that macro in configure.(in|ac) will turn 64-bit timet on if you autoreconf with 2.72. Right? We can't embark on that until we decide whether this transition will be done within the existing arch/triplet or with a new one. I agree we should decide that pronto. And I think that 'we' is bigger than just Debian. If new autoconf (and gnulib) just turns this on within the existing arch/triplet then we, the distro, can't use those new versions unless we back out those changes, or until we decide that we are going to attempt this ABI transition within the existing arch/triplet. I'm OK with this being done either way (complicated transition within arch/triplet, or whole-world rebuild with new arch/triplet) once the size of the problem (and thus the amount of work) is reasonably understood and there is some consensus amongst distros. TTBOMK we need some more research before we can make that choice (although I realise some others are further down this road than I am, and yes I did plan to get to this point about a year ago, so apologies for slowness). Hence my suggestion of a full discussion on the cross-distro list. It is overdue. However my limited understanding as of right now says that autoconf 2.72 tying 64bit time_t to use of AC_SYS_LARGEFILE means that 2.72 can't be used in debian yet. So I currently favour not tying them together in this release. People have been using AC_SYS_LARGEFILE without 64bit time_t for many years now so it's not yet clear to me why that cannot continue. And even if it is a good idea to complete both transitions in the same upheaval we can't just have everyone who enabled LFS sometime in the last 20 years suddenly being forced into the time_t change (can we?). Wookey --=20 Principal hats: Debian, Wookware, ARM http://wookware.org/ --Q2LtEObxj4fS/vxA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmNwALMACgkQ+4YyUahv nkfRxg//eRuWZwRH+1/soiVQD9KnslU7/MEJ6dKR+gn2oPgKSoQ7WXNEyvOdmfTv uFso5t/hhiKI+FPsdHR5V7Omz6jE852ZmQT7VQ+01svb3zeXoVRW2E7645N4YmA5 IZIvueQKgr4Yj52xWt37ppDpH3TwYEyZzvyu5Ti0iyy/m9PNwK/C5QDlMVDabMHN e7Ji3CHVxAciGO6kggtrlFuYnkkk1F8GLIz9in/06PIGqdzyL8Yyy5LmEPXgjwIJ s0m8lk0EYHzmDfJJZpGdIMwwdaneR/a96Y9lYfg4zcrhd3TvQcs0cWxrG60XLWU/ N2Xbl/UpjQlS2WZ7Tm+MPg4SWfvKr0dnIIrQt70/cTGhDvNx8pjZ8vNck3NDA7z6 bF6KUHeljrFedWKRaogKxJMecRrbR/S7uzw/mfqkpaGNAQv734f54eICvxJ8fHvH RVHXQU+4xVys7sBQ/QqhUfwvSjXe7JwloCumr39H2PRNfMuwoaDo8SH52XcZp2nm U5L29jOb6x91m4DNDSrQRD+4qqktTL7+DhrmRiNjIcOqDehQHxNxb01PHIfU/tvX RatijzbvR1l2L1vgf6zSkk8z9pPaELPVbnyQQ5ABuoTI7vP7U/bi0rAIwFP+ie/R KVkGqHYMJ/FhZlth2o3JE2jSRjoYG/uRyHtwreWQNYQVNZrZGkQ= =4Ybm -----END PGP SIGNATURE----- --Q2LtEObxj4fS/vxA--