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

Previous Next

Full log

View this message in rfc822 format

From: Richard Sent <richard <at> freakingpenguin.com>
To: Leo Famulari <leo <at> famulari.name>
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 21:21:57 -0400

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

> 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.

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.

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.

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?

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.

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.

Thanks! :)

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

Previous Next

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