Re: Jam: which licence is this?

[Vagrant Cascadian]

On 2021-04-25, Jack Hill wrote:
> On Sun, 25 Apr 2021, Vagrant Cascadian wrote:
>> On 2021-04-25, Jack Hill wrote:
>>> I'm working on packaging the Argyll Color Management System for Guix. To
>>> build, it uses the Jam tool, which has the following license:
>>>
>>> ```
>>> This is Release 2.5 of Jam, a make-like program.
>>>
>>> License is hereby granted to use this software and distribute it
>>> freely, as long as this copyright notice is retained and modifications
>>> are clearly marked.
>>>
>>> ALL WARRANTIES ARE HEREBY DISCLAIMED.
>>> ```
>>
>> Permission to use, check.
>> Permission to study, probably(?)
>> Permission to share, check.
>> Permission to modify,  ?
>>
>> Is it even free software? There is no mention of modification which
>> doesn't appear to be free by my layman's reading...
>
> I do see a mention of modification "…modifications are clearly marked." 

Yes, somehow I glazed over this at first... it implies that
modifications which are clearly marked are allowed. :)

live well,
  vagrant


signature.asc
Description: PGP signature

Re: Jam: which licence is this?

[Jack Hill]

I have asked the FSF licensing lab about this in RT #1718940

Best,
Jack

Re: Jam: which licence is this?

[Jack Hill]

On Sun, 25 Apr 2021, Vagrant Cascadian wrote:


On 2021-04-25, Jack Hill wrote:

I'm working on packaging the Argyll Color Management System for Guix. To
build, it uses the Jam tool, which has the following license:

```
This is Release 2.5 of Jam, a make-like program.

License is hereby granted to use this software and distribute it
freely, as long as this copyright notice is retained and modifications
are clearly marked.

ALL WARRANTIES ARE HEREBY DISCLAIMED.
```


Permission to use, check.
Permission to study, probably(?)
Permission to share, check.
Permission to modify,  ?

Is it even free software? There is no mention of modification which
doesn't appear to be free by my layman's reading...


I do see a mention of modification "…modifications are clearly marked." 
Compare with the gnuplot license, for which modifications can only be 
distributed as separate patch files


/*[
 * Copyright 1986 - 1993, 1998, 2004   Thomas Williams, Colin Kelley
 *
 * Permission to use, copy, and distribute this software and its
 * documentation for any purpose with or without fee is hereby granted,
 * provided that the above copyright notice appear in all copies and
 * that both that copyright notice and this permission notice appear
 * in supporting documentation.
 *
 * Permission to modify the software is granted, but not the right to
 * distribute the complete modified source code.  Modifications are to
 * be distributed as patches to the released version.  Permission to
 * distribute binaries produced by compiling modified sources is granted,
 * provided you
 *   1. distribute the corresponding source modifications from the
 *released version in the form of a patch file along with the binaries,
 *   2. add special version identification to distinguish your version
 *in addition to the base release version number,
 *   3. provide your name and address as the primary contact for the
 *support of your modified version, and
 *   4. retain our contact information in regard to use of the base
 *software.
 * Permission to distribute the released version of the source code along
 * with corresponding source modifications in the form of a patch file is
 * granted with same provisions 2 through 4 for binary distributions.
 *
 * This software is provided "as is" without express or implied warranty
 * to the extent permitted by applicable law.
]*/

ajam clearly marks its modifications by including this in its readme:

"""
This if "Argyll-Jam", a simple derivative of the "FT-Jam" build tool, based and
100% compatible with Jam 2.5. See http://www.freetype.org/jam/ for more
details about FT-Jam.

This is the "FT-Jam" 2.5.2 release, with minor ArgyllCMS tweaks,
and the ArgyllCMS V1.3.3 Jambase as the default rule set.

Note that you'll find the original Jam README in the file README.ORG
"""

Thoughts?
Jack

Re: Jam: which licence is this?

[Ricardo Wurmus]

Vagrant Cascadian  writes:


On 2021-04-25, Jack Hill wrote:
I'm working on packaging the Argyll Color Management System for 
Guix. To 
build, it uses the Jam tool, which has the following license:


```
This is Release 2.5 of Jam, a make-like program.

License is hereby granted to use this software and distribute 
it
freely, as long as this copyright notice is retained and 
modifications

are clearly marked.

ALL WARRANTIES ARE HEREBY DISCLAIMED.
```


Permission to use, check.
Permission to study, probably(?)
Permission to share, check.
Permission to modify,  ?

