From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id qL0+AfKnMGcsbAAA62LTzQ:P1 (envelope-from ) for ; Sun, 10 Nov 2024 12:32:50 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id qL0+AfKnMGcsbAAA62LTzQ (envelope-from ) for ; Sun, 10 Nov 2024 13:32:50 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=Nst1kR3N; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1731241970; a=rsa-sha256; cv=none; b=pYqFHhrnJklCjw/7TzLmh2QTxjf6KNB0vBpDDlRcpR0yIKNCVrzkqC2BEl1PeuO29n5wnd JAreoaKxlm1lXG5+FYuM9psgXj2dwdjHVF9bhDTk91KUx+uj1e9dU1cKRR1nrK89geIxQC 4RZAcFATNDGha1R+IYTh6MsRQ4FuWMzR257h/Yfon7Y7KkchBPobVqOD3IGR71ZiOw3L7s a9+dsLG+Nayxu2GlZ2sjBy+Jj43lniIBt1smfxCjNMsVvzk0t9MZK37bBnpt2nGvYdhLhl XIU/wrjltghO3zeWHuxsxSIkBk7UXZnK+MxQO7RaU1+2cGE/zjnXXAlyG8KH5A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=Nst1kR3N; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1731241969; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=vzJrKCGFNMl1gWyOsP+pcu+VBZf+lYCzR/cLGCi35WU=; b=OHOd7bYDe7GlixPkb3fkgbJCd9i+gXd4n97zeCDRKFbCRtKlKjuNDCVEARwfmgPcAgS8pi 5CYPxhFJ2ESYwIaTpvpB+wk9C9wAO70pdLFD6rA9AyvP8OSVYkgEQujQtcWd0Ina/Xk5D0 RjvTRk5Pxa636Wh8Sy+nTki6HgMUd+kwQ8bSCQvJNIRvlKU/sNWj7INT8NCbPWUeCoBEOo GpzPuyn7pjt9drI3TW7TZjT11a3KTlszhXSM18HIqsmtUj2vUBEiRpZ/zzxSwsQ2rlkVYp A7pNwgwrtzh+tAiIpzIhJqZO/qGvRw5pKy/7gVJ2e/L1+gxxn6p/nktXn97rQQ== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id CD79C192A6 for ; Sun, 10 Nov 2024 13:32:49 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tA777-0004ob-FX; Sun, 10 Nov 2024 07:32:21 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tA775-0004oA-Bj for guix-devel@gnu.org; Sun, 10 Nov 2024 07:32:19 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tA772-00061m-GC; Sun, 10 Nov 2024 07:32:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=vzJrKCGFNMl1gWyOsP+pcu+VBZf+lYCzR/cLGCi35WU=; b=Nst1kR3NI9ETwRtbEDSH 9vpMNxxUqCjU9mCfQqy6gwGs40haXjt9WXT9HmwWufPfrcw996oJWNqVFSevtw9Zs+BzQZ3nHNdYo 2jMIs5heuuggb13Ys7uVBUKqSKo4xDfqUrHS5Eoi/n30mNbNOvJD9LL3DDWzWPT2h+RgL0j5f8FMA PLXARdEd+rHciVc80QsrQYCPHU+TAALDw7xDwHwW75mnNByVDKSHOMi6iUzrdEaqHnP5r6DdvO+yL 74ECCkElRtKBLY39m1+3sbTolGRp/tHBVk9mG2hlVpdOWowLhuqHJZkzsrKnLCe4moI3uPAv0wgcP kpX2GzqSsTItMQ==; From: To: Richard Sent Cc: Leo Famulari , guix-devel@gnu.org, Ricardo Wurmus , 67535@debbugs.gnu.org Subject: Re: Does anyone use i686-linux? [was Re: bug#67535: ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux] In-Reply-To: (Efraim Flashner's message of "Tue, 30 Jul 2024 18:18:50 +0300") Organization: AvatarAcademy.nl References: <87sevsxtqg.fsf@elephly.net> <87v80n8yiy.fsf@freakingpenguin.com> X-Url: http://AvatarAcademy.nl Date: Sun, 10 Nov 2024 13:32:12 +0100 Message-ID: <87zfm7z2ur.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -1.24 X-Spam-Score: -1.24 X-Migadu-Queue-Id: CD79C192A6 X-Migadu-Scanner: mx12.migadu.com X-TUID: lK8OBvd7bQek Efraim Flashner writes: Hello, > On Mon, Jul 29, 2024 at 09:21:57PM -0400, Richard Sent wrote: >> Leo Famulari writes: >>=20 >> > People have presented some good reasons for keeping at least some level >> > of i686 support. >> >=20 >> > But unfortunately, 3rd party channels cannot be one of them, whether or >> > not they follow the FSDG. >> > >> > Of course, we won't deliberately make their work more difficult, and >> > maybe we consider their needs if it's easy, but I think they shouldn't >> > be considered to present compelling arguments for us to make decisions >> > within GNU Guix, especially if it involves us doing extra work. >>=20 >> That's true enough! I don't mean to say that 3rd party channels using >> i686 is sufficient reason alone to support it. I just consider it worth >> keeping in mind. >>=20 >> In my opinion, when we ask questions like "Does anyone use X", it >> doesn't really matter if that answer is "Yes, in my custom config" vs. >> "Yes, in this 3rd party channel my custom config uses". The primary >> distinction between the two is if the code is shared publicly. I don't >> see that line in the sand being helpful when asking about usage. >>=20 >> To phrase this another way, if I instead said "I use multiarch >> environments containing i686-linux Guix packages to run software that >> can't be ported to x64" without mentioning 3rd-party channels at all, >> would that suddenly become valid usage? Why? >>=20 >> i686 multiarch environments are useful in certain cases. Regardless of >> whether those environments are provided in Guix proper, in a custom >> config, or a 3rd party channel, user-facing functionality will be lost >> if we remove them. >>=20 >> Breaking changes are okay, and if we consider this too niche of a use >> case or too high of a maintenance burden it should be dropped. I do >> believe it should progress into the consideration stage instead of being >> discarded outright. >>=20 >> Thanks! :) > > I would argue that some of the bootstrapping effort which is i686 > specifically and can't be easily ported to x86_64 (such as compilers) > are a perfectly fine reason to need something to be built natively vs > cross-compiled. Another email mentioned wine, which, while I don't > believe it is currently possible to cross-compile in guix, may or may > not work correctly when used cross-compiled as an input for wine64. Also, I have been "using" Guix i686-linux to for my work on bringing i586-gnu Guix/Hurd to real 32bit hardware, by installing and re-installing Guix/hurd from Guix/linux and dual booting. i586-gnu does not boot on any of my older 64bit machines. A draft blog post is in the works about this. While this could technically also be done by installing debian-i386 and do foreign-distro guix development, that would be far from ideal. > Without directly answering the question of "is the phrasing wrong" vs > "is the burden too high", IMO there's not really a difference between a > package in a separate channel vs a custom package in someone's config, > other than how easy it is to share. If we said, despite the move to Qt6 > and upstream chromium dropping support for 32-bit architectures and thus > affecting i686 support in qtwebengine, that it was imperative that i686 > keep a working qtwebengine and that we couldn't upgrade it unless we > knew it worked on i686 that might be a problem due to "The Dangers of > the Internets", but ongoing work to update patches to keep it working > would be good. Or I suppose another example is if we froze Gnome at a > version that supported the old librsvg because the new one depends on > rust, instead we've worked around it so that those that can't use the > new one use the old one, and those packages which can't use the old one > specifically use the new one, with the side effect that gnome isn't > supported on all architectures. > > I would not be against selecting some scientific packages and marking > them as 64bit only with a note that although they might build on 32bit > architectures, they would never be used there and there is no reason to > try to even build them. Indeed, it would be nice to at least have a basic exwm system available. Greeings, Janneke --=20 Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar=C2=AE https://AvatarAcade= my.com