all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Leo Famulari <leo@famulari.name>
To: Richard Sent <richard@freakingpenguin.com>
Cc: guix-devel@gnu.org, Ricardo Wurmus <rekado@elephly.net>,
	67535@debbugs.gnu.org, Efraim Flashner <efraim@flashner.co.il>
Subject: Re: Does anyone use i686-linux? [was Re: bug#67535: ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux]
Date: Mon, 29 Jul 2024 20:01:12 -0400	[thread overview]
Message-ID: <ZqgtSPDRFmqEaptq@jasmine.lan> (raw)
In-Reply-To: <A882707A-3035-4986-B630-23CDFD20B6C7@freakingpenguin.com>

On Mon, Jul 29, 2024 at 11:00:36AM -0400, Richard Sent wrote:
> For consideration, I know at least one 3rd-party channel relies on being able to create a multiarch container containing i686 packages. I'll refrain from linking since it packages nonfree software. This is an example where keeping an old architecture around is more complicated than simply counting the number of active machines using said architecture.

People have presented some good reasons for keeping at least some level
of i686 support.

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.

> Perhaps we could tally the number of substitutes served for supported architectures and use that as our metric for liveliness.

I'd love this! Not just for deciding when to remove support, but to
measure if adding support gains more users.


  reply	other threads:[~2024-07-30  2:12 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-29 20:55 bug#67535: ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux Leo Famulari
2023-12-06 12:25 ` Efraim Flashner
2024-07-26 18:51   ` Does anyone use i686-linux? [was Re: bug#67535: ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux] Leo Famulari
2024-07-26 20:17     ` Kaelyn
2024-07-28 21:49     ` Efraim Flashner
2024-07-29 12:33       ` Ricardo Wurmus
2024-07-29 15:00         ` Richard Sent
2024-07-30  0:01           ` Leo Famulari [this message]
2024-07-30  1:21             ` Richard Sent
2024-07-30 14:39               ` Leo Famulari
2024-08-01 23:51                 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-07-30 15:18               ` Efraim Flashner
2024-07-30 21:02         ` bug#67535: " André Batista
2024-08-01 20:12           ` Leo Famulari
2024-08-02  8:36             ` Ricardo Wurmus
2024-08-02 19:34             ` bug#67535: " André Batista
2024-09-05  9:42           ` Ricardo Wurmus
2024-09-05 23:52             ` André Batista
2024-08-12 14:03       ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZqgtSPDRFmqEaptq@jasmine.lan \
    --to=leo@famulari.name \
    --cc=67535@debbugs.gnu.org \
    --cc=efraim@flashner.co.il \
    --cc=guix-devel@gnu.org \
    --cc=rekado@elephly.net \
    --cc=richard@freakingpenguin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.