bug#53700: Guix package is hardcoded in guix home

[Andrew Tropin]

On 2022-03-02 12:06, Ludovic Courtès wrote:

> Hi,
>
> Gordon Quad  skribis:
>
>> guix home uses guix package directly imported from (gnu packages
>> package-management) gnu/home/services.scm:22
>>
>> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services.scm#n22
>>
>> It looks like for now it is used only here gnu/home/services.scm:283
>>
>> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services.scm#n284
>>
>> It is quite unfortunte to see guix home to pull whole extra copy of guix
>> only to use few files to do gettext localization init.
>
> Yes, it’s a bit heavy-handed.
>
>> If would be nice to be able to customize guix package used there so I
>> can make sure guix used by guix home is the same as in my guix daemon.
>
> I’m not sure I understand.  As you write, the ‘guix’ package is used in
> (gnu home services) only to get gettext catalogs; AFAICS it’s not used
> for anything else.
>
> Could you clarify what you had in mind?

I was hit by this one yesterday as well.  I tried to manage just a few
config files with Guix Home on foreign distro, but it started to
download 46 megabytes of guix package, while I expected it to work
completely offline.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

bug#62163: Suppress logging shepherd evaluation in mcron.log

[Maxim Cournoyer]

Hi,

Bruno Victal  writes:

> On 2023-03-30 11:22, Ludovic Courtès wrote:
>> Hi,
>> 
>> Bruno Victal  skribis:
>> 
>>> On 2023-03-28 17:25, Ludovic Courtès wrote:

 Nope. :-)  What is ‘my-heartbeat-job’ doing?
>>>
>>> It queries shepherd to see if a service is running and sends a restart if 
>>> required.
>> 
>> Isn’t that what #:respawn? #t is supposed to do?  :-)
>> 
>> If you find that #:respawn? doesn’t work, then we should fix it.
>
> Oh, I should have explained better here.
> Re-spawn works, it's the (daemon) service that might misbehave/go 
> unresponsive without crashing,
> i.e. HTTP backend stops responding to API requests but the server is still up.
> The job performs a "health-check" and restarts it if it doesn't get the 
> appropriate response.
>
> A concrete situation where this could be of use is for logs.guix that 
> occasionally stops
> recording.

So some kind of supervisor for the job, that specific run time checks to
ensure the process is still doing its job, if I understand correctly.  I
wonder if this use case could be integrated into our Shepherd services
themselves, via some supervisor slot or similar, that would run some
script periodically.

-- 
Thanks,
Maxim

bug#40567: mpd-service-type needs a pre-existing user in system and does not works with a new user defined in config.scm

[Bruno Victal]

Hi Veera,

On 2020-04-12 05:25, R Veera Kumar wrote:
> Hi,
> 
> This is to report:
> mpd-service-type needs a pre-existing user in system and does not works
> with a new user defined in config.scm. Running guix system reconfigure 
> gives some getpw error.
> 
> Guix system reconfigure works fine if we add temporarily a user with useradd.
> 
> Thanks,
> Veera

This bug no longer applies as mpd-service-type has gone through some 
refactorings in the meantime.
Worth noting is that mpd-service-type isn't meant to be used with interactive 
user-accounts, for
such cases a home service variant should be used instead.


Cheers,
Bruno

bug#62448: [PATCH] doc: Note that `guix shell` should contain base language packages.

[Josselin Poiret via Bug reports for GNU Guix]

* doc/guix.texi (Invoking guix shell): Explain that python must be included in
the invocation even if it is already available in the external environment.

Suggested-by: Skyler 
---
 doc/guix.texi | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index c49e51b72e..879a526b77 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -96,7 +96,7 @@ Copyright @copyright{} 2021 Domagoj Stolfa@*
 Copyright @copyright{} 2021 Hui Lu@*
 Copyright @copyright{} 2021 pukkamustard@*
 Copyright @copyright{} 2021 Alice Brenon@*
-Copyright @copyright{} 2021, 2022 Josselin Poiret@*
+Copyright @copyright{} 2021, 2022, 2023 Josselin Poiret@*
 Copyright @copyright{} 2021 muradm@*
 Copyright @copyright{} 2021, 2022 Andrew Tropin@*
 Copyright @copyright{} 2021 Sarah Morgensen@*
