bug#38479: Org Mode is borked

Hi Guix, Our Org Mode package (emacs-org) seems to be broken in a funny way. Here's how to reproduce this bug (on commit dac7928): 1) Install ‘emacs’ and ‘emacs-org’. 2) Start Emacs and work around https://debbugs.gnu.org/38399 by adding the directory containing org to the front of

bug#37309: [PATCH] services: openssh: Restrict to IPv4.

Le 3 décembre 2019 21:12:51 GMT+01:00, Leo Famulari a écrit : >This works around . > >* gnu/services/ssh.scm ()[address-family]: New >field. >(openssh-config-file): Use it. >* doc/guix.texi: Document it. >--- > doc/guix.texi| 10 ++ >

bug#26608: channels.scm supporting substitutes

Ludovic posted some channels.scm code in September 2018 supporting using more substitutes. Unfortunately his code no longer functions due to an upgrade of guile-json in guix. I've tried to learn enough guile to upgrade the code to the newer json structures, and posted my changes to github at

bug#38428: closed (Re: bug#38428: issues.guix.gnu.org gives 500 server error for some old issues)

Error gone for me, too, now. On Tue, Dec 3, 2019, 8:23 AM Ricardo Wurmus wrote: > > Nome Grey writes: > > > Just to note it somewhere, the 500 errors are back. > > I can’t reproduce this, but I do see that there are quite a lot of > connections that make it difficult for the server to serve

bug#38428: closed (Re: bug#38428: issues.guix.gnu.org gives 500 server error for some old issues)

Nome Grey writes: > Just to note it somewhere, the 500 errors are back. I can’t reproduce this, but I do see that there are quite a lot of connections that make it difficult for the server to serve all requests.

bug#38471: meta: I don't receive follow-ups to bug reports I submitted

I remarked on this before: https://lists.gnu.org/archive/html/guix-devel/2019-06/msg00315.html It seems that I don’t get follow-up emails to bug reports I submitted unless people explicitly put me in CC (presumably by reply to all in the original email thread). I’ve failed to answer follow-up

bug#38469: guix gc should keep around recent intermediate build

> Have you tried passing the options '--gc-keep-derivations=yes’ and > '--gc-keep-outputs=yes' to guix-daemon? I had not. I added that right now, and first tests seem to indicate that this helps. Thanks! Would it be a bad idea to make this the default? Alternatively, how about some kind of

bug#36675: [PATCH] gnu: kodi: Disable intermittently failing test.

As reported in , occasionally the TestMassEvent.General test in kodi crashes with a mutex error. * gnu/packages/patches/kodi-skip-testmasseventgeneral.patch: New file. * gnu/packages/kodi.scm (kodi)[source]: Use it. * gnu/local.mk: (dist_patch_DATA): Add

bug#26170: Bug #26170 Hunting: doc: Explanation of propagated-inputs unclear

On Tue, Dec 03, 2019 at 01:14:05PM +0100, zimoun wrote: > Dear Florian, > > You report this bug [1] a couple of years ago about unclear > explanations of the term propagated-inputs. > […] > Do you have already a patch? If no, do you plan to prepare one? > > > Thank you in advance for any

bug#38469: guix gc should keep around recent intermediate build ingredients by default

Robert Vollmert skribis: > [ This is a user/developer friendliness feature request. I’m not arguing > that `guix gc` should do anything differently on a technical level, I’m > just trying to argue that the default experience should be different. ] > > Current situation: > I use a forked

bug#26170: Bug #26170 Hunting: doc: Explanation of propagated-inputs unclear

Dear Florian, You report this bug [1] a couple of years ago about unclear explanations of the term propagated-inputs. [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26170 The explanations of propagated-inputs are here [2] and short words are there [3]. Tey have not been changed since your

bug#38469: guix gc should keep around recent intermediate build ingredients by default

[ This is a user/developer friendliness feature request. I’m not arguing that `guix gc` should do anything differently on a technical level, I’m just trying to argue that the default experience should be different. ] Current situation: I use a forked guix repository as my default channel,

bug#38435: BTRFS open_ctree failed

raingloom skribis: > On Sat, 30 Nov 2019 15:53:11 +0100 > Guillaume Le Vaillant wrote: > >> raingloom skribis: >> >> > This is what I get after a recent `guix system reconfigure` : >> > Scanning for Btrfs filesystems >> > [2.342790] BTRFS error (device sda1): open_ctree failed >> > >> >

bug#37757: Kernel panic upon shutdown

Ludovic Courtès writes: > To everyone reading this: if you’re experiencing shepherd crashes, > please raise your hand :-) \o > and consider applying this patch so we can gather debugging info! Can I do that without installing from a local checkout? Best wishes, Arne -- Unpolitisch sein heißt

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

Clément Lassieur writes: > Any update about this? Any plan to push a fix or a revert? I've been > using your new patches without any issue for a few days already. This would also be important for me. I’m currently forced to use xfce due to this bug, and that hinders me quite a bit, for

bug#38336: ‘wine64-staging’ is very expensive to build

Hi Rutger, Rutger Helling skribis: > Sorry for the late reply. I'm not really active anymore in Guix > development for various reasons. No problem! > Wine needs a whole 32-bit dependency chain to be able to run both 32-bit > and 64-bit code, since a Wine that can only run 64-bit code is >

bug#38336: ‘wine64-staging’ is very expensive to build

Hi Ludo, Sorry for the late reply. I'm not really active anymore in Guix development for various reasons. Wine needs a whole 32-bit dependency chain to be able to run both 32-bit and 64-bit code, since a Wine that can only run 64-bit code is considered useless. That is why the package is