GNU bug report logs - #51352
Matterbridge contained a lot of vendored code

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: guix; Reported by: Denis 'GNUtoo' Carikli <GNUtoo@HIDDEN>; dated Sat, 23 Oct 2021 14:58:02 UTC; Maintainer for guix is bug-guix@HIDDEN.

Message received at submit <at>

Received: (at submit) by; 23 Oct 2021 14:57:22 +0000
From debbugs-submit-bounces <at> Sat Oct 23 10:57:22 2021
Received: from localhost ([]:36890
	by with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at>>)
	id 1meISY-0004Pv-D0
	for submit <at>; Sat, 23 Oct 2021 10:57:22 -0400
Received: from ([]:45418)
 by with esmtp (Exim 4.84_2)
 (envelope-from <GNUtoo@HIDDEN>) id 1meISU-0004Pl-OQ
 for submit <at>; Sat, 23 Oct 2021 10:57:21 -0400
Received: from ([2001:470:142:3::10]:47674)
 by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <GNUtoo@HIDDEN>)
 id 1meISU-0001sN-FQ
 for bug-guix@HIDDEN; Sat, 23 Oct 2021 10:57:18 -0400
Received: from ([]:38010
 by with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256)
 (Exim 4.90_1) (envelope-from <GNUtoo@HIDDEN>)
 id 1meISR-0001NM-Dr
 for bug-guix@HIDDEN; Sat, 23 Oct 2021 10:57:18 -0400
Received: from (localhost [])
 by (OpenSMTPD) with ESMTP id d076fc8d
 for <bug-guix@HIDDEN>; Sat, 23 Oct 2021 14:49:34 +0000 (UTC)
Received: from primarylaptop (localhost.localdomain [::1])
 by (OpenSMTPD) with ESMTP id 2d735684
 for <bug-guix@HIDDEN>; Sat, 23 Oct 2021 14:49:34 +0000 (UTC)
Date: Sat, 23 Oct 2021 16:57:02 +0200
From: Denis 'GNUtoo' Carikli <GNUtoo@HIDDEN>
To: bug-guix@HIDDEN
Subject: Matterbridge contained a lot of vendored code
Message-ID: <20211023165702.1e518f56@primarylaptop>
X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.30; i686-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/Czpt6ebe/uoYt26sifvXjHE";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Received-SPF: pass client-ip=;
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.4 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at>
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <>
List-Unsubscribe: <>, 
 <mailto:debbugs-submit-request <at>>
List-Archive: <>
List-Post: <mailto:debbugs-submit <at>>
List-Help: <mailto:debbugs-submit-request <at>>
List-Subscribe: <>, 
 <mailto:debbugs-submit-request <at>>
Errors-To: debbugs-submit-bounces <at>
Sender: "Debbugs-submit" <debbugs-submit-bounces <at>>
X-Spam-Score: -2.4 (--)

Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable


When I sent the patch adding matterbridge to Guix, I only notified that
I didn't know if it contained vendored code or not at the last moment
(after the patch was sent, during the discussion about it, and before
it was merged).

The issue is that I didn't know go at all and more specifically I didn't
know its the compilation system worked. So I managed to create a
package for matterbridge by looking at how it was done for other go

After learning more about how go compilation worked, I found out that
matterbridge contained a lot of vendored code.

And Guix explicitly wants to avoid bundles code. In the "16.6 Submitting
Patches" section of the manual[1], we have:
> 6. Make sure the package does not use bundled copies of software
> already available as separate packages.
And here while most dependencies are not already packaged, some are,
and I guess that I should read between the lines and conclude that all
the matterbridge dependencies should rather be packaged.

So the question is what should we do about that.=20

As I understand with the go build system, or you vendor all
dependencies, or you vendor none, and I've not yet managed to find a
way to workaround that yet in Guix (to do a progressive unvendoring).

So instead I've started working on unvendoring matterbridge[2]
completely, but if we go this route, there are more than 500

To do that I first used the following command:
    guix import go -r

I then started looking at each package definition that Guix didn't
manage to detect the license of, and I read the licenses to find if
they were free software. All the licenses I read were FSDG compliant.
Usually they had some extra text indicating the provenance of the code
or they would have multiple free software licenses.

Then I started adding packages for the dependencies that guix import go
didn't manage to find.

Theses are repositories that are being forked from the official ones
for a reason or another.

I've not finished that yet, but I still think it was a good idea to
open a bug report as I've now more understanding of the problem.

Given the huge amount of dependencies I was wondering what was the best
approach here:
- Would it makes sense to remove matterbridge from Guix, or should we
  fix it instead?
- If we fix it by packaging each dependencies, would it be ok if that
  is done step by step, like if dependencies are packaged and patches
  for them are sent, without necessarily a way to seriously test if
  the packaged dependency work until they are used by other software
  (like matterbridge)?

Also when I'll manage to update matterbridge[3] how should we deal with
such amount of packages? Would I need to send one (generated) patch for
the upgrade of each package?

I also guess that sticking as much as possible to what Guix import go
generates would help in situations like that as it would make the
maintenance faster.

[3]Right now there is a compilation issue that I didn't manage to fix,
  even with help from #guix).


Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature




Acknowledgement sent to Denis 'GNUtoo' Carikli <GNUtoo@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-guix@HIDDEN. Full text available.
Report forwarded to bug-guix@HIDDEN:
bug#51352; Package guix. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Sat, 23 Oct 2021 15:00:02 UTC

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