@@ -5959,6 +5959,14 @@ building or downloading any missing package, and runs the
 guix shell python python-numpy -- python3
 @end example
 
+Note that it is necessary to include the main @code{python} package in
+this command even if it is already installed into your environment. This
+is so that the shell environment knows to set @env{PYTHONPATH} and other
+related variables. The shell environment cannot check the previously
+installed environment, because then it would be non-deterministic.  This
+is true for most libraries: their corresponding language package should
+be included in the shell invocation.
+
 @quotation Note
 @cindex shebang, for @command{guix shell}
 @command{guix shell} can be also be used as a script interpreter, also

base-commit: be5e280e5fe26f93bd5a6e3f76e4502edb913a94
-- 
2.39.2

bug#62448: Inconsistent guile enviornment from guix shell

[Josselin Poiret via Bug reports for GNU Guix]

Hi Skyler,

It's a shame that nobody had pointed out this (quite common) missing
piece earlier.

Skyler via Bug reports for GNU Guix  writes:

> In spite of being reasonable, it is not particularly intuitive. Could I 
> recommend an addition to the manual in section "7.1 Invoking guix-shell", 
> adding text like the below after the example invocation `guix shell python 
> python-numpy -- python3​`?
>
> "Note that it is necessary to include the main python package in this command 
> even if it is already installed into your environment. This is so that the 
> shell environment knows to set PYTHONPATH and other related variables. The 
> shell environment cannot check the previously installed environment, because 
> then it would be non-deterministic."

Yes, this would be a good idea.  I can try to do this right now.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#62496: For network-manager-applet's nm-connection-editor, libnma needs to be installed

[Maxim Cournoyer]

Hi,

Ludovic Courtès  writes:

