GNU bug report logs - #67535
ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux

Previous Next

Package: guix;

Reported by: Leo Famulari <leo <at> famulari.name>

Date: Wed, 29 Nov 2023 20:56:02 UTC

Severity: normal

Done: Leo Famulari <leo <at> famulari.name>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Leo Famulari <leo <at> famulari.name>
To: Richard Sent <richard <at> freakingpenguin.com>
Cc: guix-devel <at> gnu.org, Ricardo Wurmus <rekado <at> elephly.net>, 67535 <at> debbugs.gnu.org, Efraim Flashner <efraim <at> flashner.co.il>
Subject: bug#67535: 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
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.




This bug report was last modified 191 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.