[bug#55083,2/2] gnu: Add bundlewrap

  * gnu/packages/configuration-management.scm (bundlewrap): New variable

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
---
 gnu/packages/configuration-management.scm | 41 +++++++++++++++++++++--
 1 file changed, 38 insertions(+), 3 deletions(-)
  

Denis 'GNUtoo' Carikli schreef op za 23-04-2022 om 18:54 [+0200]:
> +    (license license:gpl3)))

Isn't this incompatible with librouteros' license?

Greetings,
Maxime.
  

Denis 'GNUtoo' Carikli schreef op za 23-04-2022 om 18:54 [+0200]:
> +    (synopsis "Agent-less configuration management")
> +    (description "Agent-less configuration management with Python")

What does this mean?  E.g., could I consider the text editor 'nano' to
be an ‘agent-less configuration management’ tool, because it allows me
the modify configuration files (‘managing’) and it doesn't have a
daemon (‘agent’)?

Greetings,
Maxime.
  

Denis 'GNUtoo' Carikli schreef op za 23-04-2022 om 18:54 [+0200]:
> +                  python-requests

Is python-requests used for contacting https:// URLs?  If so,
'bundlewrap' probably needs a SSL_CERT_FILE or SSL_CERT_DIR search path
(see, e.g., https://github.com/psf/requests/pull/2903).

Greeetings,
Maxime.
  

Denis 'GNUtoo' Carikli schreef op za 23-04-2022 om 18:54 [+0200]:
> +              (method url-fetch)
> +              (uri (pypi-uri "bundlewrap" version))
> +              (sha256
> +               (base32
> +               

It uses /usr/bin/less
<https://github.com/bundlewrap/bundlewrap/blob/567b5f055067b1e23ea8081b24f1bebfdc44c541/bundlewrap/utils/ui.py#L122>,
which does not exist in Guix.

It also uses git, bzr and hg:

https://github.com/bundlewrap/bundlewrap/blob/567b5f055067b1e23ea8081b24f1bebfdc44c541/bundlewrap/utils/scm.py#L10

these theoretically should be absolutised though there might be closure
size concerns.

There's also a use of 'stat':

https://github.com/bundlewrap/bundlewrap/blob/567b5f055067b1e23ea8081b24f1bebfdc44c541/bundlewrap/utils/remote.py#L8

Possibly there are more things to absolutise.

Greetings,
Maxime.
  

Denis 'GNUtoo' Carikli schreef op za 23-04-2022 om 18:54 [+0200]:
> +(define-public bundlewrap
> +  (package
> +    (name "bundlewrap")
> +    (version "4.13.6")
> +    (source (origin
> +              (method url-fetch)
> +              (uri (pypi-uri "bundlewrap" version))
> +              (sha256
> +               (base32
> +                "1fsy5kjpacrca85ckxhwq1y4lci4ysls5raam75jpkzg5ra1fxj7"))))

There appears to be some code that is broken in non-English locales:

   "stat -c '%U:%G:%a:%s:%F' -- {}".format(quote(path)),

    @property
    def is_directory(self):
        return self.stat['type'] == "directory"

    @property
    def is_file(self):
        return self.stat['type'] in ("regular file", "regular empty
file")

    @property
    def is_symlink(self):
        return self.stat['type'] == "symbolic link"

In my locale, it's 'map', not 'directory'.

Greetings,
Maxime.
  

On Sat, 23 Apr 2022 20:49:00 +0200
Maxime Devos <maximedevos@telenet.be> wrote:

> Denis 'GNUtoo' Carikli schreef op za 23-04-2022 om 18:54 [+0200]:
> > +    (license license:gpl3)))
> 
> Isn't this incompatible with librouteros' license?
Yes it is.

I've deduced both licenses from the setup.py file which as I understand
constitutes a statement of the project license (according to the GPL
FAQ you need statements to be sure of the license, not just a COPYING
file), but the issue is that they don't tell if it's GPLv2-only or
GPLv2-or-later (or GPLv3-only or GPLv3-or-later for bundlewrap's).

At first I've asked librouteros to clarify the situation[1] and
if that doesn't work I can still ask bundlewrap to add an exception for
linking against GPLv2-only code.

The later is also possible because there is some copyright assignment
process when sending patches to bundlewrap[2].

References:
-----------
[1]https://github.com/luqasz/librouteros/issues/129
[2]https://github.com/bundlewrap/bundlewrap/blob/main/CAA.md

Denis.
  

Hi Denis,

Did you have a chance to address Maxime’s comments?

Seems like little is missing to get those patches applied.

Thanks,
Ludo’.
  

On Mon, 23 May 2022 15:19:16 +0200
Ludovic Courtès <ludo@gnu.org> wrote:

> Hi Denis,
Hi,

> Did you have a chance to address Maxime’s comments?
> 
> Seems like little is missing to get those patches applied.
I could do that but we can only merge python-librouteros.

python-librouteros doesn't want to change license so only bundlewrap
can fix that licensing issue.

I've reported the bug upstream[1], and as there is a CLA, a single
entity (here a company) owns all the copyright, and they don't want to
re-license as GPLv2 or GPLv2-or-later, so as I understand the only
options left are:
- to somehow remove the python-librouteros dependency completely
- to add an exception to link it to GPLv2 code

As for the later the project expressed some doubts on if it's really
possible or not:
> Hm. Are you sure it's possible for me to "allow" BundleWrap to be
> linked against GPLv2 libs? Wouldn't that require the permission of
> the lib, rather than BundleWrap?

And so far I found the following information on the topic but nothing
really conclusive yet:
- https://www.gnu.org/licenses/gpl-faq.html#v2v3Compatibility
- https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

And here the issue mentioned in the first link is the GPLv2 section 6
which has:
> [...]
> You may not impose any further restrictions on the recipients'
> exercise of the rights granted herein.
> [...]

So here I'm not sure anymore if there is a way to somehow satisfy
the GPLv2 of the library just with an exception in bundlewrap.

I'm also very interested in understanding that issue better as I've
written software (were I still own all the copyright) that has somewhat
similar requirements (I want to release it under GPLv2 or later (to
be able to be merged upstream) with an exception for linking against
Apache libraries).

References:
-----------
[1]https://github.com/bundlewrap/bundlewrap/issues/709

Denis.
  

Denis 'GNUtoo' Carikli schreef op ma 23-05-2022 om 18:08 [+0200]:
> I could do that but we can only merge python-librouteros.
> 
> python-librouteros doesn't want to change license

Upstream clarified it's GPLv2-only, but AFAICT hasn't explicitly
expressed any opinion on whether they would mind relicensing.  I asked
for clarification [1]

[1]: <https://github.com/luqasz/librouteros/issues/129#issuecomment-1134892145>

Greetings,
Maxime.