> Hello,
>
> "P. p. phalantha"  skribis:
>
>> Invoking nm-connection-editor from the command line and repeating these
>> steps gave the informative error message:
>>
>> ```
>> (nm-connection-editor:1751): GLib-GIO-ERROR **: 02:02:58.502: Settings
>> schema 'org.gnome.nm-applet.eap' is not installed
>> Trace/breakpoint trap
>> ```
>>
>> I found a fix via the installation of libnma, thanks to a 2012 thread on
>> LinuxQuestions.org:
>> https://www.linuxquestions.org/questions/slackware-14/network-manager-applet-1-16-0-i586-1-package-is-missing-%27org-gnome-nm-applet%27-schema-4175670946/.
>> After the installation of libnma I was able to successfully add the network.
>
> I experienced this problem just today and your bug report was helpful!
>
> Actually, both libnma and network-manager-applet provide the relevant
> schema file, but they’re different:
>
> $ find $(guix build libnma) -name \*nm-applet\*
> /gnu/store/hh0mq79nqhcwkpx7v68dibcv9lbha7sn-libnma-1.10.2/share/glib-2.0/schemas/org.gnome.nm-applet.gschema.xml
> $ diff -u 
> /gnu/store/9hl2p2xzlkkwibankp8604ngha880yn2-network-manager-applet-1.30.0/share/glib-2.0/schemas/org.gnome.nm-applet.gschema.xml
>  
> /gnu/store/hh0mq79nqhcwkpx7v68dibcv9lbha7sn-libnma-1.10.2/share/glib-2.0/schemas/org.gnome.nm-applet.gschema.xml
> --- 
> /gnu/store/9hl2p2xzlkkwibankp8604ngha880yn2-network-manager-applet-1.30.0/share/glib-2.0/schemas/org.gnome.nm-applet.gschema.xml
>   1970-01-01 01:00:01.0 +0100
> +++ 
> /gnu/store/hh0mq79nqhcwkpx7v68dibcv9lbha7sn-libnma-1.10.2/share/glib-2.0/schemas/org.gnome.nm-applet.gschema.xml
>   1970-01-01 01:00:01.0 +0100
> @@ -1,6 +1,6 @@
>  
>  
> -   gettext-domain="nm-applet">
> +   gettext-domain="libnma">
>  
>false
>Disable connected notifications
> @@ -37,4 +37,16 @@
>Set to FALSE to disable displaying the applet in the 
> notification area.
>  
>
> +  
> +
> +  false
> +  Ignore CA certificate
> +  Set this to true to disable warnings about CA 
> certificates in EAP authentication.
> +
> +
> +  false
> +  Ignore CA certificate
> +  Set this to true to disable warnings about CA 
> certificates in phase 2 of EAP authentication.
> +
> +  
>  
>
> The one in libnma has the extra “.eap” thing.
>
> The attached hack works, but it looks like something’s wrong, maybe
> related to ?
>
> Ludo’.
>
> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
> index 0efb98b97c..aac847710d 100644
> --- a/gnu/packages/gnome.scm
> +++ b/gnu/packages/gnome.scm
> @@ -8921,9 +8921,18 @@ (define-public network-manager-applet
>  "1lswxfxjfbiknspwli8d65i0bnyfazzcnrqckaw0s44zkm7bh5lm"
>  (build-system meson-build-system)
>  (arguments
> - `(#:glib-or-gtk? #t
> -   #:configure-flags
> -   '("-Dappindicator=yes")))
> + (list #:glib-or-gtk? #t
> +   #:configure-flags #~'("-Dappindicator=yes")
> +   #:phases
> +   #~(modify-phases %standard-phases
> +   (add-after 'install 'copy-gsettings-schema
> + (lambda* (#:key inputs #:allow-other-keys)
> +   (define schema
> + 
> "share/glib-2.0/schemas/org.gnome.nm-applet.gschema.xml")
> +
> +   (delete-file (string-append #$output "/" schema))
> +   (symlink (search-input-file inputs schema)
> +(string-append #$output "/" schema)))
>  (native-inputs
>   (list gettext-minimal
> `(,glib "bin") ; for glib-compile-resources, etc.
>

I've reverted to the previously working version on master, but we should
figure out what's up with this change in recent releases.  It may affect
1.42 as well (which is supposedly the current stable release).

Leaving this open.  Thanks for investigating.

-- 
Thanks,
Maxim

bug#62513: network-manager updated to unstable version?

[Maxim Cournoyer]

Hi,

Csepp  writes:

> Maxim Cournoyer  writes:
>
>> Hi John,
>>
>> John Kehayias  writes:
>>
>>> Hi Guix,
>>>
>>> (cc'ing Maxim as author of last few network-manager version updates.)
>>>
>>> I noticed a recent up date to network-manager to 1.43.4 (previously
>>> 1.41.2 and 1.40.0) but can't find a record of that release. In their
>>> docs there is no mention of anything newer than the 1.42 release [0,
>>> 1] and they mention the even-numbered releases being the stable series
>>> [2]. Indeed, Arch only has 1.42.4 in their repos [3]. I only see "dev"
>>> tags for these 1.43 versions in their gitlab.
>>>
>>> Should we be on a 1.42.y version instead?
>>
>> The GNOME versioning scheme is a bit of a mess; they stopped using
>> stable/unstable oven/odd release cycles since GNOME 40 I think, but left
>> each of the components the luxury to keep using it, which NetworkManager
>> appears to be doing.
>>
>> 'guix refresh -u' picked 1.43 and I didn't give it much of an thought.
>> In general, I think it's OK to carry the "unstable" releases of GNOME
>> components, which in my experience are usually stable :-).
>>
>>> I noticed this because the update to 1.43.4 has an issue with my
>>> (wired) connection not resuming from sleep when previously it did. I
>>> have to restart the service. I had some logs I can dig up, but in
>>> discussing on IRC (no logs that day it seems) there was nothing out of
>>> the ordinary and the shepherd service seemed normal.
>>>
>>> I've since reconfigured to a commit before the most recent version
>>> change, namely 5174820753be045ba4fc7cc93da33f4e0b730bc3 and cannot
>>> reproduce the issue so seems due to newer versions of network-manager
>>> after 1.41.2 at least.
>>>
>>> Note that this may have been reported upstream [4], but I haven't
>>> tested with the current stable release. So this may be a separate
>>> (upstream) issue.
>>
>> So it seems that even if we used the "stable" 1.42.x release, we'd still
>> have this problem.  It's been reported 4 days ago; I guess let's wait to
>> see if a hotfix will be made, as that seems a serious issue.
>>
>> Otherwise, if many Guix users are affected and no hotfix is on the
>> horizon, we could consider reverting back to our older version.
>>
>> Does that sound reasonable?
>
> This also affects two of my recently reconfigured/upgraded machines.  My
> guess is there are probably many others affected.

I take this as a "no" :-).

Reverted with be5e280e5fe26f93bd5a6e3f76e4502edb913a94.

Closing.

-- 
Thanks,
Maxim

bug#62547: --symlink option of "guix shell -C -F" is non-functional for /lib and /usr/lib, unlike /bin

[Maxime Devos]

$ guix shell -F -C tk -- some-software
# ... libtk8.5 not found, let's choose version 8.5

$ LC_ALL=en_GB.UTF-8 guix shell -F -C tk@8.5 shell
guix shell: error: tk: package not found for version 8.5

# Guix doesn't have version 8.5.  Let's lie and pretend
# that 8.5=8.6, maybe it will be ‘close enough’ for
# ‘some-software’.

$ guix shell -F -C tk --symlink=/lib/libtk8.5.so=/lib/libtk8.5.so -- 
some-software


guix shell: fout: symlink target is absolute: '/lib/libtk8.5.so'

tip: The target of the symlink must be relative rather than absolute, as 
it is relative to the profile created.
Perhaps the source and target components of the symlink spec were 
inverted? Below is a valid example, where the

`/usr/bin/env' symbolic link is to target the profile's `bin/env' file:

 --symlink=/usr/bin/env=bin/env

# Looks an arbitrary limitation to me -- the symlink code could just
# treat absolute targets as absolute instead of relative to the profile.
# Still, let's give following the tip a try.

$ LC_ALL=en_GB.UTF-8 guix shell -F -C tk 
--symlink=/lib/libtk8.5.so=lib/libtk8.6.so -- some-software
error: failed to evaluate directive: ("/lib/libtk8.5.so" -> 
"/gnu/store/sbvf4784c43ssr20x45icvm8s8h7zvh4-profile/lib/libtk8.6.so")

guix shell: error: symlink: Read-only file system: ".//lib/libtk8.5.so"


# If /usr/lib is tried instead of /lib, a different error occurs:

$ LC_ALL=en_GB.UTF-8 guix shell -F -C tk 
--symlink=/usr/lib/libtk8.5.so=lib/libtk8.6.so -- some-software


guix shell: error: symlink: File exists: "/usr/lib"

# Contrast this with /bin, in which files symlinks can be put, unlike
# /usr/lib and /lib (yes I know that putting libraries in /bin doesn't
# make much sense, it's just an example):

$ LC_ALL=en_GB.UTF-8 guix shell -F -C tk 
--symlink=/bin/libtk8.5.so=lib/libtk8.6.so -- some-software

guix shell: error: some-software: command not found
hint: Did you mean 'mtrace'?

Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#59131: gnu: emacs-magit: Tests fail.

[Maxim Cournoyer]

"("  writes:

> Fixed independently of my patch by updating to that commit.

Thanks for the heads-up; closing.

-- 
Thanks,
Maxim

bug#62513: network-manager updated to unstable version?

[Csepp]

Maxim Cournoyer  writes:

> Hi John,
>
> John Kehayias  writes:
>
>> Hi Guix,
>>
>> (cc'ing Maxim as author of last few network-manager version updates.)
>>
>> I noticed a recent up date to network-manager to 1.43.4 (previously
>> 1.41.2 and 1.40.0) but can't find a record of that release. In their
>> docs there is no mention of anything newer than the 1.42 release [0,
>> 1] and they mention the even-numbered releases being the stable series
>> [2]. Indeed, Arch only has 1.42.4 in their repos [3]. I only see "dev"
>> tags for these 1.43 versions in their gitlab.
>>
>> Should we be on a 1.42.y version instead?
>
> The GNOME versioning scheme is a bit of a mess; they stopped using
> stable/unstable oven/odd release cycles since GNOME 40 I think, but left
> each of the components the luxury to keep using it, which NetworkManager
> appears to be doing.
>
> 'guix refresh -u' picked 1.43 and I didn't give it much of an thought.
> In general, I think it's OK to carry the "unstable" releases of GNOME
> components, which in my experience are usually stable :-).
>
>> I noticed this because the update to 1.43.4 has an issue with my
>> (wired) connection not resuming from sleep when previously it did. I
>> have to restart the service. I had some logs I can dig up, but in
>> discussing on IRC (no logs that day it seems) there was nothing out of
>> the ordinary and the shepherd service seemed normal.
>>
>> I've since reconfigured to a commit before the most recent version
>> change, namely 5174820753be045ba4fc7cc93da33f4e0b730bc3 and cannot
>> reproduce the issue so seems due to newer versions of network-manager
>> after 1.41.2 at least.
>>
>> Note that this may have been reported upstream [4], but I haven't
>> tested with the current stable release. So this may be a separate
>> (upstream) issue.
>
> So it seems that even if we used the "stable" 1.42.x release, we'd still
> have this problem.  It's been reported 4 days ago; I guess let's wait to
> see if a hotfix will be made, as that seems a serious issue.
>
> Otherwise, if many Guix users are affected and no hotfix is on the
> horizon, we could consider reverting back to our older version.
>
> Does that sound reasonable?

This also affects two of my recently reconfigured/upgraded machines.  My
guess is there are probably many others affected.

bug#62163: Suppress logging shepherd evaluation in mcron.log

[Bruno Victal]

On 2023-03-30 11:22, Ludovic Courtès wrote:
> Hi,
> 
> Bruno Victal  skribis:
> 
>> On 2023-03-28 17:25, Ludovic Courtès wrote:
>>>
>>> Nope. :-)  What is ‘my-heartbeat-job’ doing?
>>
>> It queries shepherd to see if a service is running and sends a restart if 
>> required.
> 
> Isn’t that what #:respawn? #t is supposed to do?  :-)
> 
> If you find that #:respawn? doesn’t work, then we should fix it.

