bug#72527: Rottlog never exits cleanly

[Simon Streit]

Hello jgart,

jgart  writes:

> Would you be interested in sending a v1 patch with a proposal that
> fixes the issue. I could then test it.

I'll workout a patch and post it, once I've got one.  


Kind regards,

-- 
Simon

bug#72527: Rottlog never exits cleanly

[Simon Streit]

Hello!

On inspection of the default settings for Rot[t]log’s service, and
reading through /var/log/mcron.log, rottlog always exits with the
following error:

--8<---cut here---start->8---
2024-08-07 12:00:00 3408 
/gnu/store/scligrs2fwpsy6jvffraa274k7ipbg81-rottlog-0.72.2/sbin/rottlog: 
running...
2024-08-07 12:00:01 3408 
/gnu/store/scligrs2fwpsy6jvffraa274k7ipbg81-rottlog-0.72.2/sbin/rottlog: failed 
after 0.199s with: (misc-error #f unclean exit status ~S (1) #f)
--8<---cut here---end--->8---

Checking directly:

--8<---cut here---start->8---
root@host ~# 
/gnu/store/scligrs2fwpsy6jvffraa274k7ipbg81-rottlog-0.72.2/sbin/rottlog -v
read_custom: Config file 'custom' does not exist
read_daily: Config file 'daily' does not exist
check_last_rotate: Checking for week(ly) config file
check_last_rotate: Old date  : 1722810339
check_last_rotate: New date  : 1723125091
check_last_rotate: Next date : Thu 15 Aug 16:51:31 CEST 2024
check_last_rotate: Rotation not needed: 314752 < 604800
read_monthly: Config file 'monthly' does not exist
root@host ~# echo $?
1
--8<---cut here---end--->8---

To experiment a little, I add:

--8<---cut here---start->8---
(simple-service 'nginx-custom-rotations rottlog-service-type
(list (log-rotation
   (frequency 'custom)
   (files '("/var/log/nginx/access.log"
"/var/log/nginx/error.log"))
   (options '("storedir nginx
period 15")
(simple-service 'nginx-daily-rotations rottlog-service-type
(list (log-rotation
   (frequency 'daily)
   (files '("/var/log/nginx/access.log"
"/var/log/nginx/error.log"))
   (options '("storedir nginx")
(simple-service 'nginx-monthly-rotations rottlog-service-type
(list (log-rotation
   (frequency 'monthly)
   (files '("/var/log/nginx/access.log"
"/var/log/nginx/error.log"))
   (options '("storedir nginx")
--8<---cut here---end--->8---

Upon reconfiguration, I called “/gnu/store/...rottlog -v” again, and
voilà, it exits cleanly.

The current default is to only provide a weekly rotation.  Rottlog
expects a custom, daily, weekly and monthly file.  The documentation
upstream doesn't state this directly.  Providing empty files doesn't
help either, as it then errors out about syntax errors.

Would it make sense to be sure that a weekly file is enough, or all four
files are provided in a way?  The latter option sounds like slight over
engineering.  The default weekly rotation is enough for a base system.

I doubt it this is someone’s first concern to read through
/var/log/mcron.log and understand the error message on a new system.
The error message is there and it is not clear why at first sight.


Kind regards

-- 
Simon

bug#67538: Shepherd stops responding during "guix system reconfigure"

[Simon Streit]

Attila Lendvai  writes:

> i've also experienced this, and someone else on IRC also described the
> same behavior. that makes three of us.

I can confirm it too.  It looks as if shepherd hangs when something
changes.  But it doesn't happen all the time.  It also happens sometimes
when configuring a home environment.  There it is not much of a problem
to restart shepherd.

But that doesn't work on a system level.  There I have to hard reset the
system.

> i don't think it's relevant, but i'm also using syncthing.

I'm not sure about this either.  I've noticed too that the service
syncthing will sometimes hang when stopping or restarting.  This could
be a different issue with the service itself.

While thinking of it:  I don't use syncthing in my system declaration
anymore.  It move over to my home environment.  The hanging still
happens.


Regards

-- 
Simon

bug#59364: gnome clocks does not start due to missing libGLES.so

[Simon Streit]

John Kehayias  writes:

> Is this the same issue as in ? With
> potential fix ? I'm looking to
> include this on the next mesa-updates round coming up soon.

Yes, it is!  I can only confirm this error on older Machines with older
graphics cards.  The newer ones are okay.


-- 
Simon

bug#63237: Sway fails to start

[Simon Streit]

Simon Streit  writes:

> Since checkout 5bfce83dc4cddfdbb9f4bef06a26dbfe525c2838 sway at version
> 1.8 fails to start.  GDM's log says:

The previous error message is not quite right.  I still had
LIBGL_ALWAYS_SOFTWARE enabled.  The log file now has:

--8<---cut here---start->8---
libEGL warning: MESA-LOADER: failed to open crocus: 
/gnu/store/9pypr3c3y379shbwm9ilb4pik9mkfd83-mesa-22.2.4/lib/dri/crocus_dri.so: 
cannot open shared object file: No such file or directory (search paths 
/gnu/store/9pypr3c3y379shbwm9ilb4pik9mkfd83-mesa-22.2.4/lib/dri, suffix _dri)

00:00:00.029 [ERROR] [wlr] [EGL] command: eglInitialize, error: 
EGL_NOT_INITIALIZED (0x3001), message: "DRI2: failed to load driver"
libEGL warning: MESA-LOADER: failed to open crocus: 
/gnu/store/9pypr3c3y379shbwm9ilb4pik9mkfd83-mesa-22.2.4/lib/dri/crocus_dri.so: 
cannot open shared object file: No such file or directory (search paths 
/gnu/store/9pypr3c3y379shbwm9ilb4pik9mkfd83-mesa-22.2.4/lib/dri, suffix _dri)

00:00:00.032 [ERROR] [wlr] [EGL] command: eglInitialize, error: 
EGL_NOT_INITIALIZED (0x3001), message: "DRI2: failed to load driver"
00:00:00.032 [ERROR] [wlr] [EGL] command: eglInitialize, error: 
EGL_NOT_INITIALIZED (0x3001), message: "eglInitialize"
00:00:00.032 [ERROR] [wlr] [render/egl.c:264] Failed to initialize EGL
00:00:00.032 [ERROR] [wlr] [render/egl.c:554] Failed to initialize EGL context
00:00:00.032 [ERROR] [wlr] [render/gles2/renderer.c:679] Could not initialize 
EGL
00:00:00.032 [ERROR] [wlr] [render/wlr_renderer.c:333] Could not initialize 
renderer
00:00:00.032 [ERROR] [sway/server.c:79] Failed to create renderer
--8<---cut here---end--->8---

bug#63237: Sway fails to start

[Simon Streit]

Since checkout 5bfce83dc4cddfdbb9f4bef06a26dbfe525c2838 sway at version
1.8 fails to start.  GDM's log says:

--8<---cut here---start->8---
libEGL warning: Not allowed to force software rendering when API explicitly 
selects a hardware device.
libEGL warning: MESA-LOADER: failed to open crocus: 
/gnu/store/9pypr3c3y379shbwm9ilb4pik9mkfd83-mesa-22.2.4/lib/dri/crocus_dri.so: 
cannot open shared object file: No such file or directory (search paths 
/gnu/store/9pypr3c3y379shbwm9ilb4pik9mkfd83-mesa-22.2.4/lib/dri, suffix _dri)

00:00:00.029 [ERROR] [wlr] [EGL] command: eglInitialize, error: 
EGL_NOT_INITIALIZED (0x3001), message: "DRI2: failed to load driver"
00:00:00.029 [ERROR] [wlr] [EGL] command: eglInitialize, error: 
EGL_NOT_INITIALIZED (0x3001), message: "eglInitialize"
00:00:00.029 [ERROR] [wlr] [render/egl.c:264] Failed to initialize EGL
00:00:00.029 [ERROR] [wlr] [render/egl.c:554] Failed to initialize EGL context
00:00:00.029 [ERROR] [wlr] [render/gles2/renderer.c:679] Could not initialize 
EGL
00:00:00.029 [ERROR] [wlr] [render/wlr_renderer.c:333] Could not initialize 
renderer
00:00:00.029 [ERROR] [sway/server.c:79] Failed to create renderer
--8<---cut here---end--->8---

Anyone else run into this yet?


Kind regards
Simon

bug#61080: guile-static 3.0.9 failed to build.

[Simon Streit]

Hilton Chain via Bug reports for GNU Guix  writes:

> Logs after unpack phase:

Can confirm.  Build is currently failing.


Kind regards
Simon 

bug#59364: gnome clocks does not start due to missing libGLES.so

[Simon Streit]

Csepp  writes:
> It does work with LIBGL_ALWAYS_SOFTWARE=1, but it would be pretty messed
> up if that had to be enabled globally.

Thanks for that tip! 

I fired up a recent Fedora live image to see that these applications do
work in wayland on this old machine.  Which they do. 

Gnome in Ferdora is already at 43.  

bug#59364: gnome clocks does not start due to missing libGLES.so

[Simon Streit]

Hello,

Csepp  writes:

> This is the exact error:
> Couldn't open libGLESv2.so.2: libGLESv2.so.2: cannot open shared object file: 
> No such file or directory

I can confirm this error, though it only happens in wayland enabled
sessions on my old laptop with an Intel GM965/GL960.  This doesn't
happen on machines with modern graphics cards installed.

The list is longer for me on Gnome applications that will fail to start:

gnome-calculator, gnome-calendar, gnome-characters, gnome-clocks
gnome-contacts, gnome-font-viewer, etc.

Checkout is at 8f9588185d74f1f251b041b84d43302c337588ff.

bug#55336: Graphical installer: Selecting a partition scheme always takes me back to the start

[Simon Streit]

Simon Streit  writes:
>> I noticed this behaviour happens when placing a hyphon inbetween two
>> words in the hostname.  The installer doesn't reset when there is no
>> hyphen.  I will try to complete the installation to confirm that it
>> usually works without the hyphen.  I'm still at
>> axygxkgkgcgbk2gjd6q521h85shp7hwf-image.iso.
>
> That claim doesn't seem right either.  Only after rebooting the machine
> and setting `guix' as hostname doesn't reset the installer.
>
> Will report back.

The installer went through with setting the hostname to guix. 

bug#55336: Graphical installer: Selecting a partition scheme always takes me back to the start

[Simon Streit]

Simon Streit  writes:

> Mathieu Othacehe  writes:
>
>>> Disk image is: axygxkgkgcgbk2gjd6q521h85shp7hwf-image.iso from
>>> https://ci.guix.gnu.org/build/125952/details.
>>>
>>> Please find attached some logs too:
>>
>> It looks like you experimented a crash (segfault or so), and the
>> backtrace is not really helpful here sadly.
>
> Please visit the core dump online at [1] for a while.
>
> I noticed this behaviour happens when placing a hyphon inbetween two
> words in the hostname.  The installer doesn't reset when there is no
> hyphen.  I will try to complete the installation to confirm that it
> usually works without the hyphen.  I'm still at
> axygxkgkgcgbk2gjd6q521h85shp7hwf-image.iso.

That claim doesn't seem right either.  Only after rebooting the machine
and setting `guix' as hostname doesn't reset the installer.

Will report back. 

bug#55336: Graphical installer: Selecting a partition scheme always takes me back to the start

[Simon Streit]

Mathieu Othacehe  writes:

>> Disk image is: axygxkgkgcgbk2gjd6q521h85shp7hwf-image.iso from
>> https://ci.guix.gnu.org/build/125952/details.
>>
>> Please find attached some logs too:
>
> It looks like you experimented a crash (segfault or so), and the
> backtrace is not really helpful here sadly.

Please visit the core dump online at [1] for a while.

I noticed this behaviour happens when placing a hyphon inbetween two
words in the hostname.  The installer doesn't reset when there is no
hyphen.  I will try to complete the installation to confirm that it
usually works without the hyphen.  I'm still at
axygxkgkgcgbk2gjd6q521h85shp7hwf-image.iso.

[1] https://steel-is-real.com/core-dump

bug#55336: Graphical installer: Selecting a partition scheme always takes me back to the start

[Simon Streit]

Hello,

Luis Felipe via Bug reports for GNU Guix  writes:

> Problem solved.

I just ran into this same problem with an old machine.

Disk image is: axygxkgkgcgbk2gjd6q521h85shp7hwf-image.iso from
https://ci.guix.gnu.org/build/125952/details. 

Please find attached some logs too: 



installer-backtrace
Description: Binary data


installer-result
Description: Binary data


Kind regards
Simon 

bug#55200: Guix offload fails to allow connections while attempting to connect with the host's hostname or FQDN

[Simon Streit]

This issue is related to [1] which was resolved.  Pulling to a current
checkout solves this issue. 

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55335

bug#55335: openssh-service no longer listens on IPv6

[Simon Streit]

Ludovic Courtès  writes:

> Let me know if anything’s amiss!

Looking all good.  v4 and v6 connections are working now.

bug#55200: Guix offload fails to allow connections while attempting to connect with the host's hostname or FQDN

[Simon Streit]

Just a quick follow up to correct the title.  I noticed that my wording
is wrong:

Simon Streit  writes:
> After a bit of bisecting I pinned my issue down to checkout
> 808b9e850491c7b1d867a5f1f4d5ee6f61f345d4.  From there on any guix
> offload test or status will fail if a hostname, or FQDN, is set in the
> name field of a machine.  Offloads work if an IP address is set
> instead.

Any connection fails if I try to offload to a host with its hostname or
FQDN.  Connections to an IP addresse do not fail.

I was wondering if there are more debugging options to look into
offloading?  Changing log-level to 'debug in openssh didn't help.

bug#55200: Guix offload fails to resolve hostnames

[Simon Streit]

Hello!

After a bit of bisecting I pinned my issue down to checkout
808b9e850491c7b1d867a5f1f4d5ee6f61f345d4.  From there on any guix
offload test or status will fail if a hostname, or FQDN, is set in the
name field of a machine.  Offloads work if an IP address is set
instead.

A snip:
--8<---cut here---start->8---
$ guix offload status machines.scm testhost
guix offload: getting status of 1 build machines defined in 'machines.scm'...
guix offload: error: failed to connect to 'testhost': Connection refused
--8<---cut here---end--->8---

It would be great if someone could confirm this somehow.  I've observed
this on a different host and finally got to test it on my main host
today.  Testing in a Qemu through libvirt the error behaved a bit
differently with a different error.  But I didn't follow that track
after all.  I mostly do offloading onto bare metal.


Kind regards
Simon

bug#54109: Document package variable in virtlogd service

[Simon Streit]

Hello!

I would like to suggest a little extension in the manual.

I noticed that the package variable for virtlogd service is not
documented.  It is possible to define the package as (libvirt libvirt)
for said service.  While it is closely related to libvirt-service-type,
the package variable may still be independently modified.

This only became clear after using inferiors in libvirt-service-type for
some time now.  New Qemu packages would still be pulled in after
reconfiguring with new checkouts.  Unfortunately Qemu's packages take a
lot of space, which is why I've pinned it to a fixed version.

Thus I think this should be included into the manual.

>From 634dae4017e840f24e8ed2240707602700e9cf25 Mon Sep 17 00:00:00 2001
From: Simon Streit 
Date: Tue, 22 Feb 2022 16:23:38 +0100
Subject: [PATCH] doc: Add documentation.

* doc/guix.texi (Virtualization Services): Document virtlogd package
variable.
---
 doc/guix.texi | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index a4145af7fd..528760d7f6 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -30888,6 +30888,10 @@ Its value must be a @code{virtlog-configuration}.
 @end lisp
 @end deffn
 
+@deftypevar {@code{libvirt} parameter} package libvirt
+Libvirt package.
+@end deftypevar
+
 @deftypevr {@code{virtlog-configuration} parameter} integer log-level
 Logging level.  4 errors, 3 warnings, 2 information, 1 debug.
 
-- 
2.34.0



Kind regards
Simon

bug#53695: trash-cli crashes

[Simon Streit]

Brice Waegeneire  writes:

> I'm the one who updated trash-cli¹; sorry to have broken it for you.
> Unfortunalty, I can't manage to reproduce it on my side:

Thank you for upgrading it.  My current solution is to keep an old
version around.  So it is not much of a problem really.

> Is it still broken on your side?  Are you on a foreign distro?  Can you share
> other relevant information to find in which condition the package
> break ?

It still is.  My system is at 47eb897bd377f87854335a6d0cc711b94cb8589e.
I just put it into my system declaration again to see if it works, and
that it is not my user profiles breaking them.

It still exits with the same error, and unfortunately I can't provide
more as in to why it is failing.  I can also rebuild the package without
a problem.

I also have a vanilla Guix running in a VM with only a minimum of
packages and no extra config.  I just pulled it into either the system,
or my user profile.  None work.


Kind regards
Simon

bug#53695: trash-cli crashes

[Simon Streit]

With trash-cli's last update, it doesn't work any more and exits with
the following error:

--8<---cut here---start->8---
Traceback (most recent call last):
  File "/home/ss2/.guix-profile/bin/trash-list", line 4, in 
from trashcli.list import main as main
ModuleNotFoundError: No module named 'trashcli'
--8<---cut here---end--->8---

I've tried to come up with a solution, but none work so far.


Kind regards
Simon

bug#53668: Updating substitutes on LAN hosts dies unexpectedly

[Simon Streit]

Simon Streit  writes:
> I just activated the cache. It hasn't crashed so far.

No, it did crash again.

bug#53668: Updating substitutes on LAN hosts dies unexpectedly

[Simon Streit]

Hello Guillaume,

Guillaume Le Vaillant  writes:

> I have also seen this kind of crashes on my LAN.
> I don't know what causes this issue, but I noticed that it has happened
> less often since I activated the cache for the guix-publish service.

I just activated the cache. It hasn't crashed so far.

bug#53668: Updating substitutes on LAN hosts dies unexpectedly

[Simon Streit]

Hello,

quite often, and quite randomly I run into this situation that whenever
Guix tries to rebuild a profile, and sometimes while downloading from
local Guix hosts sharing their store items, the process will crash with
the following error:

--8<---cut here---start->8---
~ $1 reconfigure
substitute: updating substitutes from 'http://192.168.0.157:3000'...  
56.3%Backtrace:
substitute: In ice-9/boot-9.scm:
substitute:   1752:10 17 (with-exception-handler _ _ #:unwind? _ # _)
substitute: In unknown file:
substitute:   16 (apply-smob/0 #)
substitute: In ice-9/boot-9.scm:
substitute: 724:2 15 (call-with-prompt _ _ #)
substitute: In ice-9/eval.scm:
substitute: 619:8 14 (_ #(#(#)))
substitute: In guix/ui.scm:
substitute:2206:7 13 (run-guix . _)
substitute:   2169:10 12 (run-guix-command _ . _)
substitute: In ice-9/boot-9.scm:
substitute:   1752:10 11 (with-exception-handler _ _ #:unwind? _ # _)
substitute:   1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
substitute: In guix/scripts/substitute.scm:
substitute:757:18  9 (_)
substitute:348:26  8 (process-query # _ #:cache-urls _ 
#:acl _)
substitute: In guix/substitutes.scm:
substitute:365:27  7 (lookup-narinfos/diverse _ _ # …)
substitute:322:31  6 (lookup-narinfos _ _ #:open-connection _ # _)
substitute:245:26  5 (fetch-narinfos _ _ #:open-connection _ # _)
substitute: In ice-9/boot-9.scm:
substitute:   1685:16  4 (raise-exception _ #:continuable? _)
substitute:   1685:16  3 (raise-exception _ #:continuable? _)
substitute:   1780:13  2 (_ #<&compound-exception components: 
(#<&assertion-fail…>)
substitute:   1685:16  1 (raise-exception _ #:continuable? _)
substitute:   1685:16  0 (raise-exception _ #:continuable? _)
substitute:
substitute: ice-9/boot-9.scm:1685:16: In procedure raise-exception:
substitute: Wrong type (expecting exact integer): #f
guix system: error: 
`/gnu/store/kcc8zh1fhp05wgw2m48w3gk228j39f5q-guix-1.3.0-21.e427593/bin/guix 
substitute' died unexpectedly
--8<---cut here---end--->8---

Unfortunately this crash happens at random.  Other times it goes
through.  Current checkout is ff14bc60e56fb0c6636da1da9a850b7b04abb367,
which isn't the most current, I know.  I've been observing this behavior
since some time now, and haven't figured out what the reason is behind
it yet.  The error message looks similar to [1].

The way this error appears is, that I usually have one host that I
upgrade first, and then share the checkout and the store between hosts
to speed up the upgrading process locally.  Unfortunately the updater
will crash randomly whenever the host starts scanning other hosts that
are found through mDNS.  Sometimes this happens while fetching new
packages into a profile.

I've set up publishing:

--8<---cut here---start->8---
(service guix-publish-service-type
  (guix-publish-configuration (host "0.0.0.0")
  (port 3000)
  (ttl #f)
  (advertise? #t)))
--8<---cut here---end--->8---

and of course host discovery in guix-service-type too.


Kind regards
Simon


[1] https://issues.guix.gnu.org/52464

bug#52976: Some tools in Samba fail to find modules, and a missing dependency

[Simon Streit]

Simon Streit  writes:
> compiles to a package.  But ‘samba-tools’ fails again.

Just a quick follow up, samba-tools fails with ldb being missing:
--8<---cut here---start->8---
ModuleNotFoundError: No module named 'ldb'
--8<---cut here---end--->8---

I put ldb into inputs, and wrapped it as well.  That didn't help.


Kind regards
Simon

bug#52976: Some tools in Samba fail to find modules, and a missing dependency

[Simon Streit]

Hello Maxim,

thanks for having look at my patch. 

Maxim Cournoyer  writes:

> We shouldn't hard code Python versions in the paths as it'd be too prone
> to break.  You could probably make good use of the recently introduced
> search-input-directory procedure here :-).

I tried your suggestion, but unfortunately my attempt with modifying
the lines to as such:
--8<---cut here---start->8---
(talloc (string-append
  (search-input-directory inputs
  "/lib/python3.9/site-packages")))
(tdb (string-append
   (search-input-directory inputs
   "/lib/python3.9/site-packages")))
(python-dnspython (string-append
(search-input-directory inputs
"/lib/python3.9/site-packages")))
--8<---cut here---end--->8---
compiles to a package.  But ‘samba-tools’ fails again.

It is not quite clear to me now why this method is better?  Is hard
coding being avoid now?  Should I avoid the ‘3.9’ in the search path?
Sorry that I have to ask for an explanation.

And while we are at it.  I noticed that you have already replaced
heimdal with mit-krb5, which I had done personally already without
proposing it yet.  Thanks for that.

Point is that I was trying to pull up an AD DC, which is why I run these
problems.

And then, can I ask you to add avahi to inputs?  Since some time Samba
has disabled SMBv1, which means host discovery with NetBIOS doesn’t work
any more.  Now it is best to have Avahi running alongside Samba hosts,
so that Samba can publish it’s service over multicast.  No extra
configuration is needed for this. 

This doesn’t help much for Windows hosts though.  I’ve already packaged
wsdd [1], and have prepared a service, which I haven’t made public
either yet.  I haven’t completed the documentation for info so far.
Should really finish it now.

I will open another issue for this later, and will not hijack this
thread for it.


Kind regards
Simon


[1] https://github.com/christgau/wsdd

bug#47030: blueman fails to find a dbus service file

[Simon Streit]

Grigory Shepelev  writes:

> Installed guix a few weeks ago on my desktop PC and just yesterday on
> my laptop (thinkpad L13). Having the same problem on both of them.
>
> Gnome's default bluetooth "app" doesn't work. 
>
> After having the same config as in your example I can launch
> blueman-manager and connect to my bluetooth sound system. It makes a
> sound as if it's connected and displays itself as connected but I
> can't pick it as an output device in gnome's setting "sound" tab.
>
> How have you dealt with this?

I eventually solved my problem by adding
--8<---cut here---start->8---
(simple-service 'dbus-extras
dbus-root-service-type
(list blueman))
--8<---cut here---end--->8---
to service list, and loading
--8<---cut here---start->8---
(gnu packages networking)
--8<---cut here---end--->8---
to load blueman in the declaration.

Will close this bug report since it is not deemed to be one.


Kind regards
Simon 

bug#52976: Some tools in Samba fail to find modules, and a missing dependency

[Simon Streit]

While experimenting with Samba, I noticed that some tools, especially
samba-tools will not run, and crash:
--8<---cut here---start->8---
root@motor ~# samba-tool
Traceback (most recent call last):
  File "/run/current-system/profile/bin/samba-tool", line 33, in 
from samba.netcmd.main import cmd_sambatool
  File 
"/gnu/store/78baaab8085rd5xnfrpdkxdf07zkmin9-samba-mod-4.13.14/lib/python3.9/site-packages/samba/__init__.py",
 line 29, in 
import samba.param
ModuleNotFoundError: No module named 'talloc'
--8<---cut here---end--->8---

Doing more testing, other tools appear to not find the libraries they
need too.  The combination is as folows:
 - samba-tool, fails when tdb missing.
 - samba-gpupdate Idem.
 - samba_dnsupdate requires dnspython, but fails when talloc missing.
 - samba_downgrade_db" fails when tdb missing.
 - samba_kcc Idem.
 - samba_spnupdate" Idem.
 - samba_upgradedns" dns not found when talloc missing.

I prepared a small patch to wrap up the inputs appropriately.  I hope it
is acceptable that they are all combined in one wrap procedure.

dnspython was added as a new input too.


Kind regards
Simon

>From 201dc8e01fa4484e24b3e088ab6a4211e9839f33 Mon Sep 17 00:00:00 2001
From: Simon Streit 
Date: Mon, 3 Jan 2022 13:08:23 +0100
Subject: [PATCH] gnu: samba: Use PYTHONPATH.

* gnu/packages/samba.scm (samba): Use PYTHONPATH in 'wrap-program phase..
---
 gnu/packages/samba.scm | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/samba.scm b/gnu/packages/samba.scm
index bb5b402eee..33a39eb3be 100644
--- a/gnu/packages/samba.scm
+++ b/gnu/packages/samba.scm
@@ -235,7 +235,30 @@ (define-public samba
(lambda _
  (substitute* "dynconfig/wscript"
(("bld\\.INSTALL_DIR.*") ""))
- #t)))
+ #t))
+ (add-after 'install 'wrap-program
+   ;; Some samba tools selectively fail to find talloc, tdb
+   ;; and dnspython.
+   (lambda* (#:key inputs outputs #:allow-other-keys)
+ (let ((out (string-append (assoc-ref outputs "out")))
+   (talloc (string-append (assoc-ref inputs "talloc")
+  "/lib/python3.9/site-packages"))
+   (tdb (string-append (assoc-ref inputs "tdb")
+   "/lib/python3.9/site-packages"))
+   (python-dnspython (string-append
+  (assoc-ref inputs "python-dnspython")
+  "/lib/python3.9/site-packages")))
+   (for-each
+(lambda (bin)
+  (wrap-program (string-append out bin)
+`("PYTHONPATH" prefix (,talloc ,tdb ,python-dnspython
+'("/bin/samba-tool"
+  "/sbin/samba-gpupdate"
+  "/sbin/samba_dnsupdate"
+  "/sbin/samba_downgrade_db"
+  "/sbin/samba_kcc"
+  "/sbin/samba_spnupdate"
+  "/sbin/samba_upgradedns"))
;; FIXME: The test suite seemingly hangs after failing to provision the
;; test environment.
#:tests? #f))
@@ -258,7 +281,8 @@ (define-public samba
python
popt
readline
-   tdb))
+   tdb
+   python-dnspython))
 (propagated-inputs
  ;; In Requires or Requires.private of pkg-config files.
  (list ldb talloc tevent))
-- 
2.34.0

bug#51259: Cannot build Guix from source (error messages about the translations)

[Simon Streit]

Simon Streit  writes:
> Leo Famulari  writes:
>
>> I noticed today that I can't build Guix from a fresh Git checkout in the
>> usual manner. Something goes wrong while building the Korean language
>> info manual. I tested it several times and on two different computers,
>> both x86_64.
>
> Can confirm that I can't build on a fresh Guix or on another machine.
>
> I just had a look into the file guix.ko.texi.  Unfortunately the file
> itself is indeed full of question marks:
>
> @menu
> *  ??::  Guix ?? !
> * :: Guix???  ??? ? 
>???.
> * ? ? ::  Guix .
> * ?? ::  ?? ? ?? .
> * guix-?? ::  ?? ?? .
> * ?? ??::  ??-?? ??.
> * Guix ::Guix ? ?? .
> @end menu

Extending my previous message:

I first thought that it had to do with commit
15c91189cb61c579f4289047c79530cefe75215f, but it turns out that commit
0623138ffa5b066afc25547ffdeb97753cb0ee9a creates these errors.

Commit d1b375402f5680b1e5a77dd1fb77e1e9d94625d1 is okay.


Kind regards
Simon

bug#51259: Cannot build Guix from source (error messages about the translations)

[Simon Streit]

Hello,

Leo Famulari  writes:

> I noticed today that I can't build Guix from a fresh Git checkout in the
> usual manner. Something goes wrong while building the Korean language
> info manual. I tested it several times and on two different computers,
> both x86_64.

Can confirm that I can't build on a fresh Guix or on another machine.

I just had a look into the file guix.ko.texi.  Unfortunately the file
itself is indeed full of question marks:
--8<---cut here---start->8---
@menu
*  ??::  Guix ?? !
* :: Guix???  ??? ? 
   ???.
* ? ? ::  Guix .
* ?? ::  ?? ? ?? .
* guix-?? ::  ?? ?? .
* ?? ??::  ??-?? ??.
* Guix ::Guix ? ?? .
@end menu
--8<---cut here---end--->8---

Chances are something wrong?


Kind regards,
Simon

bug#50705: emacs-guix fails to list packages

[Simon Streit]

Hello Ludo,

Ludovic Courtès  writes:
> Could it be that something else is interfering, in your ~/.emacs, Guile
> load path or something?

Yes, it turned out that certain profiles where not all upgraded after
pulling to a current checkout.

Sorry about the inconveniance.


Kind regards
Simon

bug#50705: emacs-guix fails to list packages

[Simon Streit]

Hello,

I just pulled Guix up to 6eded1a04186e3118b293486b038c994e05efedf, and
unfortunately emacs-guix fails to list any installed packages of a given
profile.

Part of the output from it's internal REPL follows as such:
--8<---cut here---start->8---
  14 (eval (#:21:16 ()>) 
#)
In emacs-guix/packages.scm:
   777:23 13 (package/output-sexps _ output _ _ (synopsis installed output 
version name id package-id known-status # #))
In srfi/srfi-1.scm:
   460:18 12 (fold # _ (#< name: …> …))
In emacs-guix/packages.scm:
359:2 11 (_ #< name: "syncthing-gtk" version: 
"0.9.4.4-1.c46fbd8" output: "out" item: "/gnu/store/w4…> …)
   351:22 10 (packages-by-name _ _ _)
   281:48  9 (_ _ _)
In unknown file:
   8 (force #>)
In gnu/packages.scm:
   239:33  7 (fold-packages # # _ # #)
In guix/discovery.scm:
   153:11  6 (all-modules _ #:warn _)
In srfi/srfi-1.scm:
   460:18  5 (fold # _ (("/home/ss2/.config/guix/…" . #)))
In guix/discovery.scm:
   143:19  4 (_ _ ())
In srfi/srfi-1.scm:
   691:23  3 (filter-map # _ . _)
In guix/discovery.scm:
   118:22  2 (_ . _)
In guix/ui.scm:
324:2  1 (report-unbound-variable-error _ #:frame _)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)
--8<---cut here---end--->8---

But if I where to remove this package “syncthing-gtk”, the error would
move on to the next package.

Then I rolled back to commit 337b7f5a13b8fd8b5ee320fd5a850ede1ad63b6d,
wich is a commit before 7bae88b5b9dcacad4dcd11b353b486dc2f8a78e2, where
a new checkout of guix was added to the packages tree.  Unfortunately
the error changes over to:
--8<---cut here---start->8---
   2 (eval (#:19:16 ()>) 
#)
In current input:
19:17  1 (_)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)
--8<---cut here---end--->8---

Hope this is only a small error.


Kind regards
Simon

bug#50212: Several tests fail, Bash fails often. Was: Tests fail while building Guix

[Simon Streit]

Maxim Cournoyer  writes:
> I'm guessing the i386 does something bogus?  Your x86_64 is already able
> to run i386 code natively, AFAIK.

Alright, this was my interpretation from the manual and available
architectures that I just plugged it all together like that.  I wasn't
aware that x86_64 can run i386 natively.

> The binfmt service type registers binary formats of non-native
> architectures with interpreters to run them [0]; this way, when an ARM
> binary is encountered on a x86_64 system, the kernel Linux knows to
> launch it via QEMU, for example.  Since commit
> 77c2f4e2068ebec3f384c826c5a99785125ff72c, this is in effect for any
> container (it used to be possible to enable it with (guix-support? #t)
> on only for the container spawned by guix-daemon.

I reenabled the service without it mentioning i386.  Building Guix
passes as expected.  Thank you.


Kind regards,
Simon

bug#50212: Several tests fail, Bash fails often. Was: Tests fail while building Guix

[Simon Streit]

Simon Streit  writes:
> So why would my system brake the bootstrap binary?  Has it got to do
> with a particular package I have in my profile(s)?  I generally build
> Guix with ‘guix environment --pure guix.’  I have a second Guix build
> machine running.  The packages used there are quite similar, so these
> two machines have very similar checkouts and config in general.  Hence,
> when I build Guix there, the same error occurs.

I figured out why this is happening.  I disabled
--8<---cut here---start->8---
(service qemu-binfmt-service-type
 (qemu-binfmt-configuration
  (platforms (lookup-qemu-platforms "arm" "aarch64" "i386"
--8<---cut here---end--->8---
and now all tests pass.

Why would this be a problem?  


Simon

bug#50212: Several tests fail, Bash fails often. Was: Tests fail while building Guix

[Simon Streit]

Hello Maxime,

Maxime Devos  writes:
> Some questions:
>
> * What's the hash of gnu/packages/bootstrap/i686-linux/bash?
>
>   (Run guix hash gnu/packages/bootstrap/i686-linux/bash)
>
>   I have 1ig8a4bhc7fpw8zrnw4l568wmmcb29rlwg4jbih3imb4x6d9l1gd.
>   If you see something different, your copy is probably corrupt.

The hash is: 1ig8a4bhc7fpw8zrnw4l568wmmcb29rlwg4jbih3imb4x6d9l1gd

> * What does ‘objdump -a gnu/packages/bootstrap/i686-linux/bash’ output?
>   On my x86_64 system, it outputs ‘[...] file format elf32-i386’.

Result is:
--8<---cut here---start->8---
./bash: file format elf32-i386
--8<---cut here---end--->8---

> * What architecture are you on?

And: x86_64-linux system.

I just updated my system to a8dd285d5a0670abf124a721e6ba94da045b24ba and
am building 76114232d7c140fb9fee84510b72fcfe6ee27714, which failed again.

Early on I installed Guix into a VM, and built the sources in there
on a pretty much default config from the installer.  All tests passed.

Just to be sure I did another clean clone on my main machine, which
failed again.

So why would my system brake the bootstrap binary?  Has it got to do
with a particular package I have in my profile(s)?  I generally build
Guix with ‘guix environment --pure guix.’  I have a second Guix build
machine running.  The packages used there are quite similar, so these
two machines have very similar checkouts and config in general.  Hence,
when I build Guix there, the same error occurs.


Simon

bug#50212: Several tests fail, Bash fails often. Was: Tests fail while building Guix

[Simon Streit]

Hey Mark,

Mark H Weaver  writes:
> Also check the permissions of gnu/packages/bootstrap/i686-linux/bash.
> It should be 0555, i.e. "-r-xr-xr-x", and ditto for 'mkdir' in the same
> directory.  I vaguely recall someone running into a similar problem many
> years ago because the executable bit was missing in their bootstrap
> files, even though the files had the correct contents.  The executable
> bit is effectively included in the hash computation when the file is
> imported to the store, although "guix hash" disregards it when applied
> to a single file.

Contents of bootstrap are as follows:
--8<---cut here---start->8---
  /home/ss2/code/guix/gnu/packages/bootstrap/i686-linux:
  total used in directory 4.1M available 340.5 GiB
  drwxr-xr-x 3 ss2 users 4.0K Aug 28 23:55 .
  drwxr-xr-x 3 ss2 users 4.0K Apr 19 22:13 ..
  -r-xr-xr-x 1 ss2 users 1.3M Mar  7 23:53 bash
  -r-xr-xr-x 1 ss2 users 698K Mar  7 23:54 mkdir
  -r-xr-xr-x 1 ss2 users 1.3M Mar  7 23:57 tar
  -r-xr-xr-x 1 ss2 users 842K Mar  7 23:57 xz
--8<---cut here---end--->8---

Simon

bug#50212: Tests fail while building Guix

[Simon Streit]

Tobias Geerinckx-Rice  writes:

> On 2021-08-26 20:07, Simon Streit wrote:
>> /home/ss2/code/guix/test-tmp/store/9m9mjdz3zl28n1dq094aqsxk5d480mvg-bash:
>> 9m9mjdz3zl28n1dq094aqsxk5d480mvg-bash: No such file or directory
>> But this executable is there though.
>
> Does it run when invoked manually?

Good question!  Should have thought about this before early on.  No, it
doesn't.

bug#50212: Tests fail while building Guix

[Simon Streit]

Hello,

since my first submission of this bug report was rejected -- the
attachments where too big --, this report I will simply repost so that
it can be delivered through mailman while the original post remains only
accessible through the web interface.

Here the original post:

Simon Streit  writes:
> Hello,
>
> after a time off, I just recently began pulling the latest commits and
> have been trying to build Guix since maybe a week.  But several tests
> fail.  Even a clean clone fails.
>
> I've only a handful of logs.  It seams that the tests fail mostly for
> this reason:
>
> /home/ss2/code/guix/test-tmp/store/9m9mjdz3zl28n1dq094aqsxk5d480mvg-bash: 
> 9m9mjdz3zl28n1dq094aqsxk5d480mvg-bash: No such file or directory
>
> But this executable is there though.

The original logs have been compressed, which should make them now small
enough to let them through the mailer.



challenge.log.gz
Description: Binary data


derivations.log.gz
Description: Binary data


gexp.log.gz
Description: Binary data


grafts.log.gz
Description: Binary data


graph.log.gz
Description: Binary data


packages.log.gz
Description: Binary data


profiles.log.gz
Description: Binary data


store.log.gz
Description: Binary data

bug#48496: Guix reconfigure fails to switch to new system

[Simon Streit]

Hello, just another follow up:

Simon Streit  writes:
> I just managed to reproduce this very same error message after
> downgrading to commit a67c00f4f7ee0a70fce14a7e1907cce332c85813 (I lost
> the previous system a couple of days ago), and it threw this error after
> trying to reconfigure.  Given that it is complaining about srfi-1, I
> disabled everything that was relevant to it, and it still fails.

I just did another test on another machine with this commit, and I
noticed, that despite that this error message happens, the system
generation is still put up:

--8<---cut here---start->8---
Generation 46   Jun 01 2021 18:55:05(current)
  file name: /var/guix/profiles/system-46-link
  canonical file name: /gnu/store/6nrj5zd9zar1n332f2s4wqpxm4rsjb4x-system
  label: GNU with Linux-Libre 5.11.21
  bootloader: grub-efi
  root device: UUID: *snip*
  kernel: 
/gnu/store/53r3pzj18jshhkvm2ggiiy6gxqx5y2cr-linux-libre-5.11.21/bzImage
  channels:
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  commit: a67c00f4f7ee0a70fce14a7e1907cce332c85813
  configuration file: 
/gnu/store/wysjis8dnwrvkdmrcw234mm3fy5l9a1k-configuration.scm
--8<---cut here---end--->8---

Will try to reboot into this generation later.


Greetings
Simon

bug#48496: Guix reconfigure fails to switch to new system

[Simon Streit]

Ludovic Courtès  writes:

> Hi Simon & Tobias,
>
> Ludovic Courtès  skribis:
>
>> Tobias Geerinckx-Rice  skribis:
>>
>>> Simon Streit 写道：
>>>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>>>> no code for module (system repl error-handling)
>>>
>>> Thank you for reporting this.  With commit
>>> 5fa46ca96da90ec19e32cc4d726f099d0979d60b on master, the system
>>> tests that failed for me with this error no longer do.
>>
>> What system tests were failing?
>>
>> At first sight I don’t see how a67c00f4f7ee0a70fce14a7e1907cce332c85813
>> led to this:
>>
>> activating system...
>> Backtrace:
>> In ice-9/boot-9.scm:
>>   3422:24 19 (_)
>>222:29 18 (map1 (((gnu system accounts)) ((gnu build accounts)) …))
>>222:29 17 (map1 (((gnu build accounts)) ((gnu build #)) ((# …)) …))
>>222:17 16 (map1 (((gnu build linux-boot)) ((guix build utils)) # …))
>>   3326:17 15 (resolve-interface (gnu build linux-boot) #:select _ # _ …)
>> In ice-9/threads.scm:
>> 390:8 14 (_ _)
>> In ice-9/boot-9.scm:
>>   3252:13 13 (_)
>> In ice-9/threads.scm:
>> 390:8 12 (_ _)
>> In ice-9/boot-9.scm:
>>   3536:20 11 (_)
>>2835:4 10 (save-module-excursion #)
>>   3556:26  9 (_)
>> In unknown file:
>>8 (primitive-load-path "gnu/build/linux-boot" #)
>> In gnu/build/linux-boot.scm:
>>  22:0  7 (_)
>> In ice-9/boot-9.scm:
>>3409:4  6 (define-module* _ #:filename _ #:pure _ #:version _ # _ …)
>>   3422:24  5 (_)
>>222:29  4 (map1 (((rnrs io ports)) ((system repl #)) ((srfi #)) …))
>>222:17  3 (map1 (((system repl error-handling)) ((srfi srfi-1)) …))
>>3329:6  2 (resolve-interface (system repl error-handling) #:select …)
>>   1685:16  1 (raise-exception _ #:continuable? _)
>>   1685:16  0 (raise-exception _ #:continuable? _)
>>
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> no code for module (system repl error-handling)
>
> I’ve tried several system tests and manually running a system in a VM,
> with a67c00f4f7ee0a70fce14a7e1907cce332c85813 reinstated, and cannot
> reproduce the issue.
>
> Do you know of a way to reproduce it?

I just managed to reproduce this very same error message after
downgrading to commit a67c00f4f7ee0a70fce14a7e1907cce332c85813 (I lost
the previous system a couple of days ago), and it threw this error after
trying to reconfigure.  Given that it is complaining about srfi-1, I
disabled everything that was relevant to it, and it still fails.
>
> The IRC log <https://logs.guix.gnu.org/guix/2021-05-18.log> suggests
> that a couple of people experienced the issue on that day, but pastes
> are no longer accessible.

Just to be sure I'll paste my error message again: 
--8<---cut here---start->8---
~ $ sudo guix system reconfigure --allow-downgrades
guix system: warning: rolling back channel 'guix' from 
b7664dfb780336114c229683b87d3564e9a72268 to 
a67c00f4f7ee0a70fce14a7e1907cce332c85813
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
   /gnu/store/asgn7g5mj2lwm0699hvlwwvjs19rfw2z-system.drv
   /gnu/store/2lx0dck2pm65hgp02s1ldcx8nhlmph00-provenance.drv
   /gnu/store/5jz1m453prfb9g8m1klgdqb6nsigpx7c-profile.drv
   /gnu/store/g14nbwf930yiajyg6pvkwzyw533rvdrw-grub.cfg.drv

building /gnu/store/2lx0dck2pm65hgp02s1ldcx8nhlmph00-provenance.drv...
building CA certificate bundle...
listing Emacs sub-directories...
building fonts directory...
generating GLib schema cache...
creating GTK+ icon theme cache...
building cache files for GTK+ input methods...
building directory of Info manuals...
building database for manual pages...
building XDG desktop file cache...
building XDG MIME database...
building profile with 98 packages...
building /gnu/store/asgn7g5mj2lwm0699hvlwwvjs19rfw2z-system.drv...
building /gnu/store/g14nbwf930yiajyg6pvkwzyw533rvdrw-grub.cfg.drv...
/gnu/store/yrbsyghfckd1319khs36iwhrcmpdjzs4-system
/gnu/store/9vcl1in6398kkq3hcra6kyivpq476gag-grub.cfg

activating system...
The following derivation will be built:
   /gnu/store/16fk787qz7dbgillrrc1kh64ax82fdfc-switch-to-system.scm.drv

building /gnu/store/16fk787qz7dbgillrrc1kh64ax82fdfc-switch-to-system.scm.drv...
Backtrace:
In ice-9/boot-9.scm:
  3422:24 19 (_)
   222:29 18 (map1 (((gnu system accounts)) ((gnu build accounts)) …))
   222:29 17 (map1 (((gnu build accounts)) ((gnu build #)) ((# …)) …))
   222:17 16 (map1 (((gnu build linux-boot)) ((guix build utils)) # …))
  3326:17 15 (resolve-interface (gnu build linux-boot) #:select _ # _ …)
In ice-9/threads.scm:
390:8 14 (_ _)
In ice-9/boot-9.

bug#48496: Guix reconfigure fails to switch to new system

[Simon Streit]

Hi Tobias,

Tobias Geerinckx-Rice  writes:
> Simon Streit 写道：
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> no code for module (system repl error-handling)
>
> Thank you for reporting this.  With commit
> 5fa46ca96da90ec19e32cc4d726f099d0979d60b on master, the system
> tests that failed for me with this error no longer do.
>
> Could you confirm?

Yes, this commit runs through.


Cheers
Simon

bug#48496: Guix reconfigure fails to switch to new system

[Simon Streit]

Hi,

after pulling and trying to upgrade a system, Guix will fail switching
to a new system saying:

--8<---cut here---start->8---
The following derivation will be built:
   /gnu/store/hswsg23l03pyrf7nckr1zrmb0rfsssf6-grub.cfg.drv

building /gnu/store/hswsg23l03pyrf7nckr1zrmb0rfsssf6-grub.cfg.drv...
/gnu/store/3zpjx9ky5lyx3l90qvnp1qqrvrc70caf-system
/gnu/store/lrvf3k1qrs3mrb3aasq9b6i6gd321aiz-grub.cfg

activating system...
Backtrace:
In ice-9/boot-9.scm:
  3422:24 19 (_)
   222:29 18 (map1 (((gnu system accounts)) ((gnu build accounts)) …))
   222:29 17 (map1 (((gnu build accounts)) ((gnu build #)) ((# …)) …))
   222:17 16 (map1 (((gnu build linux-boot)) ((guix build utils)) # …))
  3326:17 15 (resolve-interface (gnu build linux-boot) #:select _ # _ …)
In ice-9/threads.scm:
390:8 14 (_ _)
In ice-9/boot-9.scm:
  3252:13 13 (_)
In ice-9/threads.scm:
390:8 12 (_ _)
In ice-9/boot-9.scm:
  3536:20 11 (_)
   2835:4 10 (save-module-excursion #)
  3556:26  9 (_)
In unknown file:
   8 (primitive-load-path "gnu/build/linux-boot" #)
In gnu/build/linux-boot.scm:
 22:0  7 (_)
In ice-9/boot-9.scm:
   3409:4  6 (define-module* _ #:filename _ #:pure _ #:version _ # _ …)
  3422:24  5 (_)
   222:29  4 (map1 (((rnrs io ports)) ((system repl #)) ((srfi #)) …))
   222:17  3 (map1 (((system repl error-handling)) ((srfi srfi-1)) …))
   3329:6  2 (resolve-interface (system repl error-handling) #:select …)
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
no code for module (system repl error-handling)
--8<---cut here---end--->8---

Checkout is at b905abfbd3235322c826e3b0ad45e410a3cd96f3

bug#48240: “guix copy” to host with daemon listening on TCP fails

[Simon Streit]

Ludovic Courtès  writes:

> Hi,
>
> Simon Streit  skribis:
>
>> Then it was suggested I checkout to commit
>> dd14678b9b9843be20e2bbb98ceb30d2433dab82 and force downgrade my new
>> system.  While doing so, I noticed that guix-daemon would still offload,
>> while if I'd type in `guix offload test`, I'd get a response:
>>
>> guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
>> guix offload: Guix is usable on 'host' (test returned 
>> "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
>> guix offload: 'host' is running GNU Guile 3.0.5
>> guix offload: error: failed to connect over SSH to daemon at 'host', socket 
>> /var/guix/daemon-socket/socket
>>
>> Anyway, back to this old commit offloading works for all users.
>>
>> The commit with this broken behaviour is at:
>> 87b4b0e4385149b40ee87ae2d57712679452746b.
>
> Fixed in da28efef36af8925bcd9e40a81cbf552cf8c2d02.  Let me know if it
> works for you!

Offloading works with this commit!  Thanks
>
> Thanks,
> Ludo’.

bug#48240: “guix copy” to host with daemon listening on TCP fails

[Simon Streit]

Ludovic Courtès  writes:
> Fixed in da28efef36af8925bcd9e40a81cbf552cf8c2d02.  Let me know if it
> works for you!

I'll try it later.  I missed this mail yesterday.


Cheers! 

bug#48240: “guix copy” to host with daemon listening on TCP fails

[Simon Streit]

Ludovic Courtès  writes:
> Simon Streit  skribis:
>> Anyway, back to this old commit offloading works for all users. 
>
> Is the socket file name displayed above correct?  Or did you specify
> something else in the  record?

No, nothing that I'm aware about.  I haven't made any special changes. 
>
> Is the ‘GUIX_DAEMON_SOCKET’ environment variable defined on that
> machine?

No.
>
> How do you run guix-daemon on the head node?  The patches discussed here
> haven’t made it into the ‘guix’ package yet AFAIK.

That is a Guix system, where I've got an extra user with no extra group
permisions that takes the requests for offloading the clients make.
Thinking about it, the host isn't fully updated. Its current checkout
is, or was at the time of reporting to this issue:
407e0af6aa465479d08dafb125d06d50109f1822


Cheers!

bug#48240: “guix_ copy” to host with daemon listening on TCP fails

[Simon Streit]

Hello!

After reinstalling my system last night, I run into this problem too,
that I couldn't offload.

Then it was suggested I checkout to commit
dd14678b9b9843be20e2bbb98ceb30d2433dab82 and force downgrade my new
system.  While doing so, I noticed that guix-daemon would still offload,
while if I'd type in `guix offload test`, I'd get a response:
--8<---cut here---start->8---
guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
guix offload: Guix is usable on 'host' (test returned 
"/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
guix offload: 'host' is running GNU Guile 3.0.5
guix offload: error: failed to connect over SSH to daemon at 'host', socket 
/var/guix/daemon-socket/socket
--8<---cut here---end--->8---

Anyway, back to this old commit offloading works for all users. 

The commit with this broken behaviour is at:
87b4b0e4385149b40ee87ae2d57712679452746b.


Cheers
Simon

bug#47030: blueman fails to find a dbus service file

[Simon Streit]

Hello,

I'm not quite sure yet if this is a is an actual bug or a error on my
side.

Whenever I load blueman-applet, it will pop up an error saying:

Failed to apply newtork settings

and

g-dbus-error-quark:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.blueman.Mechanism was not provided by any .service files (2)

Calling blueman-applet from the console gives:

--8<---cut here---start->8---
blueman-applet version 2.1.4 starting
Stale PID, overwriting
blueman-applet 22.15.06 WARNING  PluginManager:148 __load_plugin: Not loading 
PPPSupport because its conflict has higher priority
blueman-tray version 2.1.4 starting
Stale PID, overwriting
blueman-tray version 2.1.4 starting
There is an instance already running

(.blueman-tray-real:2356): Gdk-CRITICAL **: 22:15:07.504: 
gdk_window_thaw_toplevel_updates: assertion 
'window->update_and_descendants_freeze_count > 0' failed
--8<---cut here---end--->8---

I just tried to get rid of this message by modifying my
%desktop-services with:

--8<---cut here---start->8---
(modify-services %desktop-services
 (dbus config => (dbus-service #:services (list blueman
--8<---cut here---end--->8---

That worked, but it didn't help much.  After looking around online I
found that there has been an issue [1] reported on this before.  Looking
further from there [2] seems to be a viable solution, which is already
packed in the blueman package, but this file I can't find in the
system's profile.

Any help would be greatly appreciated.


Cheers,
Simon

[1] https://github.com/blueman-project/blueman/issues/948
[2] https://github.com/blueman-project/blueman/wiki/PolicyKit

bug#46516: emacs-elpy@1.35.0 fails to build

[Simon Streit]

Hello,

apparantly it seems that emacs-elpy can't be installed into my user
account.  It works in a clean user account where I only
install emacs and emacs-elpy.

Unfortunately I'm not so sure why it is failing.  I tried to find out if
it is related to a previous bug [1], and then removed
emacs-yasnippet[-snippets] after skimming through [2], but that didn't
help either.

Here is my list of installed emacs packages.  This list is maybe a bit
too long, and I hope that it isn't creating any collisions:

--8<---cut here---start->8---
emacs-bash-completion   3.1.0   out 
/gnu/store/0cs84f1103qdz491a5fq5n6bwigaa8i8-emacs-bash-completion-3.1.0
emacs-avy   0.5.0   out 
/gnu/store/igy3dqqks2y83xr3q6wpk97lpk55208q-emacs-avy-0.5.0
emacs-debbugs   0.27out 
/gnu/store/4dxjha723slzyhix2j2ivq22kx07i4rh-emacs-debbugs-0.27
emacs-yasnippet 0.14.0  out 
/gnu/store/q7xja6pc9h5x0hy9m91g82pqlj4rijrb-emacs-yasnippet-0.14.0
emacs-elpher2.10.2  out 
/gnu/store/yias3il5bplbm96rrx6c48dgibplaqq2-emacs-elpher-2.10.2
emacs-org   9.4.4   out 
/gnu/store/30cdhha6sqvgxs6m47mbhc8fkimvarcs-emacs-org-9.4.4
emacs-slime 2.26.1  out 
/gnu/store/b0pq57nlq8n6lrm1mpnk2xdpzj31cnz9-emacs-slime-2.26.1
emacs-transmission  0.12.2  out 
/gnu/store/9nn5jp4wr1w71863v8vc6524w8z6hi37-emacs-transmission-0.12.2
emacs-bluetooth 0.2 out 
/gnu/store/l1lp4m1n2zkaj8qnkyx2mrlpc6c5v3qw-emacs-bluetooth-0.2
emacs-emojify   1.2 out 
/gnu/store/5jlqr639896b6jkiyk7hw205n0rj9ylb-emacs-emojify-1.2
emacs-dired-rsync   0.5 out 
/gnu/store/m97gm459r4zcbhjig5gzpxda3a1fr5d6-emacs-dired-rsync-0.5
emacs-yasnippet-snippets0.23out 
/gnu/store/x8p8pvp6jf9mclciqb99zrxwkdil2fh6-emacs-yasnippet-snippets-0.23
emacs-lsp-mode  7.0.1   out 
/gnu/store/ahdhymh2nm9m05j1hbrmxy9fah19vsfw-emacs-lsp-mode-7.0.1
emacs-lsp-ui7.0.1   out 
/gnu/store/99501j0zfr54l9g7lx1yx5xakgqdjv47-emacs-lsp-ui-7.0.1
emacs-treemacs  2.8 out 
/gnu/store/lg258if4cxwiqlihwscv2bs04vb73i5r-emacs-treemacs-2.8
emacs-trashed   2.1.2   out 
/gnu/store/nr5wxcs2886zyh8ag8ymlm8nc6hzqa42-emacs-trashed-2.1.2
emacs-anzu  0.64out 
/gnu/store/0h8v6w8bcd1aip04zl40gr96mpwp7gav-emacs-anzu-0.64
emacs-arduino-mode  0-1.23ae47c out 
/gnu/store/5q2yb6i54ajk1x7p913hj20b2xy4d1vv-emacs-arduino-mode-0-1.23ae47c
emacs-pulseaudio-control0.0.1-4.a931533 out 
/gnu/store/s1dd217w5sgm9xv0mws2k715mywiky2b-emacs-pulseaudio-control-0.0.1-4.a931533
emacs-guix  0.5.2-3.a694fdb out 
/gnu/store/7k3jrw60p8a5iyqa7mjlqrmhy0gdz1hd-emacs-guix-0.5.2-3.a694fdb
emacs-auctex13.0.4  out 
/gnu/store/a953ypkr5dk7gd18s0pcj3firhlq2jz0-emacs-auctex-13.0.4
emacs   27.1out /gnu/store/7z33lhy9m8xqgym9w3hj30y1w290c8hn-emacs-27.1
emacs-pdf-tools 0.90-1.c510442  out 
/gnu/store/hyadwmf3m0ihsvx4pn97382i68bhc0fd-emacs-pdf-tools-0.90-1.c510442
emacs-company-restclient0.3.0   out 
/gnu/store/2h7n9v2hqid878rjxgsqxvfz03z7c8b0-emacs-company-restclient-0.3.0
emacs-company-reftex0.1.0   out 
/gnu/store/j8vcsk2y71gbs0xzdhrf71131ccslfd7-emacs-company-reftex-0.1.0
emacs-company-quickhelp 2.2.0-1.479676c out 
/gnu/store/srjb8l8av72gblfrz5dnjs4w6s77ykrj-emacs-company-quickhelp-2.2.0-1.479676c
emacs-company-posframe  0.5.0   out 
/gnu/store/ml1mjvbwfy8lijsghjwpa8gqasgbnr97-emacs-company-posframe-0.5.0
emacs-company-math  1.4 out 
/gnu/store/py6p1ylpgnjmzs6d46xgyqd3dv4zfqvc-emacs-company-math-1.4
emacs-company-lua   0.1-2.29f6819   out 
/gnu/store/6bllb7y3b9yclsp4dfbmiqcqq82ldsac-emacs-company-lua-0.1-2.29f6819
emacs-company-lsp   2.1.0   out 
/gnu/store/cd6v8nlspbgirqa3hazplrxrli84g3gh-emacs-company-lsp-2.1.0
emacs-company-jedi  0.04out 
/gnu/store/kiypz9s3kiiz7zhiv8j4jk0vyx9pdniy-emacs-company-jedi-0.04
emacs-company-irony 1.1.0   out 
/gnu/store/myyz95pfkhax32vi4ha8ad98da0744az-emacs-company-irony-1.1.0
emacs-company-flow  0.1.0-1.76ef585 out 
/gnu/store/00g6bi0jl56dmn50jd6j936sml80spzh-emacs-company-flow-0.1.0-1.76ef585
emacs-company-emoji 2.6.0   out 
/gnu/store/qas1lz20cs821bfswxpn44zjj2xpyg63-emacs-company-emoji-2.6.0
emacs-company-ebdb  1.1 out 
/gnu/store/y0vpakgdxdvngqysn1c7c8idj1dd58v7-emacs-company-ebdb-1.1
emacs-company-coq   1.0.1   out 
/gnu/store/gxjyz404msf7pbqqbiyj5cmd1grqi637-emacs-company-coq-1.0.1
emacs-company-cabal 0.3.0-1.62112a7 out 
/gnu/store/jhv3rs039g12lkynrkphz3yh43h0gsz2-emacs-company-cabal-0.3.0-1.62112a7
emacs-company-box   0.0.1-0.be37a9a out 
/gnu/store/scczsl0s57rhqmdxzn7hya1brh8mz220-emacs-company-box-0.0.1-0.be37a9a
emacs-company-auctex0-1.48c42c5 out 
/gnu/store/mxvha9h2kmr8zxrwr6j5c7z0aky3yi9x-emacs-company-auctex-0-1.48c42c5
emacs-company   0.9.13  out 
/gnu/store/zf82m64bp66v3sh0rr4p6c26z996dmix-emacs-company-0.9.13
emacs-prettier  0.1.0-1.e9b73e8 out 
/gnu/store/zjmczv9idnwmvb91nm39cw

bug#44820: MPD fails after respawning too often

[Simon Streit]

Ludovic Courtès writes:

> Hi Martin,
>
> Martin Becze  skribis:
>
>> I also ran into this problem. Here is the relevnat part of
>> /var/run/mpd//log
>>
>>> exception: Failed to create pid file "/var/run/mpd//pid": 
>>> Permission denied
>>
>> A quick dirty fix is just to chown the /var/run/mpd folder so that mpd
>> can create its pid file.
>
> So was the ownership of /var/run/mpd/$USER wrong?

`/var/run/mpd' and subsequent user folders belong to root:root.  Only
`/var/run/mpd/mpd' belong to mpd:mpd.  They where recreated belonging to
root:root after deleting them.

>
> Thanks,
> Ludo’.

bug#44820: MPD fails after respawning too often

[Simon Streit]

Martin Becze writes:

> I also ran into this problem. Here is the relevnat part of
> /var/run/mpd//log
>
>> exception: Failed to create pid file "/var/run/mpd//pid": 
>> Permission denied
>
> A quick dirty fix is just to chown the /var/run/mpd folder so that mpd
> can create its pid file.

I have the the same error message in my log file too, and chowning
ownership of directories helps too.



>
> On 11/27/20 4:31 AM, Ludovic Courtès wrote:
>> Hi,
>> Simon  skribis:
>>
>>> On a recent pull, MPD will not start any more.
>>>
>>> Herd status reports:
>>>
>>> Status of mpd:
>>>It is stopped.
>>>It is disabled.
>>>Provides (mpd).
>>>Requires (user-processes).
>>>Conflicts with ().
>>>Will be respawned.
>>>Last respawned on Mon Nov 23 10:22:07+0100 2020.
>>>
>>>
>>> Reading my messages, I find:
>>>
>>> Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd.
>>> Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started.
>>> Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd.
>>> Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started.
>>> Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd.
>>> Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started.
>>> Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd.
>>> Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started.
>>> Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd.
>>> Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started.
>>> Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd.
>>> Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started.
>>> Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been disabled.
>>> Nov 23 10:22:07 localhost shepherd[1]:   (Respawning too fast.)
>>>
>>>
>>> Unfortunately, there are no further messages as to why the service is
>>> disabled, or why the daemon is respawning too often.
>> Does /var/log/mpd/mpd.log or similar contain useful info?
>> Could you share your ‘mpd-configuration’?
>> There have been two changes recently, which fixed the mpd system
>> test,
>> but perhaps they introduced other issues:
>>
>> https://git.savannah.gnu.org/cgit/guix.git/log?id=bb124f6e9c0af0a23736f233c2ea2c9c9b4a40a6
>> Thanks for reporting the issue,
>> Ludo’.


If I read it correctly in the changes made above, ownership of the
directory should be changed, but it is not.  I just deleted the
directory in /run/mpd and did a reboot.  The user directory is
recreated, and .mpd too, but only ownership is changed in .mpd.

Too bad that my knowledge in guile is too limited at the moment to
provide a solution.  But I'd really love too at the moment. :)

But I believe ownership of the parent directory should be changed
according to the user.

Sorry that I can't provide any better solution at the moment.


Cheers,
Simon