bug#38479: Org Mode is borked

2019-12-03 Thread Diego Nicola Barbato
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 ‘load-path’:
   --8<---cut here---start->8---
   (push "/path/to/org-9.2.6" load-path)
   --8<---cut here---end--->8---
3) Open a new org file:
   --8<---cut here---start->8---
   C-x C-f foo.org RET
   --8<---cut here---end--->8---
4) Enter the following text into the buffer:
   --8<---cut here---start->8---
   #+STARTUP: indent
   --8<---cut here---end--->8---
5) Verify you're running Org Mode version 9.2.6 by running:
   --8<---cut here---start->8---
   M-x org-version RET
   --8<---cut here---end--->8---
6) Here comes the fun part: Hit C-c C-c.  This will produce the
   following error message:
   --8<---cut here---start->8---
   Symbol’s function definition is void: org-outline-overlay-data
   --8<---cut here---end--->8---
7) Now reload Org from source (instead of the .elc files):
   --8<---cut here---start->8---
   C-u C-c C-x !
   --8<---cut here---end--->8---
6) Repeat step 6.  This time it succeeds!
   --8<---cut here---start->8---
   Local setup has been refreshed
   --8<---cut here---end--->8---

The function ‘org-outline-overlay-data’ isn't defined anywhere in the
org-9.2.6 source, but it is defined in the org bundled with Emacs.
Because of this I suspect that the new emacs-build-system generates a
weird chimera containing parts of both org-9.2.6 and org-9.1.9.

To my untrained eye this looks like it’s probably a consequence of the
aforementioned bug #38399.  So I'd expect this issue to disappear as
soon as that one is fixed.

Regards,

Diego





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

