[bug#47104] grumble status update

[jgart via Guix-patches via <guix-patches@gnu.org>]

> 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