[bug#47104] [PATCH 1/2] gnu: Add grumble.

[bug#47104] [PATCH 1/2] gnu: Add grumble.

[jgart via Guix-patches via]

[-- Attachment #1: Type: text/plain, Size: 471 bytes --]

Hi Guix!

Here is grumble, an alternative mumble server implemented in golang.

go-github-com-gorilla-websocket was the only dependency we needed to package for it.

Now, to create a grumble-service-type :)

This was packaged by myself, donotshake, and Raghav Gururajan while communicating on a grumble instance and pair programming over tmate. All the co-authors are listed in the commit message.

Thank you,

jgart

libremiami.org
mumble.libremiami.org

[-- Attachment #2: 0001-gnu-Add-go-github-com-gorilla-websocket.patch --]
[-- Type: application/octet-stream, Size: 2733 bytes --]

From f9c36cd8be5eac9802c6a03d362e955ab8ab7511 Mon Sep 17 00:00:00 2001
From: LibreMiami <packaging-guix@libremiami.org>
Date: Fri, 12 Mar 2021 10:54:51 -0500
Subject: [PATCH 1/2] gnu: Add go-github-com-gorilla-websocket.

* gnu/packages/golang.scm (go-github-com-gorilla-websocket):
New variable.

Co-authored-by: Raghav Gururajan <rg@raghavgururajan.name>
Co-authored-by: donotshake <donotshake:matrix.org>
Co-authored-by: jgart <jgart@dismail.de>
---
 gnu/packages/golang.scm | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/golang.scm b/gnu/packages/golang.scm
index 849227d693..b8a4027420 100644
--- a/gnu/packages/golang.scm
+++ b/gnu/packages/golang.scm
@@ -24,6 +24,7 @@
 ;;; Copyright © 2020 raingloom <raingloom@riseup.net>
 ;;; Copyright © 2020 Martin Becze <mjbecze@riseup.net>
 ;;; Copyright © 2021 Ricardo Wurmus <rekado@elephly.net>
+;;; Copyright © 2021 LibreMiami <packaging-guix@libremiami.org>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -4809,7 +4810,7 @@ test results.")
 (define-public go-github-com-golang-protobuf-proto
   (package
     (name "go-github-com-golang-protobuf-proto")
-    (version "1.3.1")
+    (version "1.3.5")
     (source (origin
               (method git-fetch)
               (uri (git-reference
@@ -4818,7 +4819,7 @@ test results.")
               (file-name (git-file-name name version))
               (sha256
                (base32
-                "15am4s4646qy6iv0g3kkqq52rzykqjhm4bf08dk0fy2r58knpsyl"))))
+                "1gkd1942vk9n8kfzdwy1iil6wgvlwjq7a3y5jc49ck4lz9rhmgkq"))))
     (build-system go-build-system)
     (arguments
      '(#:import-path "github.com/golang/protobuf/proto"
@@ -6773,3 +6774,23 @@ compressed streams in Go.")
       (description "Package ed25519 implements the Ed25519 signature
 algorithm.")
       (license license:bsd-3))))
+
+(define-public go-github-com-gorilla-websocket
+  (package
+    (name "go-github-com-gorilla-websocket")
+    (version "1.4.2")
+    (home-page "https://github.com/gorilla/websocket")
+    (source (origin
+              (method git-fetch)
+              (uri (git-reference
+                    (url home-page)
+                    (commit (string-append "v" version))))
+              (file-name (git-file-name name version))
+              (sha256
+               (base32 "0mkm9w6kjkrlzab5wh8p4qxkc0icqawjbvr01d2nk6ykylrln40s"))))
+    (build-system go-build-system)
+    (arguments
+     '(#:import-path "github.com/gorilla/websocket"))
+    (synopsis "Well-tested and widely used WebSocket implementation for Go")
+    (description "Gorilla WebSocket is a Go implementation of the WebSocket protocol.")
+    (license license:bsd-2)))
-- 
2.30.2


[-- Attachment #3: 0002-gnu-Add-grumble.patch --]
[-- Type: application/octet-stream, Size: 3112 bytes --]

From 3430f134746a4c8aa5c0f1e8ba4e706a46f95770 Mon Sep 17 00:00:00 2001
From: LibreMiami <packaging-guix@libremiami.org>
Date: Fri, 12 Mar 2021 11:00:00 -0500
Subject: [PATCH 2/2] gnu: Add grumble.

* gnu/packages/telephony.scm (grumble):
New variable.

Co-authored-by: Raghav Gururajan <rg@raghavgururajan.name>
Co-authored-by: donotshake <donotshake:matrix.org>
Co-authored-by: jgart <jgart@dismail.de>
---
 gnu/packages/telephony.scm | 39 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/gnu/packages/telephony.scm b/gnu/packages/telephony.scm
index 5c8d247e68..f6f2312d65 100644
--- a/gnu/packages/telephony.scm
+++ b/gnu/packages/telephony.scm
@@ -59,6 +59,7 @@
   #:use-module (gnu packages glib)
   #:use-module (gnu packages gnome)
   #:use-module (gnu packages gnupg)
+  #:use-module (gnu packages golang)
   #:use-module (gnu packages gtk)
   #:use-module (gnu packages image)
   #:use-module (gnu packages libcanberra)
@@ -92,6 +93,7 @@
   #:use-module (guix git-download)
   #:use-module (guix build-system cmake)
   #:use-module (guix build-system gnu)
+  #:use-module (guix build-system go)
   #:use-module (guix build-system qt))
 
 (define-public libilbc
@@ -915,3 +917,40 @@ Initiation Protocol (SIP) and a multimedia framework.")
 telephony functionality into custom Telegram clients.")
     (home-page "https://github.com/zevlg/libtgvoip")
     (license license:unlicense)))
+
+(define-public grumble
+  (let ((commit "6f8c2bf2f51fddc1cb09e3385bc4e9db5dc43ba9")
+        (revision "335"))
+    (package
+      (name "grumble")
+      (version (git-version "0.0.0" revision commit))
+      (source (origin
+                (method git-fetch)
+                (uri (git-reference
+                      (url "https://github.com/mumble-voip/grumble")
+                      (commit commit)))
+                (file-name (git-file-name name version))
+                (sha256
+                 (base32
+                  "0yvh1k1ag56b5myg479hs6c296h9c19l43qbjmf0qwa6n4j3rvss"))))
+      (build-system go-build-system)
+      (arguments
+       '(#:unpack-path "github.com/mumble-voip/grumble"
+         #:import-path "github.com/mumble-voip/grumble/cmd/grumble"
+         #:phases
+         (modify-phases %standard-phases
+           (add-after 'unpack 'patch
+             (lambda* (#:key unpack-path #:allow-other-keys)
+               (substitute* (find-files "." "\\.go$")
+                 (("mumble.info/grumble/pkg")
+                  (string-append unpack-path "/pkg")))
+               #t)))))
+      (inputs
+       `(("go-github-com-golang-protobuf-proto" ,go-github-com-golang-protobuf-proto)
+         ("go-github-com-gorilla-websocket" ,go-github-com-gorilla-websocket)
+         ("go-golang-org-x-crypto" ,go-golang-org-x-crypto)))
+      (synopsis "Alternative Mumble server")
+      (description "Grumble is an implementation of a server for the Mumble
+voice chat system.  It is an alternative to Murmur, the typical Mumble server.")
+      (home-page "https://github.com/mumble-voip/grumble")
+      (license license:bsd-3))))
-- 
2.30.2

[bug#47104] [PATCH 1/2] gnu: Add grumble.

[Leo Prikler]

Hi jgart,

Am Freitag, den 12.03.2021, 16:25 +0000 schrieb jgart:
> Now, to create a grumble-service-type :)
I know you mean this somewhat jokingly, but is there anything (apart
maybe from the name of the binary), that would keep you from reusing
murmur-service-type?

> @@ -4809,7 +4810,7 @@ test results.")
>  (define-public go-github-com-golang-protobuf-proto
>    (package
>      (name "go-github-com-golang-protobuf-proto")
> -    (version "1.3.1")
> +    (version "1.3.5")
>      (source (origin
>                (method git-fetch)
>                (uri (git-reference
> @@ -4818,7 +4819,7 @@ test results.")
>                (file-name (git-file-name name version))
>                (sha256
>                 (base32
> -                "15am4s4646qy6iv0g3kkqq52rzykqjhm4bf08dk0fy2r58knpsy
> l"))))
> +                "1gkd1942vk9n8kfzdwy1iil6wgvlwjq7a3y5jc49ck4lz9rhmgk
> q"))))
>      (build-system go-build-system)
>      (arguments
>       '(#:import-path "github.com/golang/protobuf/proto"
Please refrain from silently bumping other packages 😉

> +      (version (git-version "0.0.0" revision commit))
Three 0s is a bit much for a package, that has declared 1.0~devel since
its inception.  Are there even plans to release this ever?

Apart from the above, there are some other question, that I'd like to
ask before greenlighting this patch.
1. Is this package in its current state usable?
2. Is it still maintained upstream?  It is a little stretch to say
Grumble is undergoing active development after a year of no activity.
3. https://github.com/mumble-voip/grumble#project-status lists quite a
few features that are lacking, but does it maybe contain features, that
would make it worth packaging?

If the answer is "no" to any of the above, I'm not too sure whether it
would be wise to have this in Guix upstream.  If LibreMiami wanted to
host grumble instances on Guix regardless, perhaps a channel might be a
better fit?

> This was packaged by myself, donotshake, and Raghav Gururajan while
> communicating on a grumble instance[...].
I'm not sure whether our broadcasting regulations would require you to
label this patch as product placement, but thanks for the info, I
guess.

Regards,
Leo

[bug#47104] grumble status update

[jgart via Guix-patches via]

Hi Leo,

> I know you mean this somewhat jokingly, but is there anything (apart
> maybe from the name of the binary), that would keep you from reusing
> murmur-service-type?

See here: 

https://github.com/mumble-voip/grumble/issues/21
https://github.com/mumble-voip/grumble/pull/26

There are more sources related to the grumble config that's currently implemented that I can't locate at the moment. 

I remember reading that they didn't necessarily want to maintain feature parity with the grumble config format.

> 1. Is this package in its current state usable?

I would say yes. We packaged grumble while talking over grumble. It feels pretty solid. 

Grumble also has an active fork as a library and being used by wahay: https://wahay.org/

It is currently 16 commits ahead of upstream:

https://github.com/digitalautonomy/grumble

> 2. Is it still maintained upstream?  It is a little stretch to say
> Grumble is undergoing active development after a year of no activity. 

It sounds like the project maintainers of the upstream grumble project are very slow to review pull requests. It sounds like they are too busy with other projects/work.

See the complaint here by one of the contributors that chimed in when I opened an issue:

https://github.com/mumble-voip/grumble/issues/76

> 3. https://github.com/mumble-voip/grumble#project-statuslists quite a
> few features that are lacking, but does it maybe contain features, that
> would make it worth packaging?

See https://github.com/mumble-voip/grumble/issues/76

"... Grumble has the distinguishing feature of native support for Websockets (because I was a lot worse at C++ back then and so I contributed a patch here instead), and Murmur will probably not have that for the foreseeable future. You could of course just configure a proxy in front of Murmur if you need this. A lot of the plans for work we were making a few years ago pointed towards Grumble being more focused on ease-of-use and these small workloads I talked about above. It makes sense: the Murmur static binary has issues and so a Grumble static (just how Go works) binary that you can download and run, trivially configure and easily negotiate certs over LE (unfortunately never happened due to LE issues, but it would be viable now), accessible over the Web could fulfil a sort of "batteries-included" user-friendly niche."

> If the answer is "no" to any of the above, I'm not too sure whether it
> would be wise to have this in Guix upstream.  If LibreMiami wanted to
> host grumble instances on Guix regardless, perhaps a channel might be a
> better fit?

We can put this in a LibreMiami channel with a service for it if you insist it not be included in upstream guix. 

If upstream grumble picks up development then I can send a patch again for review.

That said, can you take the patch for go-github-com-gorilla-websocket?

We will need go-github-com-gorilla-websocket for many other packages that we're working on. One of them being the hugo static site generator that we're working on with Ryan Prior.

Relatedly, we're planning on packaging wahay (https://wahay.org/). 

wahay depends on the fork of grumble that I linked above. 

Should we package only the fork of grumble in that case and not upstream grumble?

all the best,

jgart

[bug#47104] grumble status update

[Leo Prikler]

Hi jgart,

Am Sonntag, den 18.04.2021, 17:25 +0000 schrieb jgart:
> Hi Leo,
> 
> > I know you mean this somewhat jokingly, but is there anything
> > (apart
> > maybe from the name of the binary), that would keep you from
> > reusing
> > murmur-service-type?
> 
> See here: 
> 
> https://github.com/mumble-voip/grumble/issues/21
> https://github.com/mumble-voip/grumble/pull/26
> 
> There are more sources related to the grumble config that's currently
> implemented that I can't locate at the moment. 
> 
> I remember reading that they didn't necessarily want to maintain
> feature parity with the grumble config format.
That's… disappointing.

> > 1. Is this package in its current state usable?
> 
> I would say yes. We packaged grumble while talking over grumble. It
> feels pretty solid. 
> 
> Grumble also has an active fork as a library and being used by wahay:
> https://wahay.org/
> 
> It is currently 16 commits ahead of upstream:
> 
> https://github.com/digitalautonomy/grumble
This doesn't really look active to me either.  It appears as though
they diverged at some point and simultaneously came to a halt.  Now
wahay is still active, but that's a different beast.

> > 2. Is it still maintained upstream?  It is a little stretch to say
> > Grumble is undergoing active development after a year of no
> > activity. 
> 
> It sounds like the project maintainers of the upstream grumble
> project are very slow to review pull requests. It sounds like they
> are too busy with other projects/work.
> 
> See the complaint here by one of the contributors that chimed in when
> I opened an issue:
> 
> https://github.com/mumble-voip/grumble/issues/76
I take that as a "Maybe, but actually no".

> > 3. https://github.com/mumble-voip/grumble#project-statuslists quite
> > a
> > few features that are lacking, but does it maybe contain features,
> > that
> > would make it worth packaging?
> 
> See https://github.com/mumble-voip/grumble/issues/76
> 
> "... Grumble has the distinguishing feature of native support for
> Websockets (because I was a lot worse at C++ back then and so I
> contributed a patch here instead), and Murmur will probably not have
> that for the foreseeable future. You could of course just configure a
> proxy in front of Murmur if you need this. A lot of the plans for
> work we were making a few years ago pointed towards Grumble being
> more focused on ease-of-use and these small workloads I talked about
> above. It makes sense: the Murmur static binary has issues and so a
> Grumble static (just how Go works) binary that you can download and
> run, trivially configure and easily negotiate certs over LE
> (unfortunately never happened due to LE issues, but it would be
> viable now), accessible over the Web could fulfil a sort of
> "batteries-included" user-friendly niche."
W.r.t. ease-of-use I don't think it should be too difficult to get
murmur + certbot working in Guix.  All I can recall from the Debian
(yeah, I know) server, that I currently run murmur on, is that you need
to get your hook for restarting murmur right.

> > If the answer is "no" to any of the above, I'm not too sure whether
> > it
> > would be wise to have this in Guix upstream.  If LibreMiami wanted
> > to
> > host grumble instances on Guix regardless, perhaps a channel might
> > be a
> > better fit?
> 
> We can put this in a LibreMiami channel with a service for it if you
> insist it not be included in upstream guix. 
It is not so much me insisting rather than me thinking, that channels
fit such "niche" uses better.  As far as I can tell, Guix tries to make
system services as secure as possible and having a service with glaring
security flaws is not really a good fit in that scenario.  See also the
recent removal of mongodb.

> If upstream grumble picks up development then I can send a patch
> again for review.
Please do so.

> That said, can you take the patch for go-github-com-gorilla-
> websocket?
> 
> We will need go-github-com-gorilla-websocket for many other packages
> that we're working on. One of them being the hugo static site
> generator that we're working on with Ryan Prior.
While the package description itself LGTM, the patch inadvertently
version bumps some Go protobuf package.  If it's okay with you and
Ryan, I think the better solution would be to send a clean patch along
with hugo or perhaps separately.

> Relatedly, we're planning on packaging wahay (https://wahay.org/). 
> 
> wahay depends on the fork of grumble that I linked above. 
> 
> Should we package only the fork of grumble in that case and not
> upstream grumble?
Again, since wahay has no public release and LibreMiami might want to
tail upstream, I think that this would be a better fit outside of Guix.
As for the differences in their versions of grumble, I honestly don't
know what to do.  Guix usually tries not to vendor packages and this
might mean using upstream grumble for wahay, but the grumble fork might
also implement features, that are necessary for wahay.

This is just my personal opinion, but right now Guix seems to have
about 70 "no release" comments, some of which are actually "no release
since".  I don't think there's a reason to bump this number unless the
developer has a good reason not to assign version numbers (other than
"it's not ready yet", which is a perfect reason not to assign version
numbers, but also a perfect reason to refrain from packaging it), which
does not seem to hold here.

Regards,
Leo

[bug#47104] grumble status update

[jgart via Guix-patches via]

> It is not so much me insisting rather than me thinking, that channels
> fit such "niche" uses better. As far as I can tell, Guix tries to make
> system services as secure as possible and having a service with glaring
> security flaws is not really a good fit in that scenario. See also the
> recent removal of mongodb.

I also agree that this will be a good use case for a guix channel. Thanks for the advice on that.

We'll move grumble and wahay (tbd) to our channel for community testing and experimentation. 

> While the package description itself LGTM, the patch inadvertently
> version bumps some Go protobuf package. If it's okay with you and
> Ryan, I think the better solution would be to send a clean patch along
> with hugo or perhaps separately.

I'll resend a patch for go-github-com-gorilla-websocket soon. 

Hugo might be a while. It's a beast of a package:

https://github.com/ryanprior/guix-packages/blob/master/testing/hugo.scm
https://github.com/ryanprior/guix-packages/blob/master/testing/new-hugo-deps.org

It definitely doesn't resemble the one in nixpkgs :)

https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/applications/misc/hugo/default.nix#L36

Thank you for taking the time to review our patches.

all the best,

jgart

April 18, 2021 2:32 PM, "Leo Prikler" <leo.prikler@student.tugraz.at> wrote:

> Hi jgart,
> 
> Am Sonntag, den 18.04.2021, 17:25 +0000 schrieb jgart:
> 
>> Hi Leo,
>> 
>> I know you mean this somewhat jokingly, but is there anything
>> (apart
>> maybe from the name of the binary), that would keep you from
>> reusing
>> murmur-service-type?
>> 
>> See here:
>> 
>> https://github.com/mumble-voip/grumble/issues/21
>> https://github.com/mumble-voip/grumble/pull/26
>> 
>> There are more sources related to the grumble config that's currently
>> implemented that I can't locate at the moment.
>> 
>> I remember reading that they didn't necessarily want to maintain
>> feature parity with the grumble config format.
> 
> That's… disappointing.
> 
>> 1. Is this package in its current state usable?
>> 
>> I would say yes. We packaged grumble while talking over grumble. It
>> feels pretty solid.
>> 
>> Grumble also has an active fork as a library and being used by wahay:
>> https://wahay.org
>> 
>> It is currently 16 commits ahead of upstream:
>> 
>> https://github.com/digitalautonomy/grumble
> 
> This doesn't really look active to me either. It appears as though
> they diverged at some point and simultaneously came to a halt. Now
> wahay is still active, but that's a different beast.
> 
>> 2. Is it still maintained upstream? It is a little stretch to say
>> Grumble is undergoing active development after a year of no
>> activity.
>> 
>> It sounds like the project maintainers of the upstream grumble
>> project are very slow to review pull requests. It sounds like they
>> are too busy with other projects/work.
>> 
>> See the complaint here by one of the contributors that chimed in when
>> I opened an issue:
>> 
>> https://github.com/mumble-voip/grumble/issues/76
> 
> I take that as a "Maybe, but actually no".
> 
>> 3. https://github.com/mumble-voip/grumble#project-statuslists quite
>> a
>> few features that are lacking, but does it maybe contain features,
>> that
>> would make it worth packaging?
>> 
>> See https://github.com/mumble-voip/grumble/issues/76
>> 
>> "... Grumble has the distinguishing feature of native support for
>> Websockets (because I was a lot worse at C++ back then and so I
>> contributed a patch here instead), and Murmur will probably not have
>> that for the foreseeable future. You could of course just configure a
>> proxy in front of Murmur if you need this. A lot of the plans for
>> work we were making a few years ago pointed towards Grumble being
>> more focused on ease-of-use and these small workloads I talked about
>> above. It makes sense: the Murmur static binary has issues and so a
>> Grumble static (just how Go works) binary that you can download and
>> run, trivially configure and easily negotiate certs over LE
>> (unfortunately never happened due to LE issues, but it would be
>> viable now), accessible over the Web could fulfil a sort of
>> "batteries-included" user-friendly niche."
> 
> W.r.t. ease-of-use I don't think it should be too difficult to get
> murmur + certbot working in Guix. All I can recall from the Debian
> (yeah, I know) server, that I currently run murmur on, is that you need
> to get your hook for restarting murmur right.
> 
>> If the answer is "no" to any of the above, I'm not too sure whether
>> it
>> would be wise to have this in Guix upstream. If LibreMiami wanted
>> to
>> host grumble instances on Guix regardless, perhaps a channel might
>> be a
>> better fit?
>> 
>> We can put this in a LibreMiami channel with a service for it if you
>> insist it not be included in upstream guix.
> 
> It is not so much me insisting rather than me thinking, that channels
> fit such "niche" uses better. As far as I can tell, Guix tries to make
> system services as secure as possible and having a service with glaring
> security flaws is not really a good fit in that scenario. See also the
> recent removal of mongodb.
> 
>> If upstream grumble picks up development then I can send a patch
>> again for review.
> 
> Please do so.
> 
>> That said, can you take the patch for go-github-com-gorilla-
>> websocket?
>> 
>> We will need go-github-com-gorilla-websocket for many other packages
>> that we're working on. One of them being the hugo static site
>> generator that we're working on with Ryan Prior.
> 
> While the package description itself LGTM, the patch inadvertently
> version bumps some Go protobuf package. If it's okay with you and
> Ryan, I think the better solution would be to send a clean patch along
> with hugo or perhaps separately.
> 
>> Relatedly, we're planning on packaging wahay (https://wahay.org).
>> 
>> wahay depends on the fork of grumble that I linked above.
>> 
>> Should we package only the fork of grumble in that case and not
>> upstream grumble?
> 
> Again, since wahay has no public release and LibreMiami might want to
> tail upstream, I think that this would be a better fit outside of Guix.
> As for the differences in their versions of grumble, I honestly don't
> know what to do. Guix usually tries not to vendor packages and this
> might mean using upstream grumble for wahay, but the grumble fork might
> also implement features, that are necessary for wahay.
> 
> This is just my personal opinion, but right now Guix seems to have
> about 70 "no release" comments, some of which are actually "no release
> since". I don't think there's a reason to bump this number unless the
> developer has a good reason not to assign version numbers (other than
> "it's not ready yet", which is a perfect reason not to assign version
> numbers, but also a perfect reason to refrain from packaging it), which
> does not seem to hold here.
> 
> Regards,
> Leo

bug#47104: [PATCH 1/2] gnu: Add grumble.

[Maxim Cournoyer]

Hello,

"jgart" <jgart@dismail.de> writes:

>> It is not so much me insisting rather than me thinking, that channels
>> fit such "niche" uses better. As far as I can tell, Guix tries to make
>> system services as secure as possible and having a service with glaring
>> security flaws is not really a good fit in that scenario. See also the
>> recent removal of mongodb.
>
> I also agree that this will be a good use case for a guix channel. Thanks for the advice on that.
>
> We'll move grumble and wahay (tbd) to our channel for community testing and experimentation. 

OK.

Closing this tracker then.

Thanks,

Maxim