Is it even free software? There is no mention of modification 
which

doesn't appear to be free by my layman's reading...


Which brings up an ugly bag of worms regarding boost...


The jam build system in boost is also licensed under the Boost 
license:


The build system source is under tools/build/src/engine/, and the 
jam.cpp file has these notes:


--8<---cut here---start->8---
/*
* /+\
* +\   Copyright 1993-2002 Christopher Seiwald and Perforce 
Software, Inc.

* \+/
*
* This file is part of jam.
*
* License is hereby granted to use this software and distribute 
it freely, as
* long as this copyright notice is retained and modifications are 
clearly

* marked.
*
* ALL WARRANTIES ARE HEREBY DISCLAIMED.
*/

/* This file is ALSO:
* Copyright 2001-2004 David Abrahams.
* Copyright 2018 Rene Rivera
* Distributed under the Boost Software License, Version 1.0.
* (See accompanying file LICENSE_1_0.txt or copy at
* http://www.boost.org/LICENSE_1_0.txt)
*/
--8<---cut here---end--->8---

FWIW I consider the Jam license to be free; it does mention 
modifications and only asks that they are “clearly marked” 
(whatever that means).  It’s much saner than the LaTeX license 
that asks that any modified file be renamed; it is only acceptable 
to the FSF license team because TeX has an aliasing mechanism, so 
it’s not a practical obstacle, merely a serious annoyance.


--
Ricardo

Re: Jam: which licence is this?

[Mark H Weaver]

Hi Leo,

Leo Famulari  writes:

> On Sun, Apr 25, 2021 at 01:25:21PM -0400, Mark H Weaver wrote:
>> In general, I think that the license field of a package should include
>> all licenses that cover any files in its source distribution (by which I
>> mean the output of "guix build --source").
>> 
>> My rationale is that it is the source code, and not merely the build
>> outputs, where users will want to exercise the four freedoms of free
>> software.  For example, when a user wishes to study, modify, or
>> redistribute the software, they will want to be able to do those things
>> with the entire source distribution.
>> 
>> Does that make sense?  What do you think?
>
> It makes sense, but we've never done that.
>
> For example, the autotools files such as configure.ac bear a simple
> permissive license, but we do not mention that in the license field of
> the 'hello' package.
>
> Instead, we typically use the license that covers the overall program,
> not the (sometimes dozens of) licenses of every single file in the
> source distribution.

You're right, and that's a good point.  It's true that Guix has a
longstanding practice of omitting more lax licenses when there's also a
more restrictive license covering the same package.  I should have
mentioned that.

However, I think that longstanding practice is orthogonal to the
question of whether licenses covering build system components can be
omitted from the 'license' field.

> Can you clarify your expectations regarding which files' licenses should
> be mentioned in the package definition?

I haven't thought much about the aforementioned longstanding practice,
but that's not what I'm objecting to here.

Specifically, I'm objecting to the idea that the 'license' field need
only describe the files present in the build outputs.  For example, if a
hypothetical package is licensed under Expat but uses a build system
covered by the the Q Public License (QPL), I don't think we can omit
mention of the QPL just because those components are only used during
the build.

Does that make sense?

 Regards,
   Mark

-- 
Support Richard Stallman against the vicious disinformation campaign
against him and the FSF.  See  for more.

Re: Jam: which licence is this?

[Vagrant Cascadian]

On 2021-04-25, Jack Hill wrote:
> I'm working on packaging the Argyll Color Management System for Guix. To 
> build, it uses the Jam tool, which has the following license:
>
> ```
> This is Release 2.5 of Jam, a make-like program.
>
> License is hereby granted to use this software and distribute it
> freely, as long as this copyright notice is retained and modifications
> are clearly marked.
>
> ALL WARRANTIES ARE HEREBY DISCLAIMED.
> ```

Permission to use, check.
Permission to study, probably(?)
Permission to share, check.
Permission to modify,  ?

Is it even free software? There is no mention of modification which
doesn't appear to be free by my layman's reading...


Which brings up an ugly bag of worms regarding boost...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Outreachy - Guix Data Service: questions about improving the data for derivation comparisons.

[Luciana Lima Brito]

Hi

Your advices helped me think more clearly.

There was no need to create or modify structures other than what I was
already changing. I now return an alist instead of a list on the
derivation-differences-* functions on comparison.scm (for outputs,
inputs and sources). It helped to simplify the mapping on
controller.scm. The changes on html.scm were minimal, basically it is
matching on pairs, instead of single values.

