bug#51141: guix home reconfigure does not apply changes to shepherd services

2021-10-16 Thread Oleg Pykhalov
Hi Andrew,

Andrew Tropin  writes:

> On 2021-10-12 01:53, Oleg Pykhalov wrote:
>
>> After changing a home shepherd service I tried to reconfigure with 'guix
>> home reconfigure'.
>>
>> Process started by a service did not restart.  Assuming home shepherd is
>> like Guix System shepherd I tried to 'herd restart SERVICE_NAME', the
>> process restarted but without changes in a service definition.
>
> It's intentional, only `herd load root new-config.conf` called on
> activation, so existing services are not affected to prevent situations,
> where emacs daemon or other important process killed in the middle of
> unsaved work.

If I change something inside a system service definition
SERVICE-shepherd-service and then invoke 'guix system reconfigure', the
service will not restart and not produce any effect until I inoke 'sudo
herd restart SERVICE'.

After herd restart the service will be running with applied changes and
does not require 'herd unload root SERVICE_NAME'.
E.g. nginx-service-type.

I think this behaviour should be the same for home services.  WDYT?


signature.asc
Description: PGP signature


bug#50677: [PATCH] Minetest basic_materials really depends on moreores

2021-10-16 Thread Tobias Geerinckx-Rice via Bug reports for GNU Guix

Vivien,

Thanks!  I've pushed this series as 
df2404482495bc3af03e7fc902af1e6b0d10b4a4 et al.


I made a only few small tweaks, mainly to the commit message:


gnu: minetest-basic-materials: Depend on minetest-moreores.


‘Depend’ sounds wrong to me; it either does, or it doesn't, we 
don't determine that.  Changed to ‘Propagate …’


* minetest.scm (minetest-basic-materials): Add minetest-moreores 
as a propagated input.


Keep Git commit message body lines <=72 characters.  Most 
(non-Guix) tooling is built around that assumption.


Also use full relative file names, and use [field] notation where 
appropriate:


 * gnu/packages/foo.scm (foo)[propagated-inputs]: Add bar.

For the build system patches, I changed


guix: minetest-build-system: […]


to

 build-system/minetest: […]

Why?  Because it's shorter.  Is this a documented rule?  I can't 
say!



;; basic_materials:silver_wire cannot be crafted without
;; moreores:silver_ingot.


Documenting this is a great idea.


(commit "0b6f669df4c9b7771c03e0e6ba8effb471cdfcae")))


I changed this to

 (commit (string-append "v" version))

to use the git tag.

Both have advantages & disadvantages, but this is our currently 
preferred style.



(synopsis "Adds new ore types")
(description "More ores for Minetest.")


These aren't acceptable.  See (guix)Synopses and Descriptions.

This was my attempt at improving the importer's lazywork:

 (synopsis "Additional ore types, tools, swords, and rails for 
 Minetest")

 (description
  "This Minetest mod adds new ore types to the game (mithril, 
  silver) as well
as swords and tools made of different materials.  It also adds 
copper rails.")


Bit vague, but you know why.

Closing; thanks!

T G-R


signature.asc
Description: PGP signature


bug#51127: Acknowledgement (deja-dup cannot start a backup)

2021-10-16 Thread Vivien Kraus via Bug reports for GNU Guix
Le jeudi 14 octobre 2021 à 18:56 +0200, Vivien Kraus a écrit :
> Le jeudi 14 octobre 2021 à 18:43 +0200, Vivien Kraus a écrit :
> > So, I figured out the Gio backends for duplicity need a few tweaks.
> > 
> > You can test it by creating a stupid backup (backup any dir in
> > /tmp).
> > Now it works :)

And now with cooler ChangeLog commit messages!
> 
> > What do you think?
> > 
> > Vivien

From 39d4726859760ae84f2c82d6d3f811ed092bd373 Mon Sep 17 00:00:00 2001
From: Vivien Kraus 
Date: Thu, 14 Oct 2021 17:30:09 +0200
Subject: [PATCH 3/3] gnu: deja-dup: let deja-dup find duplicity

