From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id MHMQLogEqWb/WAEA62LTzQ:P1 (envelope-from ) for ; Tue, 30 Jul 2024 15:19:37 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id MHMQLogEqWb/WAEA62LTzQ (envelope-from ) for ; Tue, 30 Jul 2024 17:19:37 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20230601 header.b=fE0J3XTG; 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"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1722352776; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=jc4vbar+ty3tL+gSLj+zdFFk25j/Qvdnm6bKSQs1xFs=; b=GHwwrmsnMxWSUxeFa9vbVe4t2i13m9yP6wwyLKWthDVsr4ZJKUYKNaRHOyLqOFqepnKoeF AYiaqPe5xFnUwIgh4Y6qXQyZIcHNgXVxkuL7d+IBJmh2YK1Jv0k8R3S/RvlxlTOJbm/U80 ZT88rJLwi+UH2kscN6EEmlk8+gBSltBWVGbz1VnCl9omJ3rKl6dzLEWVcGpypICU+8kgJO eHqWdWoDomRa3/bbDDFedf2XtMI+IqIC4hGn425cIKyUvv0nUwjB3umYAfUjnGaGrkDghM u8Ty6CXKbdns5TpfdCjuYdBev0AMADMuLFmxh6ObpIwHE2okj7ujmZWWVXcumQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20230601 header.b=fE0J3XTG; 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"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1722352776; a=rsa-sha256; cv=none; b=fyhCX3u8u8pHF+TeNUeQgjehA9Fu0iuJY2UrcBdCaR6XkRIOHLVsWXtPrjTviO2Wwf7688 Nh1mXGfCBXGsvAsMkkflqaTwrZkF6IU+Sulx89UoA+M7zEwmAQqcBccR9z99IszKXmGfO7 lxGKzepHV2UU9k5qZJZE6sbavOp3MTkwp+lGyb3i8ShXDdPZffbW/0GkAg325Rcrz+alkV Zhp579gCHbG5J7mnEpmi81QyKTdN07N1NgBYe2HvVGDK1ANUdKbCMWjDD16lCbBupQu2rf PwaM3cN8d0SFwaWTTBOciL63VFtz40dwg0+tOHNznNp5k3MEkDe0sj9qXPUP1A== 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 7CBBC26901 for ; Tue, 30 Jul 2024 17:19:36 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sYocu-0001y7-Mj; Tue, 30 Jul 2024 11:19:00 -0400 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 1sYocp-0001xr-OM for guix-devel@gnu.org; Tue, 30 Jul 2024 11:18:55 -0400 Received: from mail-qk1-x730.google.com ([2607:f8b0:4864:20::730]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sYocn-0006Z5-Lb for guix-devel@gnu.org; Tue, 30 Jul 2024 11:18:55 -0400 Received: by mail-qk1-x730.google.com with SMTP id af79cd13be357-7a1d3e93cceso389466385a.1 for ; Tue, 30 Jul 2024 08:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722352732; x=1722957532; darn=gnu.org; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:sender:from:to :cc:subject:date:message-id:reply-to; bh=jc4vbar+ty3tL+gSLj+zdFFk25j/Qvdnm6bKSQs1xFs=; b=fE0J3XTG+CkEfVrkYcQPSh4cv3atJJQnj0ftDWg8ueWUItlKLySjn9PC/wvjhVDrXD REv+mArHrDdN8WYEfNe2RVKDOzbV1zOx5GMaJAcYZ2kTLEIA74/onDtY1JFd81ggo6Gt DmZZdNssElfz+3pCqfJQGsD/UZkxakAf93Mo+XtQkusoYjIyFDsieQz9Wewr+XuN0D3A HJ7KhfAkQLHbJMMjF2vUglkXCmNXRLb8VWgyB/l0DF65l+xQUKNLD7Q+x0WMriiIHSE4 Jj6B596FL5HpBSWToYfwvgVODIfVUZfvpgKjQX1ernLCUAie0cxyaiY6NxN11lLAyGBV Q8kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722352732; x=1722957532; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jc4vbar+ty3tL+gSLj+zdFFk25j/Qvdnm6bKSQs1xFs=; b=wB/BIkTwMCAdm7KQe49RQKznPW8Io+wBrNW5sfobfpm7VhwDclf0Ar1NlWs0zVRbSe LXPyXqtLIF0csXMTOh86S4glK3/NKTBgUT+tXkrLngJwvs/sHS6dxAkkgytWEqGcKYAc Qmq4ZvQIrsVi0LqqX4+SZAC4iuOEl11EkS/Mnjh4uAl4XCxZHKldvan4uBUoU6/YrydR iRcWt9FcJ05SykAksRyaF6SSMZPOlYkSQ2iwtz9vo2U0F07EwP1r6ga6ubw/m6RdRTxp ArM9kKBWh35fxh2RANXYqJJQYa3QIUmx0g+nykGvvFN46/JvXmb7LwqTsSNkJjtusbWf E9Og== X-Forwarded-Encrypted: i=1; AJvYcCUJI9feI021hJCtU3Ta6mu+mHQjsr7qraazunnA4NoZiAQwy9n+Ct70XYbLwFtfbKWabE3XjXSs5NuwyjpIUWGQnwI= X-Gm-Message-State: AOJu0YxFbUyeWdJpZ+zZ9cRG1izAsO/KNO5VZDZdYnYUn0EE9KZPGpPG mK3R3AyOEhum2QczBTo+oHDcOsxFPw1l0xMj2Lnrpkk4AODiOLZA4T2V0g== X-Google-Smtp-Source: AGHT+IEau+gC0AWn0ZtGSkFiE6rQ5ANN9+Nbw1qkqgUtfrMWNp6SN97en7S5pUwK8H6KrrAdUSldnQ== X-Received: by 2002:a05:620a:25ca:b0:79e:f9f4:3e99 with SMTP id af79cd13be357-7a200c957demr364718585a.1.1722352732105; Tue, 30 Jul 2024 08:18:52 -0700 (PDT) Received: from localhost (ool-ad039216.dyn.optonline.net. [173.3.146.22]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7a1d745f404sm642537885a.131.2024.07.30.08.18.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jul 2024 08:18:51 -0700 (PDT) Date: Tue, 30 Jul 2024 18:18:50 +0300 From: Efraim Flashner 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] Message-ID: Mail-Followup-To: Richard Sent , Leo Famulari , guix-devel@gnu.org, Ricardo Wurmus , 67535@debbugs.gnu.org References: <87sevsxtqg.fsf@elephly.net> <87v80n8yiy.fsf@freakingpenguin.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7W3n6y91InRnqu9a" Content-Disposition: inline In-Reply-To: <87v80n8yiy.fsf@freakingpenguin.com> x-ms-reactions: disallow X-PGP-Key-ID: 0x41AAE7DCCA3D8351 X-PGP-Key: https://flashner.co.il/~efraim/efraim_flashner.asc X-PGP-Fingerprint: A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Received-SPF: pass client-ip=2607:f8b0:4864:20::730; envelope-from=efraim.flashner@gmail.com; helo=mail-qk1-x730.google.com X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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-Country: US X-Migadu-Flow: FLOW_IN X-Spam-Score: -4.02 X-Migadu-Queue-Id: 7CBBC26901 X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -4.02 X-TUID: /KD1NzKXf9v3 --7W3n6y91InRnqu9a Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. 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. --=20 Efraim Flashner =D7=A8=D7=A0=D7=A9=D7=9C=D7=A4 = =D7=9D=D7=99=D7=A8=D7=A4=D7=90 GPG key =3D A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted --7W3n6y91InRnqu9a Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmapBE0ACgkQQarn3Mo9 g1F/uA/9HPYjvpj+lSoWxKe91Uwc15OW0nmB/nDgkCbyaz7nhwqFUQSngP2aTqA4 CNI/EEnMtjLR7KoEGEFRbRa8bRF/rxa4rW68HTZApxJ4DL7SFvL+YBQJweKNBz0h HU8NnmLEGqG2jNSpoxNOUpBXRL/bcFhgRe/kJsFmChfLaj7Blf8twwNo2IA1QlZN kIswFOkrf7UBHYI23BZo6I89eo8Rd4A2DeVM7TCME50KV0XTks6dz7wygJ6sJT86 F+bzpAIZ+Wu0t7LLl5j2zqMxUzqsFSR6hqr6ybjW0LjLl0mDWMjtMjvquMqZQDrv 1I7JfBMO6JPsW91J3MktW8kur/+dW7CW+xBhe+PU0kqSMW5YfyfbcvfEOCynT05x ad1UbSBTYJu7EgTb2izGTMgAqA0YXpezMtgjOIXmyHJ87T91sVQvIusX7md2Hcht Zo4ARgyIrNMQsNg3Saxk9d3Wq41FwxQlNb1NjKR+x+kbccg50gCsWgqBe0BVXirv ALhmbxSkzO5gHkRRmv2KA5Ztt8z/te6kn0PUIlAWTRX+XP11imWBv/E5sD9hGvjZ yafQKPEr3r+c1WoWdpaAxoPpE1Th6szZ5U11DN1MxkNn+e4OZNd9lY2O5ZZVXsvd RK1Micqd3mBEfyu2bSix3Yw/MCwUQqhG+v27ahDGIwGqDxyYvKs= =CfPU -----END PGP SIGNATURE----- --7W3n6y91InRnqu9a--