Two questions:

1 - The match on the html expects 5 values for "outputs", so I had to
settle on using empty objects on the JSON, when needed, else it would
break the match on the html. Is it ok?

2 - Now on controller.scm "outputs", "inputs", "sources", and even
"arguments" have the same structure, which is an alist of the form:

  ((base . (...))
   (target . (...))
   (common . (...)))

and I'm using the same map and match-lambda code to process them,
wouldn't it be reasonable now to make it a local function?

I'm sending the patch. I'll be waiting your reviews.

-- 
Best Regards,

Luciana Lima Brito
MSc. in Computer Science
>From d605d519a684b1be57ebd09cdf697bcdba017da1 Mon Sep 17 00:00:00 2001
From: Luciana Brito 
Date: Sun, 25 Apr 2021 15:17:33 -0300
Subject: [PATCH] Change handling of queried data for derivations comparison.

comparison.scm: return query data for derivation comparison as an alist, instead of list.
html.scm: match on pairs, instead of single values.
controller.scm: simplify mapping on outputs/inputs/sources.
---
 guix-data-service/comparison.scm | 68 +++-
 guix-data-service/web/compare/controller.scm | 62 --
 guix-data-service/web/compare/html.scm   | 43 ++---
 3 files changed, 69 insertions(+), 104 deletions(-)