* gnome.scm (deja-dup)[phases]:
Wrap deja-dup to include duplicity in PATH.
---
 gnu/packages/gnome.scm | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 20c0be8d9d..3a3219f07a 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -1773,7 +1773,14 @@ (define-public deja-dup
(lambda _
  (substitute* "data/post-install.sh"
(("gtk-update-icon-cache") "true"))
- #t)
+ #t))
+ (add-after 'install 'wrap-program
+   (lambda* (#:key inputs outputs #:allow-other-keys)
+ ;; Add duplicity to the search path
+ (wrap-program (string-append (assoc-ref outputs "out")
+  "/bin/deja-dup")
+   `("PATH" ":" prefix
+ (,(format #f "~a/bin" (assoc-ref inputs "duplicity"))
 (inputs
  `(("gsettings-desktop-schemas" ,gsettings-desktop-schemas)
("duplicity" ,duplicity)
-- 
2.33.1

From c7325a5dfbc56e76e92017cb93914a8ed4545c35 Mon Sep 17 00:00:00 2001
From: Vivien Kraus 
Date: Thu, 14 Oct 2021 18:18:56 +0200
Subject: [PATCH 2/3] gnu: duplicity: depend on dbus

* gnu/packages/backup.scm (duplicity)[inputs]:
Add dbus as an input.

* gnu/packages/backup.scm (duplicity)[phases]:
Substitute the dbus-launch program name.
---
 gnu/packages/backup.scm | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/backup.scm b/gnu/packages/backup.scm
index 407f6b7212..d1a718eab3 100644
--- a/gnu/packages/backup.scm
+++ b/gnu/packages/backup.scm
@@ -119,6 +119,7 @@ (define-public duplicity
 (inputs
  `(("librsync" ,librsync)
("lftp" ,lftp)
+   ("dbus" ,dbus)   ; dbus-launch (Gio backend)
("gnupg" ,gnupg) ; gpg executable needed
("util-linux" ,util-linux))) ; for setsid
 (arguments
@@ -130,7 +131,11 @@ (define-public duplicity
  (substitute* "duplicity/gpginterface.py"
(("self.call = u'gpg'")
 (string-append "self.call = '" (assoc-ref inputs "gnupg") "/bin/gpg'")))
-
+ (substitute* "duplicity/backends/giobackend.py"
+   (("subprocess.Popen\\(\\[u'dbus-launch'\\]")
+(string-append "subprocess.Popen([u'"
+   (assoc-ref inputs "dbus")
+   "/bin/dbus-launch']")))
  (substitute* '("testing/functional/__init__.py"
 "testing/overrides/bin/lftp")
(("/bin/sh") (which "sh")))
-- 
2.33.1

From ecaf5368c3d82045d500e0fdb4f1ee45dfbcf185 Mon Sep 17 00:00:00 2001
From: Vivien Kraus 
Date: Thu, 14 Oct 2021 17:18:29 +0200
Subject: [PATCH 1/3] gnu: duplicity: depend on pygobject

* gnu/packages/backup.scm (duplicity)[propagated-inputs]:
Add missing input.
---
 gnu/packages/backup.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/backup.scm b/gnu/packages/backup.scm
index a3f98c95f9..407f6b7212 100644
--- a/gnu/packages/backup.scm
+++ b/gnu/packages/backup.scm
@@ -114,7 +114,8 @@ (define-public duplicity
("mock" ,python-mock)))
 (propagated-inputs
  `(("lockfile" ,python-lockfile)
-   ("urllib3" ,python-urllib3)))
+   ("urllib3" ,python-urllib3)
+   ("pygobject" ,python-pygobject)))
 (inputs
  `(("librsync" ,librsync)
("lftp" ,lftp)
-- 
2.33.1



bug#51213: ghci missing reference to gcc

2021-10-16 Thread Jack Hill

On Thu, 14 Oct 2021, Jack Hill wrote:


Hi Guix,

Using Guix 5fafb6e792c1e18ec223f0c7fb350d0c9b962a45, running ghci in an 
environment can't find gcc:


Some more observations about this problem. It only occurs with our two 
newest GHC packages (8.10.7 and 8.8.4), previous releases start ghci and 
perform light usage fine. However, all releases fail to build executables 
without gcc-toolchain in the path:


```
jackhill@alperton /tmp [env]$ ghc hello.hs 
[1 of 1] Compiling Main ( hello.hs, hello.o )


: error:
Warning: Couldn't figure out C compiler information!
 Make sure you're using GNU gcc, or clang
ghc: could not execute: gcc
jackhill@alperton /tmp [env]$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.10.7
```

Interestingly, clang-toolchain can be substituted for gcc-toolchain to get 
a working ghci, but with 8.10.7, compiling with gcc still doesn't work, 
but ghc 7.10.2 find clang-toolchain to be satisfactory.


Best,
Jack