[bug#47104] grumble status update

[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.

> 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