From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14885 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: time64 switchover -- distro plans? Date: Tue, 29 Oct 2019 13:05:22 -0400 Message-ID: <20191029170522.GF16318@brightrain.aerifal.cx> References: <20191027040820.GV16318@brightrain.aerifal.cx> <65a0ee78-eaaf-f3fa-84f3-782fbdc4b06e@adelielinux.org> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="167446"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14901-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 29 18:05:37 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iPUw5-000hUS-Gy for gllmg-musl@m.gmane.org; Tue, 29 Oct 2019 18:05:37 +0100 Original-Received: (qmail 19635 invoked by uid 550); 29 Oct 2019 17:05:35 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 19614 invoked from network); 29 Oct 2019 17:05:34 -0000 Content-Disposition: inline In-Reply-To: <65a0ee78-eaaf-f3fa-84f3-782fbdc4b06e@adelielinux.org> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14885 Archived-At: On Mon, Oct 28, 2019 at 06:52:04AM -0500, A. Wilcox wrote: > On 26/10/2019 23:08, Rich Felker wrote: > > This thread is a call for feedback from distros (or other > > similarly-situated systems integrators) using musl with 32-bit archs. > > Everything is moving smoothly on my side for upcoming time64 > > switchover which will be included in the next release, 1.2.0. But with > > this involving ABI issues between packages and changes that some > > software may not be ready for, it will likely be at least somewhat > > disruptive to distros/users. > > > > In particular: > > > > * Are there resources I could/should make available that will help > > things go smoothly? > > > > * Are you available for testing building and running packages against > > time64 musl prior to release? > > > We can launch a full distro build against any given musl commit on > 32-bit PowerPC and ARM (v7). We have test suites enabled on 1280 of our > 2087 packages (~61%) so that should help find bugs if any. I can also > then install it on a Power Mac G4 and a Raspberry Pi 2 we have set aside > for testing experimental changes. Excellent. > It'd be much more difficult, but if nobody else offers i586 testing, we > *may* be able to do that as well. Let us know. I think adding further 32-bit archs to test has diminishing returns. The big thing is to catch and be prepared for packages that might break when building with 64-bit time_t. I can think of various ways this could happen, for example attempts to declare and use functions without including the appropriate header, or without a declaration at all. Also, using %ld for printing time_t (already broken for x32 but nobody uses or tests x32 so... ¯\_(ツ)_/¯ And of course, aside for preparedness for packages breaking from bugs on their end, there's the matter of finding bugs on the musl side. These will almost surely not be arch-dependent, but high-level errors at the C source level. One other area of testing that would be useful, and far easier than rebuilding, is dropping a time64 libc.so into an existing distro build with 32-bit time_t, to see if you hit any bugs with compat shims. I did a minimal level of this with Adélie Linux in a container when I first got time64 and the shims to a testable level towards the end of the summer, and found and fixed a few bugs. > > I'll also be building and testing some software on i386 and sh at > > least; I already started with busybox, which just got the main > > time64-readiness issue I was aware of fixed. > > > > I think I'll push the last of the time64 patches within the next week, > > possibly sooner, meaning "distros start testing" is a thing that could > > begin really soon if anyone's up for it. > > We would probably be ready for this in November. Timing sounds good too. I'm doing final review before push now so the changes will be upstream soon in plenty of time for that, and aim for release is "sometime" in November. Rich