Oh, I should have explained better here.
Re-spawn works, it's the (daemon) service that might misbehave/go unresponsive 
without crashing,
i.e. HTTP backend stops responding to API requests but the server is still up.
The job performs a "health-check" and restarts it if it doesn't get the 
appropriate response.

A concrete situation where this could be of use is for logs.guix that 
occasionally stops
recording.


> 
> You can send messages to the bitbucket with:
> 
>   (parameterize ((shepherd-message-port (%make-void-port "w0")))
> …)

Thanks!
I'm still curious as to exactly what/which lines cause shepherd to output the 
lines.


Cheers,
Bruno

bug#62163: Suppress logging shepherd evaluation in mcron.log

[Ludovic Courtès]

Hi,

Bruno Victal  skribis:

> On 2023-03-28 17:25, Ludovic Courtès wrote:
>> 
>> Nope. :-)  What is ‘my-heartbeat-job’ doing?
>
> It queries shepherd to see if a service is running and sends a restart if 
> required.

Isn’t that what #:respawn? #t is supposed to do?  :-)

If you find that #:respawn? doesn’t work, then we should fix it.

> (define* (heartbeat-supervisor #:key (name #f) service task
>#:allow-other-keys)
>   ;; Query service status and restart if needed.
>   (program-file
>(format #f "~@[~a-~]heartbeat-supervisor.scm" name)
>(with-imported-modules (source-module-closure
>'((gnu services herd)))
>  #~(begin
>  (use-modules (gnu services herd)
>   (srfi srfi-1))
>
>  (define (is-service-running? sym)
>(lambda (x)
>  (and (live-service-running x)
>   (memq sym (live-service-provision x)
>
>  (let ((running? (not (null?
>(any (is-service-running? '#$service)
> (current-services))

You can send messages to the bitbucket with:

  (parameterize ((shepherd-message-port (%make-void-port "w0")))
…)

HTH,
Ludo’.