2019-12-03 Thread Julien Lepiller
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 ++
> gnu/services/ssh.scm | 16 +++-
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
>diff --git a/doc/guix.texi b/doc/guix.texi
>index 39eb25385c..cf0e141baf 100644
>--- a/doc/guix.texi
>+++ b/doc/guix.texi
>@@ -13913,6 +13913,16 @@ This is a symbol specifying the logging level:
>@code{quiet}, @code{fatal},
>@code{error}, @code{info}, @code{verbose}, @code{debug}, etc.  See the
>man
> page for @file{sshd_config} for the full list of level names.
> 
>+@item @code{address-family} (default: @code{'inet})
>+This is a symbol specifying which type of internet addresses should be
>+handled by @command{sshd}.  The options are @code{inet} (IPv4),
>+@code{inet6} (IPv6), or @code{any}, which selects both @code{inet} and
>+@code{inet6}.  The upstream default in @code{any}.  However, we
default *is*
>+currently default to @code{inet} due to a nondeterministic
>+@command{sshd} startup failure when using IPv6 on Guix.  See
>+@uref{https://issues.guix.info/issue/30993, the bug report} for more
>+information on this temporary limitation.
>+
> @item @code{extra-content} (default: @code{""})
>This field can be used to append arbitrary text to the configuration
>file.  It
>is especially useful for elaborate configurations that cannot be
>expressed
>diff --git a/gnu/services/ssh.scm b/gnu/services/ssh.scm
>index d2dbb8f80d..7e25810eff 100644
>--- a/gnu/services/ssh.scm
>+++ b/gnu/services/ssh.scm
>@@ -4,6 +4,7 @@
> ;;; Copyright © 2016 Julien Lepiller 
> ;;; Copyright © 2017 Clément Lassieur 
> ;;; Copyright © 2019 Ricardo Wurmus 
>+;;; Copyright © 2019 Leo Famulari 
> ;;;
> ;;; This file is part of GNU Guix.
> ;;;
>@@ -340,7 +341,16 @@ The other options should be self-descriptive."
>;; proposed in .  Keep it
>internal/undocumented
>   ;; for now.
>   (%auto-start?  openssh-auto-start?
>- (default #t)))
>+ (default #t))
>+
>+  ;; Symbol
>+  ;; XXX: This shouldn't be required, but due to limitations with IPv6
>+  ;; on Guix, sshd often fails to start when it attempts to bind to
>both
>+  ;; 0.0.0.0 and ::, because the IPv6 interface is not ready in time.
>+  ;; Accepted options are inet (IPv4), inet6 (IPv6), or any (both).
>+  ;; 
>+  (address-familyopenssh-configuration-address-family
>+ (default 'inet)))
> 
> (define %openssh-accounts
>   (list (user-group (name "sshd") (system? #t))
>@@ -468,6 +478,10 @@ of user-name/file-like tuples."
>   (symbol->string
>(openssh-configuration-log-level config
> 
>+   (format port "AddressFamily ~a\n"
>+   #$(symbol->string
>+  (openssh-configuration-address-family config)))
>+
>;; Add '/etc/authorized_keys.d/%u', which we populate.
>(format port "AuthorizedKeysFile \
>.ssh/authorized_keys .ssh/authorized_keys2
>/etc/ssh/authorized_keys.d/%u\n")






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

2019-12-03 Thread Leo Famulari
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 ++
 gnu/services/ssh.scm | 16 +++-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 39eb25385c..cf0e141baf 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -13913,6 +13913,16 @@ This is a symbol specifying the logging level: 
@code{quiet}, @code{fatal},
 @code{error}, @code{info}, @code{verbose}, @code{debug}, etc.  See the man
 page for @file{sshd_config} for the full list of level names.
 
+@item @code{address-family} (default: @code{'inet})
+This is a symbol specifying which type of internet addresses should be
+handled by @command{sshd}.  The options are @code{inet} (IPv4),
+@code{inet6} (IPv6), or @code{any}, which selects both @code{inet} and
+@code{inet6}.  The upstream default in @code{any}.  However, we
+currently default to @code{inet} due to a nondeterministic
+@command{sshd} startup failure when using IPv6 on Guix.  See
+@uref{https://issues.guix.info/issue/30993, the bug report} for more
+information on this temporary limitation.
+
 @item @code{extra-content} (default: @code{""})
 This field can be used to append arbitrary text to the configuration file.  It
 is especially useful for elaborate configurations that cannot be expressed
diff --git a/gnu/services/ssh.scm b/gnu/services/ssh.scm
index d2dbb8f80d..7e25810eff 100644
--- a/gnu/services/ssh.scm
+++ b/gnu/services/ssh.scm
@@ -4,6 +4,7 @@
 ;;; Copyright © 2016 Julien Lepiller 
 ;;; Copyright © 2017 Clément Lassieur 
 ;;; Copyright © 2019 Ricardo Wurmus 
+;;; Copyright © 2019 Leo Famulari 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -340,7 +341,16 @@ The other options should be self-descriptive."
   ;; proposed in .  Keep it internal/undocumented
   ;; for now.
   (%auto-start?  openssh-auto-start?
- (default #t)))
+ (default #t))
+
+  ;; Symbol
+  ;; XXX: This shouldn't be required, but due to limitations with IPv6
+  ;; on Guix, sshd often fails to start when it attempts to bind to both
+  ;; 0.0.0.0 and ::, because the IPv6 interface is not ready in time.
+  ;; Accepted options are inet (IPv4), inet6 (IPv6), or any (both).
+  ;; 
+  (address-familyopenssh-configuration-address-family
+ (default 'inet)))
 
 (define %openssh-accounts
   (list (user-group (name "sshd") (system? #t))
@@ -468,6 +478,10 @@ of user-name/file-like tuples."
   (symbol->string
(openssh-configuration-log-level config
 
+   (format port "AddressFamily ~a\n"
+   #$(symbol->string
+  (openssh-configuration-address-family config)))
+
;; Add '/etc/authorized_keys.d/%u', which we populate.
(format port "AuthorizedKeysFile \
  .ssh/authorized_keys .ssh/authorized_keys2 /etc/ssh/authorized_keys.d/%u\n")
-- 
2.24.0






bug#26608: channels.scm supporting substitutes

2019-12-03 Thread Nome Grey
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
https://github.com/nomr72/guix-substitutes-channel .  It seems to run again
now.

Maybe I can learn enough to upgrade it to check the 'guix-master'
evaluations to find the latest build of key packages.  We'll see.


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

2019-12-03 Thread Nome Grey
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 all requests.
>
>


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

2019-12-03 Thread Ricardo Wurmus


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#38428: closed (Re: bug#38428: issues.guix.gnu.org gives 500 server error for some old issues)

2019-12-03 Thread Nome Grey
Just to note it somewhere, the 500 errors are back.

On Sun, Dec 1, 2019, 12:47 AM GNU bug Tracking System 
wrote:

> Your bug report
>
> #38428: issues.guix.gnu.org gives 500 server error for some old issues
>
> which was filed against the guix package, has been closed.
>
> The explanation is attached below, along with your original report.
> If you require more details, please reply to 38...@debbugs.gnu.org.
>
> --
> 38428: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38428
> GNU Bug Tracking System
> Contact help-debb...@gnu.org with problems
>
>
>
> -- Forwarded message --
> From: Ricardo Wurmus 
> To: greynom...@gmail.com
> Cc: 38428-d...@debbugs.gnu.org
> Bcc:
> Date: Sun, 01 Dec 2019 09:46:16 +0100
> Subject: Re: bug#38428: issues.guix.gnu.org gives 500 server error for
> some old issues
>
> Hi Nome Grey,
>
> > I'm trying to access https://issues.guix.gnu.org/issue/26608 and
> > https://issues.guix.gnu.org/issue/32022, which I found from google, and
> > both of them are just giving 500.
>
> this is now fixed.
>
> Unfortunately, Mumi (the software behind issues.guix.gnu.org) is still
> rather slow and due to a regression had to be slowed down a little more…
> I hope to work on this soon.
>
> Thanks for your bug report!
>
> ~~ Ricardo
>
>
>
>
>
> -- Forwarded message --
> From: Nome Grey 
> To: bug-guix@gnu.org
> Cc:
> Bcc:
> Date: Fri, 29 Nov 2019 08:57:17 -0800
> Subject: issues.guix.gnu.org gives 500 server error for some old issues
> I'm trying to access https://issues.guix.gnu.org/issue/26608 and
> https://issues.guix.gnu.org/issue/32022, which I found from google, and
> both of them are just giving 500.
>


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

2019-12-03 Thread Robert Vollmert
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 queries to a number of bugs due to 
this;
assuming this doesn’t affect only me, this seems to be quite bad for dealing 
with
bugs effectively.

Recent example: I did not receive Guillaume’s first reply in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38469

Related: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=5439 (against debbugs).

I might report this against debbugs itself instead, but to me the bug is more
“the Guix bug tracker doesn’t send follow-ups” rather than the specific debbugs
issue. E.g. fixing this by using a different bug tracker would be great! :)






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

2019-12-03 Thread Robert Vollmert
> 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 developer config fragment that
would modify a system configuration with settings that are a good
idea for Guix development, if not general use? That might also include
things like setting the $%!^@!*^% guile backtrace columns variable
for guix-daemon.






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

2019-12-03 Thread Josh Holland
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 it.
---
I have tested building the kodi-wayland package with this patch, and
it successfully builds and the tests pass.

 gnu/local.mk  |  1 +
 gnu/packages/kodi.scm |  3 +-
 .../kodi-skip-testmasseventgeneral.patch  | 59 +++
 3 files changed, 62 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/kodi-skip-testmasseventgeneral.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index e2d922373e..4fc690c785 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1036,6 +1036,7 @@ dist_patch_DATA = 
\
   %D%/packages/patches/kodi-increase-test-timeout.patch\
   %D%/packages/patches/kodi-set-libcurl-ssl-parameters.patch   \
   %D%/packages/patches/kodi-skip-test-449.patch\
+  %D%/packages/patches/kodi-skip-testmasseventgeneral.patch \
   %D%/packages/patches/laby-make-install.patch \
   %D%/packages/patches/lcalc-default-parameters-1.patch\
   %D%/packages/patches/lcalc-default-parameters-2.patch\
diff --git a/gnu/packages/kodi.scm b/gnu/packages/kodi.scm
index 59ea11f812..04d879bd17 100644
--- a/gnu/packages/kodi.scm
+++ b/gnu/packages/kodi.scm
@@ -281,7 +281,8 @@ alternatives. In compilers, this can reduce the cascade of 
secondary errors.")
 "1m0295czxabdcqyqf5m94av9d88pzhnzjvyfs1q07xqq82h313p7"))
   (patches (search-patches "kodi-skip-test-449.patch"
"kodi-increase-test-timeout.patch"
-   
"kodi-set-libcurl-ssl-parameters.patch"))
+   "kodi-set-libcurl-ssl-parameters.patch"
+   "kodi-skip-testmasseventgeneral.patch"))
   (snippet
'(begin
   (use-modules (guix build utils))
diff --git a/gnu/packages/patches/kodi-skip-testmasseventgeneral.patch 
b/gnu/packages/patches/kodi-skip-testmasseventgeneral.patch
new file mode 100644
index 00..89fe60b598
--- /dev/null
+++ b/gnu/packages/patches/kodi-skip-testmasseventgeneral.patch
@@ -0,0 +1,59 @@
+This test has been intermittently failing since version 18.2 (see Guix
+bug 36675).
+
+438/521 Test #438: TestMassEvent.General 
Child aborted***Exception:  
 0.82 sec
+Note: Google Test filter = TestMassEvent.General
+[==] Running 1 test from 1 test case.
+[--] Global test environment set-up.
+[--] 1 test from TestMassEvent
+[ RUN  ] TestMassEvent.General
+[   OK ] TestMassEvent.General (105 ms)
+[--] 1 test from TestMassEvent (105 ms total)
+
+[--] Global test environment tear-down
+[==] 1 test from 1 test case ran. (142 ms total)
+[  PASSED  ] 1 test.
+kodi-test: ../nptl/pthread_mutex_lock.c:434: __pthread_mutex_lock_full: 
Assertion `robust || (oldval & FUTEX_OWNER_DIED) == 0' failed.
+
+---
+ xbmc/threads/test/TestEvent.cpp | 19 +--
+ 1 file changed, 9 insertions(+), 10 deletions(-)
+
+diff --git a/xbmc/threads/test/TestEvent.cpp b/xbmc/threads/test/TestEvent.cpp
+index 40e644c0ed..8fe329caa4 100644
+--- a/xbmc/threads/test/TestEvent.cpp
 b/xbmc/threads/test/TestEvent.cpp
+@@ -592,17 +592,17 @@ template  void 
RunMassEventTest(std::vector>& m, boo
+ }
+
+
+-TEST(TestMassEvent, General)
+-{
+-  g_event = new CEvent();
++// TEST(TestMassEvent, General)
++// {
++//   g_event = new CEvent();
+
+-  std::vector> m(NUMTHREADS);
+-  for(size_t i=0; i> m(NUMTHREADS);
++//   for(size_t i=0; i

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

2019-12-03 Thread pelzflorian (Florian Pelz)
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 comments.
> 
> All the best,
> simon

Sorry I had totally forgotten about my bug report and do not have a
patch.  I do not have time at the moment or good knowledge of current
documentation and discussions, sorry.  I would be most happy if you
and/or others made patches for better explanations of profiles,
environments and propagated inputs.

Thank you for looking at / searching for old (but current) issues.

Regards,
Florian





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

2019-12-03 Thread Guillaume Le Vaillant


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 guix repository as my default channel, which
>   includes a number of slow-to-build Haskell packages. Now and
>   then, I run out of disk space. So I call `guix gc`, which invariably
>   removes the store paths involved in building my current system generation,
>   so the next call to `guix system reconfigure` takes hours.
>
> Desired situation:
>   After calling `guix gc`, the paths that were involved in my last system
>   build are still around, so reconfiguring doesn’t result in everything
>   being rebuilt.
>
> (If there’s some way I can achieve that now, perhaps by explicitly managing
> some roots, or passing specific arguments to `guix gc`, I’d be happy to
> know! I’d still argue that we should try to make this the default behaviour,
> though.)

Have you tried passing the options '--gc-keep-derivations=yes' and
'--gc-keep-outputs=yes' to guix-daemon?

In the operating-system definition, it would be something like:
--8<---cut here---start->8---
(services
   (cons* (service ...)
  [...]
  (modify-services %desktop-services
(guix-service-type config =>
  (guix-configuration
   (inherit config)
   (extra-options '("--gc-keep-derivations=yes"
"--gc-keep-outputs=yes")))
--8<---cut here---end--->8---





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

2019-12-03 Thread zimoun
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 report.

[2] 
https://guix.gnu.org/manual/en/html_node/package-Reference.html#package-Reference
[3] 
https://guix.gnu.org/manual/en/html_node/Invoking-guix-package.html#Invoking-guix-package


You proposed:

<<
 1) that `propagated-inputs` are automatically installed *to the Guix
profile* and not just the Store like regular inputs and
 2) that C/C++ libraries do not need to be propagated because they can
just as well be loaded from the Store *unless* their header files are
included by header files of another input package (?) and
 3) more examples like the above example for GNOME Evolution (which
however I have yet to finish packaging and submit as a patch; maybe
dconf is a better example – I presume it is also needed at run time and
not just).
>>

And I agree. I also had issue and I remember asking on IRC explanations.


Do you have already a patch? If no, do you plan to prepare one?


Thank you in advance for any comments.

All the best,
simon





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

2019-12-03 Thread Robert Vollmert
[ 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, which
  includes a number of slow-to-build Haskell packages. Now and
  then, I run out of disk space. So I call `guix gc`, which invariably
  removes the store paths involved in building my current system generation,
  so the next call to `guix system reconfigure` takes hours.

Desired situation:
  After calling `guix gc`, the paths that were involved in my last system
  build are still around, so reconfiguring doesn’t result in everything
  being rebuilt.

(If there’s some way I can achieve that now, perhaps by explicitly managing
some roots, or passing specific arguments to `guix gc`, I’d be happy to
know! I’d still argue that we should try to make this the default behaviour,
though.)






bug#38435: BTRFS open_ctree failed

2019-12-03 Thread Guillaume Le Vaillant


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
>> >
>> > Previous profiles work, I haven't modified anything about my
>> > config.scm between them.
>> >
>> > [...]
>> >
>> >
>> > Contents of /etc/profile.scm:
>> >
>> > [...]
>> >
>> >   (file-systems (cons* (file-system
>> >  (device (file-system-label "GUIX"))
>> >  (mount-point "/")
>> > (options "lazytime,compress")
>> >  (type "btrfs"))
>> >;(file-system
>> >;  (device (uuid "1234-ABCD" 'fat))
>> >;  (mount-point "/boot/efi")
>> >;  (type "vfat"))
>> >%base-file-systems))
>> >  
>> 
>> I just tried adding the 'lazytime' option to my root file system, and
>> I got the same error as you when booting. Could you try removing it
>> and see if it works?
>> 
>> Until recently, the options declared in 'file-system' records were
>> always ignored when mounting the root file system. Now they are taken
>> into consideration, and I think it reveals a bug in the way file
>> systems are mounted. If some options like 'lazytime' or 'defaults'
>> are declared in a 'file-system' record (root file system or not),
>> mounting it fails. However some other options like 'compress' or
>> 'autodefrag' work fine.
>> 
>> I suspect Guix adds some options by default when trying to mount file
>> systems, and maybe we end up with conflicting options or doubled
>> options that cause problems.
>> 
>> 
>> 
>
> I removed it and ran reconfigure and now it works.

Applying patches #38462 and #38468 and changing the file system
definition to the following should allow you to mount the root file
system with the 'lazytime' option:

--8<---cut here---start->8---
(file-system
  (device (file-system-label "GUIX"))
  (mount-point "/")
  (flags '(lazy-time))
  (options "compress")
  (type "btrfs"))
--8<---cut here---end--->8---





bug#37757: Kernel panic upon shutdown

2019-12-03 Thread Arne Babenhauserheide

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 politisch sein
ohne es zu merken


signature.asc
Description: PGP signature


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

2019-12-03 Thread Arne Babenhauserheide

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 example because it
catches key-combinations I need to pass to the IDE.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature


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

2019-12-03 Thread Ludovic Courtès
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
> considered useless. That is why the package is unfortunately so large. I
> don't think there's anything that can be done about that. 
>
> A couple of binaries are also copied, not just JSON files. That is where
> the 32-bit dependencies come from. 

OK, that’s what I feared.  Case closed, then!

Thanks for your reply,
Ludo’.





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

2019-12-03 Thread Rutger Helling
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 unfortunately so large. I
don't think there's anything that can be done about that. 


A couple of binaries are also copied, not just JSON files. That is where
the 32-bit dependencies come from. 


On 2019-11-23 00:12, Ludovic Courtès wrote:


Hello,

I noticed that 'wine64-staging' is our most expensive package to build.
Initially I was surprised because it only has a couple of nodes more in
its  object than 'wine-staging':

--8<---cut here---start->8---
ludo@ribbon ~/src/guix$ guix graph wine-staging |grep 'label = ' |wc -l
509
ludo@ribbon ~/src/guix$ guix graph wine64-staging |grep 'label = ' |wc -l
511
--8<---cut here---end--->8---

However, that single additional node leads to the duplication of the
whole derivation graph on x86_64-linux:

--8<---cut here---start->8---
ludo@ribbon ~/src/guix$ guix graph -t derivation wine-staging |grep 'label = ' 
|wc -l
2738
ludo@ribbon ~/src/guix$ guix graph -t derivation wine64-staging |grep 'label = 
' |wc -l
4598
--8<---cut here---end--->8---

This is because 'wine-staging' has a hard-coded '#:system "i686-linux"',
whereas 'wine64-staging' is (unsurprisingly :-)) built on x86_64-linux.

(The same problem happens with 'wine' vs. 'wine64'.)

Likewise, 'guix size wine64' shows that every dependency appears twice
(one 32-bit, one 64-bit), and thus the total size is twice that of
'wine'.

Rutger, is there something that can be done to avoid this?  Apparently
only JSON files are copied from 'wine-staging' into 'wine64-staging',
but maybe they refer to 32-bit shared libraries or something?

Thanks,
Ludo'.