diff --git a/guix-data-service/comparison.scm b/guix-data-service/comparison.scm
index e5e1955..1f47c38 100644
--- a/guix-data-service/comparison.scm
+++ b/guix-data-service/comparison.scm
@@ -158,19 +158,23 @@ GROUP BY 1, 2, 3, 4, 5"))
   (let ((parsed-derivation-ids
  (map string->number
   (parse-postgresql-array-string derivation_ids
-(list output-name
-  path
-  hash-algorithm
-  hash
-  recursive
-  (append (if (memq base-derivation-id
-parsed-derivation-ids)
-  '(base)
-  '())
-  (if (memq target-derivation-id
-parsed-derivation-ids)
-  '(target)
-  '()))
+`((output-name . ,output-name)
+  (path . ,path)
+  ,@(if (string? hash-algorithm)
+`((hash-algorithm . ,hash-algorithm))
+`((hash-algorithm . (
+  ,@(if (string? hash)
+`((hash . ,hash))
+`((hash . (
+  (recursive . ,(string=? recursive "t"))
+  ,(append (if (memq base-derivation-id
+ parsed-derivation-ids)
+   '(base)
+   '())
+   (if (memq target-derivation-id
+ parsed-derivation-ids)
+   '(target)
+   '()))
(exec-query conn query)))
 
 (define (derivation-inputs-differences-data conn
@@ -202,16 +206,16 @@ INNER JOIN derivations ON derivation_outputs.derivation_id = derivations.id
   (let ((parsed-derivation-ids
  (map string->number
   (parse-postgresql-array-string derivation_ids
-  (list derivation_file_name
-derivation_output_name
-(append (if (memq base-derivation-id
-  parsed-derivation-ids)
-'(base)
-'())
-(if (memq target-derivation-id
-  parsed-derivation-ids)
-'(target)
-'()))
+`((derivation_file_name . ,derivation_file_name)
+  (derivation_output_name . ,derivation_output_name)
+  ,(append (if (memq base-derivation-id
+ parsed-derivation-ids)
+   '(base)
+   '())
+   (if (memq target-derivation-id
+ parsed-derivation-ids)
+   '(target)
+   '()))
(exec-query conn query)))
 
 (define (derivation-sources-differences-data conn
@@ -235,15 +239,15 @@ GROUP BY derivation_source_files.store_path"))
   (let ((parsed-derivation-ids
  (map string->number
   (parse-postgresql-array-string 

Re: Jam: which licence is this?

[Mark H Weaver]

Hi Jack,

Jack Hill  writes:

> I'm working on packaging the Argyll Color Management System for Guix. To 
> build, it uses the Jam tool, which has the following license:
>
> ```
> This is Release 2.5 of Jam, a make-like program.
>
> License is hereby granted to use this software and distribute it
> freely, as long as this copyright notice is retained and modifications
> are clearly marked.
>
> ALL WARRANTIES ARE HEREBY DISCLAIMED.
> ```
>
> Which license is this?

Thanks very much for your diligence here.

I looked into it, and Debian calls this the "Perforce" license.  The
"copyright" file for Debian's 'boost' package includes the following
lines:

--8<---cut here---start->8---
License: Perforce
 License is hereby granted to use this software and distribute it
 freely, as long as this copyright notice is retained and modifications
 are clearly marked.
 .
 ALL WARRANTIES ARE HEREBY DISCLAIMED.
--8<---cut here---end--->8---



Maybe this should be added to (guix licenses) as 'perforce', or perhaps
'perforce-jam'?

Thoughts?

  Mark

-- 
Support Richard Stallman against the vicious disinformation campaign
against him and the FSF.  See  for more.

Re: Jam: which licence is this?

[Leo Famulari]

On Sun, Apr 25, 2021 at 01:25:21PM -0400, Mark H Weaver wrote:
> In general, I think that the license field of a package should include
> all licenses that cover any files in its source distribution (by which I
> mean the output of "guix build --source").
> 
> My rationale is that it is the source code, and not merely the build
> outputs, where users will want to exercise the four freedoms of free
> software.  For example, when a user wishes to study, modify, or
> redistribute the software, they will want to be able to do those things
> with the entire source distribution.
> 
> Does that make sense?  What do you think?

It makes sense, but we've never done that.

For example, the autotools files such as configure.ac bear a simple
permissive license, but we do not mention that in the license field of
the 'hello' package.

Instead, we typically use the license that covers the overall program,
not the (sometimes dozens of) licenses of every single file in the
source distribution.

Can you clarify your expectations regarding which files' licenses should
be mentioned in the package definition?

Re: Jam: which licence is this?

[Mark H Weaver]

Hi Ricardo,

Ricardo Wurmus  writes:

>> I'm working on packaging the Argyll Color Management System for
>> Guix. To build, it uses the Jam tool, which has the following 
>> license:
>
> This is also used by Boost.
>
> I don’t know what the license is called, but the build tool is not 
> part of the built package, so I think it doesn’t end up in the 
> license field.q

Are you saying that you believe that software included in a package's
source distribution that's used only during the build process should be
exempt from having its license(s) listed in the 'licenses' field?

If so, I strongly disagree.  I've been a Guix developer for over 8
years, and this is the first time I've heard any suggestion that the
meaning of the 'license' field should be defined in that way.

In general, I think that the license field of a package should include
all licenses that cover any files in its source distribution (by which I
mean the output of "guix build --source").

My rationale is that it is the source code, and not merely the build
outputs, where users will want to exercise the four freedoms of free
software.  For example, when a user wishes to study, modify, or
redistribute the software, they will want to be able to do those things
with the entire source distribution.

Does that make sense?  What do you think?

Regards,
  Mark

-- 
Support Richard Stallman against the vicious disinformation campaign
against him and the FSF.  See  for more.

Re: 1 Guix-devel moderator request(s) waiting

[Tobias Geerinckx-Rice]

Hi jgart,

Your meetup reminder to guix-devel@ was held for moderation:

guix-devel-boun...@gnu.org writes:

From: jg...@dismail.de on Sat Apr 24 12:28:55 2021
Subject: Re: Guix Packaging Meetup [...]
Cause: Too many recipients to the message


It had 11.  I've approved it now.  I hope the meetup was a 
success!


I've also raised the maximum number of recipients for most lists, 
from 10 to 25.  I've never seen this rule catch a single spam but 
lifting it entirely is 2 spooky 4 me.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Guix Packaging Meetup - Saturday, April 24, 2021 from 14:00 EST (18:00 PM UTC)

[jgart]

Hi Guix!

If you're free come package with us today at 2PM EST:

https://events.nixnet.services

Hope to see you there :)

jgart

https://board.disroot.org/project/guix-packaging/timeline



April 18, 2021 1:40 PM, "jgart"  wrote:

> Hi Guix!
> 
> LibreMiami is hosting a guix packaging meetup next Saturday, April 24 at 
> 14:00 EST.
> 
> The format for the meetup will involve talking over mumble while pair 
> programming over tmate. 
> 
> Feel free to package with us, watch via the livestream, or just chat with 
> over mumble.
> 
> Here's the meeting link with info on the event and how to join: 
> 
> https://events.nixnet.services/events/27955ca1-0aee-4ec5-be20-48e6c45fd0f6
> 
> Hope to see you there!
> 
> jgart
> 
> libremiami.org
> donotshake.libremiami.org
> mumble.libremiami.org

qemu-i486 no longer exists, but qemu-binfmt thinks it does

[elaexuotee]

Hey Guix,

Just for fun, I tried putting the following in my services:

(service qemu-bitfmt-service-type
  (qemu-bitfmt-configuration (platforms %qemu-platforms)))

However, after reconfiguration, shepherd fails to start qemu-binfmt:

$ sudo herd start qemu-binfmt
herd: exception caught while executing 'start' on service 'qemu-binfmt'
fport_write: No such file or directory

That message is not particularly helpful, but

$ grep binfmt_misc /var/log/messages
Apr 25 19:35:14 localhost vmunix: [ 2052.220124] binfmt_misc: register: 
failed to install interpreter file 
/gnu/store/3l74cx3dgr61kj0q8padb9ayn0dai45b-qemu-5.2.0-static/bin/qemu-i486

Indeed, it looks like the qemu-i486 binary isn't in the qemu output at all. Any
idea what happened to it?

Re: New blog post on the Guix Build Coordinator: Building derivations, how complicated can it be?

[Mathieu Othacehe]

Hello,

> On Sat, Apr 24, 2021 at 11:10 AM Christopher Baines  wrote:
>> I did think about trying to include something about Cuirass, but I don't
>> have a clear picture of it's scope or purpose, so I'm not really the
>> right person to attempt to write authoritatively about it.
>
> OK, fair enough, Matthieu, Ludo, or anyone else can shed some light
> here ?

You can learn more about Cuirass by reading its online manual[1].
The Cuirass server at https://ci.guix.gnu.org currently:

* Evaluates new Guix derivations on several branches (master,
  core-updates, ...).

* Builds those derivations on a build farm of 29 machines, some of them
  connected using a Wireguard VPN.

* Reports the build status on the Web interface, by email at
  guix...@gnu.org, though a Web API used by "guix pull" and "guix
  weather".
  
Maintaining and improving this whole architecture has been keeping me
busy for the last year. It involved a constant monitoring of the build
farm, upgrading the database, and rewriting Cuirass almost completely,
between other things.

The situation is now much better. Cuirass offers a nice substitutes
coverage, at least for Intel architectures, it is stable, well covered
by unit tests and documented.

We have already discussed the Cuirass vs Build coordinator situation in
the past. I haven't changed by mind on that subject. The Guix Build
Coordinator is more or less the equivalent of the Cuirass remote build
mechanism[2].

Integrating the Build coordinator in the Berlin build farm would mean
hooking in to Cuirass as an alternative to the remote build mechanism. I
don't think it would be wise because:

* It wouldn't bring any new features as far as I can tell.

* It would mean maintaining a new SQLite database.

  When Cuirass was using an SQLite database, maintaining it was a
  nightmare. I had to dive into SQLite sources, apply a wide variety of
  hacks[3] to make it scale.

  Even if the Build coordinator is updated to use a PostgreSQL database,
  that would mean having two databases, sitting next to each other,
  with a very similar content, which is a nonsense in my opinion.

* The Build coordinator has no documentation, no unit tests and a large
  code base that would drastically increase the system administrator
  burden.

It really makes me sad that we have two pieces of software that are
stepping on each other toes. The Build coordinator has a nice concept
and represents a huge amount of work. However, integrating it to Berlin
is not an option for me.

I think that the next challenges on the CI front are:

* Increase the number of ARM machines in the build farm.

* Work on substitutes mirrors.

* Find a way to make Cuirass and the Data Service work together.

and we should face those issues together, rather than having competing
software sharing the few build machines we own.

Thanks,

Mathieu

[1]: https://guix.gnu.org/cuirass/manual/html_node/index.html
[2]: 
https://guix.gnu.org/cuirass/manual/html_node/Build-modes.html#With-the-remote-build-mechanism_002e
[3]: 
https://wiki.mozilla.org/Performance/Avoid_SQLite_In_Your_Next_Firefox_Feature

Re: neovim and luajit?

[HiPhish]

I just want to add my 2 cents to the discussion. Officially Neovim supports 
only 
Lua 5.1 as its extension language according to the manual (`:h lua-intro`):

> The Lua 5.1 language is builtin and always available.

Using LuaJIT allows the use of some extensions to Lua 5.1, but plugins relying 
on this functionality are strictly speaking non-portable because not all users 
might have them. I don't know if it is possible with Guix, but the ideal 
solution would be to use LuaJIT where available and fall back on Lua 5.1 
otherwise.

On Sunday, 25 April 2021 09:15:57 CEST Efraim Flashner wrote:
> On Thu, Apr 22, 2021 at 01:33:58AM -0400, Jack Hill wrote:
> > On Fri, 31 Jul 2020, Jack Hill wrote:
> > > Hi Guix,
> > > 
> > > I'm wondering why we use Lua 5.1 instead of LuaJIT for neovim? It seems
> > > that upstream prefers LuaJIT given the non-default configure flag we
> > > use[0] and their FAQ[1].
> > > 
> > > I don't have an opinion either way. I'm learning about neovim today, and
> > > am curious how we arrived at our configuration.
> > > 
> > > [0]
> > > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/vim.scm?id
> > > =96a655a77bb087397a9436391e472c36ff0a2ec2#n647 [1]
> > > https://github.com/neovim/neovim/wiki/FAQ#why-embed-lua-instead-of-x
> > > 
> > > Best,
> > > Jack
> > 
> > I've returned to the above question. With the attached patch, neovim
> > builds
> > on x86_64 and performs basic editing functions. I did not test it with any
> > extra packages or plugins.
> > 
> > In addition to what I said before, I'm also interested in LuaJIT because
> > it
> > supports the 5.1 language and still seems to be developed upstream. Lua is
> > no longer developing the 5.1 series and the newer series have an
> > incompatible language.
> > 
> > A downside to using LuaJIT is that it doesn't support all the
> > architectures
> > that Guix supports [2]. In particular, it looks like aarch64 and ppc64el
> > are missing.
> > 
> > [2] https://luajit.org/install.html
> > 
> > Best,
> > Jack
> > 
> > P.S. Maybe its time to work on the Lua language of Guile 
> 
> Our copy of luajit supports aarch64 so I don't think that's a problem.
> (Last I checked) Debian has a patch to replace powerpc support with
> 64-bit ppc support. I'd go ahead with the change if that's the direction
> that neovim is going and let the powerpc64le people decide between using
> lua5.1 or just removing lua support on a per-architecture basis for
> ppc64le.

Re: Jam: which licence is this?

[Ricardo Wurmus]

Hi Jack,


I'm working on packaging the Argyll Color Management System for
Guix. To build, it uses the Jam tool, which has the following 
license:


This is also used by Boost.

I don’t know what the license is called, but the build tool is not 
part of the built package, so I think it doesn’t end up in the 
license field.q


--
Ricardo

Re: neovim and luajit?

[Efraim Flashner]

On Thu, Apr 22, 2021 at 01:33:58AM -0400, Jack Hill wrote:
> On Fri, 31 Jul 2020, Jack Hill wrote:
> 
> > Hi Guix,
> > 
> > I'm wondering why we use Lua 5.1 instead of LuaJIT for neovim? It seems
> > that upstream prefers LuaJIT given the non-default configure flag we
> > use[0] and their FAQ[1].
> > 
> > I don't have an opinion either way. I'm learning about neovim today, and
> > am curious how we arrived at our configuration.
> > 
> > [0] 
> > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/vim.scm?id=96a655a77bb087397a9436391e472c36ff0a2ec2#n647
> > [1] https://github.com/neovim/neovim/wiki/FAQ#why-embed-lua-instead-of-x
> > 
> > Best,
> > Jack
> 
> I've returned to the above question. With the attached patch, neovim builds
> on x86_64 and performs basic editing functions. I did not test it with any
> extra packages or plugins.
> 
> In addition to what I said before, I'm also interested in LuaJIT because it
> supports the 5.1 language and still seems to be developed upstream. Lua is
> no longer developing the 5.1 series and the newer series have an
> incompatible language.
> 
> A downside to using LuaJIT is that it doesn't support all the architectures
> that Guix supports [2]. In particular, it looks like aarch64 and ppc64el are
> missing.
> 
> [2] https://luajit.org/install.html
> 
> Best,
> Jack
> 
> P.S. Maybe its time to work on the Lua language of Guile 

Our copy of luajit supports aarch64 so I don't think that's a problem.
(Last I checked) Debian has a patch to replace powerpc support with
64-bit ppc support. I'd go ahead with the change if that's the direction
that neovim is going and let the powerpc64le people decide between using
lua5.1 or just removing lua support on a per-architecture basis for
ppc64le.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Jam: which licence is this?

[Jack Hill]

Hi Guix,

I'm working on packaging the Argyll Color Management System for Guix. To 
build, it uses the Jam tool, which has the following license:


```
This is Release 2.5 of Jam, a make-like program.

License is hereby granted to use this software and distribute it
freely, as long as this copyright notice is retained and modifications
are clearly marked.

ALL WARRANTIES ARE HEREBY DISCLAIMED.
```

Which license is this?

Best,
Jack