On Fri, 2021-04-02 at 16:25 -0400, Leo Famulari wrote:
> I will keep this in mind, pending their reply.
>
> The ticket system automatically added the tag 'hardware/ampere-
> altra'.
> So, it may be a case of "we can have any CPU we want, as long as it's
> an
> Ampere ALTRA"... as Henry Ford said,
On Wed, Mar 31, 2021 at 11:17 AM Leo Famulari wrote:
>
> Yeah, I agree that it's hard to learn about "what's cooking" when you
> first arrive at the mailing lists.
>
> It's true that wikis tend to get out of date, but I think that it won't
> be too bad for this use case. At least, it won't be wors
On Fri, Apr 02, 2021 at 11:56:03AM -0700, Vagrant Cascadian wrote:
> You might want to also ask for hardware that has the extensions for
> 32-bit arm, if we also want to improve substitute availability for armhf
> too. The 32-bit extensions are optional for aarch64, and thus not all
> hardware supp
On Fri, Apr 02, 2021 at 08:57:41PM +0200, Nicolò Balzarotti wrote:
> Hi! There's a typo: "dinary distros" -> binary
>
> also, extra 'this' in: this goal this for x86
Thanks! Fixed :)
Leo Famulari writes:
> Those of us who watch the Guix build farm [0] closely have identified
> the lack of capacity for building ARM binaries as a serious limitation.
>
> As part of our efforts to improve the situation, I've applied for
> donation of aarch64 (64-bit ARM) computing resources for t
On 2021-04-02, Leo Famulari wrote:
> Those of us who watch the Guix build farm [0] closely have identified
> the lack of capacity for building ARM binaries as a serious limitation.
>
> As part of our efforts to improve the situation, I've applied for
> donation of aarch64 (64-bit ARM) computing res
Those of us who watch the Guix build farm [0] closely have identified
the lack of capacity for building ARM binaries as a serious limitation.
As part of our efforts to improve the situation, I've applied for
donation of aarch64 (64-bit ARM) computing resources for the Guix build
farm:
https://git
That is fair. Thank you,
On 4/2/21 12:37 PM, Ludovic Courtès wrote:
Hi Tom,
Tom Hiller skribis:
I am using it with pack and the minimal requirement the size down but
also prevents a large number of dependencies from being pulled in when
building from source.
The latter is true and makes se
Hello!
Brice Waegeneire skribis:
> On 2021-03-03 15:13, Ludovic Courtès wrote:
I’m thinking we could get rid of the mandb hook. However, the
[...]
> What about using mandoc¹, the manpage compiler from OpenBSD, instead of
> man-db? As from it's manual it support specifying the database lo
Hi Tom,
Tom Hiller skribis:
> I am using it with pack and the minimal requirement the size down but
> also prevents a large number of dependencies from being pulled in when
> building from source.
The latter is true and makes sense to me, but note that both take about
the same amount of space:
On Thu, 2021-04-01 at 21:33 +, Luis Felipe wrote:
> I just sent a patch to include a link to the wiki in the Help page (
> https://issues.guix.gnu.org/47555).
>
> If the patch is applied, I can send a separate patch to update the
> Help menu as Vincent suggested:
>
> Help
> • GNU Guix Manual
> > Early cutoff is a very desirable property that nix does not have (and I
> > assume therefore that neither does guix).
> The “intensional model” that Julien mentioned, or what the Nix folks now
> refer to as “content-addressed derivations”, have this early cutoff
> property. It’s one of th
On Thu, 2021-04-01 at 16:36 -0400, Tom Hiller wrote:
> I am using it with pack
I assume as "guix pack cmake other-package ..."?
This seems a valid use case, although there is a
case to be made to only make the ‘fully capable’
packages visible.
In any case, you can work around this with
guix pa
13 matches
Mail list logo