bug#57965: Problem with freecad substitute

[Aleksandr Vityazev]

Hi,

I want to install freecad, substitute available but the package starts
building locally.

--8<---cut here---start->8---
guix pull

guix weather --substitute-urls="https://bordeaux.guix.gnu.org; freecad
computing 1 package derivations for x86_64-linux...
looking for 1 store items on https://bordeaux.guix.gnu.org...
https://bordeaux.guix.gnu.org ☀
  100.0% substitutes available (1 out of 1)
  53.5 MiB of nars (compressed)
  241.7 MiB on disk (uncompressed)
  1.328 seconds per request (1.3 seconds in total)
  0.8 requests per second
  (continuous integration information unavailable)


guix package  --substitute-urls="https://bordeaux.guix.gnu.org; -i freecad
The following package will be installed:
   freecad 0.20.1

substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
The following derivation will be built:
  /gnu/store/ks669hl57lll1h1qaspiwlr4ls0lg1rm-freecad-0.20.1.drv

--8<---cut here---end--->8---

This also happens with telegram-desktop.


-- 
Best regards, 
Aleksandr Vityazev

bug#57899: emacs-jsonrpc hash mismatch

[Fredrik Salomonsson]

> I'll see if I can create a patch that extracts jsonrpc from emacs'
> master branch. To avoid this issue in the future.

Created a patch for it, see 57964[0].

[0] https://issues.guix.gnu.org/57964

-- 
s/Fred[re]+i[ck]+/Fredrik/g

bug#28510: crash: guix build -S foo --with-source=bla

[Josselin Poiret via Bug reports for GNU Guix]

Hi Simon,

zimoun  writes:

> Well, I would add an error handler; as proposed [1]. :-)  Because does
> “guix build foo --source --with-source=bla” make sense?  What is the
> use-case for such command?

My bad, I didn't see the previous discussion on the subject.  To me, the
lack of generality would be unexpected: if I have a package with a
source, I expect to be able to get that source, whatever the source may
be.  Maxime's minimal example shows that it could happen for a variety
of different reasons, not just a --with-source= flag.  I don't know what
a proper fix for it would be though, since we're passing things around
that we pretend are derivations but are not, and in many places.

Best,
-- 
Josselin Poiret

bug#28510: crash: guix build -S foo --with-source=bla

[zimoun]

Hi,

On Tue, 20 Sep 2022 at 11:19, Josselin Poiret via Bug reports for GNU Guix 
 wrote:

> The simple fix would be to add another band-aid cond at the
> show-derivation-outputs call in build.scm, but it doesn't seem to be
> enough in the long term.

Well, I would add an error handler; as proposed [1]. :-)  Because does
“guix build foo --source --with-source=bla” make sense?  What is the
use-case for such command?

1: 


Cheers,
simon

bug#57827: Shepherd 0.9.2 possible regressions

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

> Regarding those four, I was able to reproduce the issue this way:
>
> $ guix repl
> (stop-service 'guix-daemon)
> (start-service 'guix-daemon (list (number->string (getpid

Or from the shell:

  herd stop guix-daemon
  herd start guix-daemon $$

I was able to reproduce it using a bare-bones.tmpl VM.

> The latter command hangs and Shepherd becomes unresponsive.  I collected
> an (attached) strace dump of Shepherd showing that there is no response
> on the socket when the service is started.
>
> Note that, this works:
>
> $ guix repl
> (stop-service 'guix-daemon)
> (start-service 'guix-daemon) 
>
> So the problem could be caused by the "container-excursion*" in the
> "fork+exec-command/container" procedure.

PID 1 gets stuck on read(16, …) forever, after reading the string “2866”
(a PID):

--8<---cut here---start->8---
[pid  2865] clone(child_stack=NULL, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLDstrace: Process 2866 
attached
, child_tidptr=0x7fccfbe00a10) = 2866
[pid  2866] set_robust_list(0x7fccfbe00a20, 24) = 0
[pid  2866] close(3)= 0
[pid  2865] write(39, "2866", 4 
[pid  2866] close(4 
[pid  2865] <... write resumed>)= 4
[pid  2866] <... close resumed>)= 0
[pid  2866] pipe2( 
[pid  2865] close(39 
[pid  2866] <... pipe2 resumed>[3, 4], O_CLOEXEC) = 0
[pid  2865] <... close resumed>)= 0
[pid  2865] exit_group(0)   = ?
[pid  2866] rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7fccfc304d80}, {sa_handler=0x7fccfc427d50, 
sa_mask=[], sa_flags=SA_RESTORER|SA_NOCLDSTOP, sa_restorer=0x7fccfc304d80}, 8) 
= 0
[pid  2866] rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7fccfc304d80}, {sa_handler=0x7fccfc427d50, 
sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fccfc304d80}, 8) = 0
[pid  2866] rt_sigaction(SIGHUP, {sa_handler=SIG_DFL, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7fccfc304d80}, {sa_handler=0x7fccfc427d50, 
sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fccfc304d80}, 8) = 0
[pid  2866] rt_sigaction(SIGTERM, {sa_handler=SIG_DFL, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x7fccfc304d80}, {sa_handler=0x7fccfc427d50, 
sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fccfc304d80}, 8) = 0
[pid  2866] rt_sigprocmask(SIG_UNBLOCK, [HUP INT TERM CHLD], [HUP INT TERM 
CHLD], 8) = 0
[pid  2866] mkdir("/var", 0777) = -1 EEXIST (File exists)
[pid  2866] mkdir("/var/run", 0777) = -1 EEXIST (File exists)
[pid  2865] +++ exited with 0 +++
[pid 1] <... wait4 resumed>[{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, 
NULL) = 2865
[pid 1] close(39)   = 0
[pid  2866] setsid( 
[pid 1] read(16,  
[pid  2866] <... setsid resumed>)   = 2866
[pid 1] <... read resumed>"2866", 4096) = 4
[pid  2866] chdir("/")  = 0
[pid 1] read(16,  
[pid  2866] prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024, rlim_max=4*1024}) 
= 0
[pid  2866] close(0)= 0
[pid  2866] openat(AT_FDCWD, "/dev/null", O_RDONLY) = 0
[pid  2866] dup2(0, 0)  = 0
[pid  2866] close(1)= 0
[pid  2866] close(2)= 0
[pid  2866] openat(AT_FDCWD, "/var/log/guix-daemon.log", 
O_WRONLY|O_CREAT|O_APPEND, 0640) = 1
[pid  2866] dup2(1, 1)  = 1
[pid  2866] dup2(1, 2)  = 2
[pid  2866] 
execve("/gnu/store/bxnkqnpbf4q4z6245b61wgpm8gkr9nj1-guix-1.3.0-29.9e46320/bin/guix-daemon",
 ["/gnu/store/bxnkqnpbf4q4z6245b61w"..., "--build-users-group", "guixbuild", 
"--max-silent-time", "0", "--timeout", "0", "--log-compression", "gzip", 
"--discover=yes", "--substitute-urls", "https://substitutes.nonguix.org "...], 
0x7fccf71fa480 /* 3 vars */) = 0
--8<---cut here---end--->8---

This happens because the other end of the file descriptor happens to be
inherited by 2866, which will never close it because it just execs
guix-daemon.

This is fixed by 6abdcef4a68e98f538ab69fde096adc5f5ca4ff4; the log
contains extra details.

Thanks!

Ludo’.

bug#44944: Unable to log into X session via gdm

[bokr]

Hi Maxim,

On +2022-09-16 15:00:22 -0400, Maxim Cournoyer wrote:
> Hi,
> 
> Danny Milosavljevic  writes:
> 
> > The latest guix system reconfigure (of yesterday) left me unable to login 
> > into
> > my X session.  guix system rollback DID NOT fix it.
> >
> > I would enter my password and it would "try" to login and return right back 
> > to
> > the gdm login screen.
> >
> > I've since removed gdm from my OS configuration (because I have to do actual
> > *work* on this computer), but I think it would have been enough to just
> > chown /var/lib/gdm and rm ~/.xsession-errors (!) in order to make it work
> > again.
> >
> > Does that mean that user ids are non-reproducible?
> >
> > Why not have user_id = hash(user_name) ?  Then they *are* reproducible.
> 
> That'd be cool, but how would you implement such a hash, that returns
> something fixed between 0 and 1024?  That doesn't sound feasible,
> although I'm no hash function expert.
>

To "return something fixed between 0 and 1024" (1023?) In a context
with less than 1024 users, couldn't one wrap Danny's "hash(username)"
with a local function that finds a 0..1023 index into a trusted table
of hash(username) values represented as string lines?

Similar to the idea of representing 32-bit sRGB 16-million-colors+transparency
with an 8-bit pallette index -- or even a 1-bit index for fg/bg alternates
to black/white.

BTW, for the unlimited-number-of-users case, what sets the 1024 range limit?

> > (I've tried finding the spot where those user accounts are generated/updated
> > but so far have been unable to)
> >
> > Anyway, this is just to record the problem and workaround.  I won't do
> > further research on this problem on it on this computer.
> >
> > The "gdm" system account is gone by now because I've removed gdm from the
> > OS configuration--and I don't plan on adding it ever again.
> 
> I experienced the exact same problem as you.  My topmost /var/lib/gdm
> directory has the correct permissions, but it contains stale entries
> that were created in the past by a different GDM user whose ID is no
> longer the same:
> 
> --8<---cut here---start->8---
> /var/lib/gdm:
> total 616
> drwx-- 1 gdm  gdm  46 Sep 16 09:09 .
> drwxr-xr-x 1 root root222 May  7 20:40 ..
> drwxr-xr-x 1 nixbld04 opendht  62 Dec  7  2021 .cache
> drwx-- 1 nixbld04 opendht  44 Dec  7  2021 .config
> -rw--- 1  955 gdm 1146880 Sep 16 09:09 core
> drwxr-xr-x 1 nixbld04 opendht  10 Dec  7  2021 .local
> 
> /var/lib/gdm/.cache:
> total 0
> drwxr-xr-x 1 nixbld04 opendht  62 Dec  7  2021 .
> drwx-- 1 gdm  gdm  46 Sep 16 09:09 ..
> drwxr-xr-x 1 nixbld04 opendht 384 Dec  7  2021 fontconfig
> drwxr-xr-x 1 nixbld04 opendht   6 Dec  7  2021 ibus
> drwxr-xr-x 1 nixbld04 opendht  34 Dec  7  2021 mesa_shader_cache
> 
> /var/lib/gdm/.cache/fontconfig:
> total 84
> drwxr-xr-x 1 nixbld04 opendht   384 Dec  7  2021 .
> drwxr-xr-x 1 nixbld04 opendht62 Dec  7  2021 ..
> -rw-r--r-- 1 nixbld04 opendht 18496 Dec  7  2021 
> 23ef510a04af7dd5ac1a2dbd06c4afd1-le64.cache-7
> -rw-r--r-- 1 nixbld04 opendht   272 Dec  7  2021 
> 269249ae71e4e445ff7f16f21dcb6de5-le64.cache-7
> -rw-r--r-- 1 nixbld04 opendht   256 Dec  7  2021 
> 50fa4f3b9c91fead50cbfcdae3296c45-le64.cache-7
> -rw-r--r-- 1 nixbld04 opendht 50584 Dec  7  2021 
> a927202dec7f348d7a0569dcad9f19a8-le64.cache-7
> -rw-r--r-- 1 nixbld04 opendht   200 Dec  7  2021 CACHEDIR.TAG
> 
> /var/lib/gdm/.cache/ibus:
> total 0
> drwxr-xr-x 1 nixbld04 opendht  6 Dec  7  2021 .
> drwxr-xr-x 1 nixbld04 opendht 62 Dec  7  2021 ..
> drwxr-xr-x 1 nixbld04 opendht 16 Dec  7  2021 bus
> 
> /var/lib/gdm/.cache/ibus/bus:
> total 172
> drwxr-xr-x 1 nixbld04 opendht 16 Dec  7  2021 .
> drwxr-xr-x 1 nixbld04 opendht  6 Dec  7  2021 ..
> -rw-r--r-- 1 nixbld04 opendht 173300 Dec  7  2021 registry
> 
> /var/lib/gdm/.cache/mesa_shader_cache:
> total 36
> drwxr-xr-x 1 nixbld04 opendht  34 Dec  7  2021 .
> drwxr-xr-x 1 nixbld04 opendht  62 Dec  7  2021 ..
> drwxr-xr-x 1 nixbld04 opendht  76 Dec  7  2021 02
> drwxr-xr-x 1 nixbld04 opendht  76 Dec  7  2021 72
> drwxr-xr-x 1 nixbld04 opendht  76 Dec  7  2021 88
> drwxr-xr-x 1 nixbld04 opendht  76 Dec  7  2021 a3
> drwxr-xr-x 1 nixbld04 opendht  76 Dec  7  2021 c4
> drwxr-xr-x 1 nixbld04 opendht  76 Dec  7  2021 f9
> -rw-r--r-- 1 nixbld04 opendht 1310728 Dec  7  2021 index
> 
> /var/lib/gdm/.cache/mesa_shader_cache/02:
> total 4
> drwxr-xr-x 1 nixbld04 opendht  76 Dec  7  2021 .
> drwxr-xr-x 1 nixbld04 opendht  34 Dec  7  2021 ..
> -rw-r--r-- 1 nixbld04 opendht 868 Dec  7  2021 
> f0edfe0ef96096640b39ff4d2786b503a60a43
> 
> /var/lib/gdm/.cache/mesa_shader_cache/72:
> total 4
> drwxr-xr-x 1 nixbld04 opendht  76 Dec  7  2021 .
> drwxr-xr-x 1 nixbld04 opendht  34 Dec  7  2021 ..
> -rw-r--r-- 1 nixbld04 opendht 989 Dec  7  2021 
> 7cd650943c7a3136f424df6a67c7897f922307
> 
> 

bug#57958: configuration->documentation outputs contains some noise

[Maxim Cournoyer]

Hello,

There appears to be a small regression for the
configuration->documentation from (gnu services configuration): the
fields appear at the beginning of the output, before the start of the
fragment, which is undesirable:

--8<---cut here---start->8---
(configuration->documentation 'lightdm-configuration)
%lightdm-configuration%lightdm-configuration%lightdm-configuration%lightdm-configuration%lightdm-configuration%lightdm-configuration%lightdm-configuration%lightdm-configuration%lightdm-configuration%lightdm-configuration%lightdm-configuration%lightdm-configuration%lightdm-configuration
@c %start of fragment

@deftp {Data Type} lightdm-configuration
Available @code{lightdm-configuration} fields are:

@table @asis
@item @code{lightdm} (default: @code{lightdm}) (type: file-like)
The lightdm package to use.

[...]
--8<---cut here---end--->8---

It'd be nice to fix that.

Thanks,

Maxim

bug#57490: UPower ignores ‘critical-power-action’

[Ludovic Courtès]

Ludovic Courtès  skribis:

> I pushed these patches:
>
>   eedf71f948 * services: upower: Default to a percentage-based policy.
>   4765242540 * services: upower: Update default percentage values.
>
> I’m not sure whether they help, but they might: using a
> time-estimate-based policy is documented as less reliable, and I suppose
> even less so when a battery gets old, as is the case on this laptop.

As those at the Ten Years of Guix event noticed, this didn’t help at all.

Ludo’.

bug#28510: crash: guix build -S foo --with-source=bla

[Josselin Poiret via Bug reports for GNU Guix]

Hi everyone,

Maxime Devos  writes:
> Here is a simpler reproducer for that error:
>
> file a.scm:
> (use-modules (gnu packages) (guix packages) (guix gexp))
> (package
>(inherit (specification->package "hello"))
>(source (local-file "a.scm")))
>
> guix build -f a.scm --source

The issue is that package-source-derivation in guix/packages.scm doesn't
actually always yield a derivation, since lower-object isn't guaranteed
to do that: here the gexp compiler for local-file only returns a string
denoting the file path of the interned store file.  `guix build` relies
on the (wrong) assumption that everything that it will build will end up
being a derivation in some way or another, so just calls
show-derivation-outputs on that, which then errors as above.

build-derivations, contrary to its name, can also pass simple file names
to build-things, and since the file will already be interned in the
store at that point, it won't need to do anything, and there won't be
any errors there.

The simple fix would be to add another band-aid cond at the
show-derivation-outputs call in build.scm, but it doesn't seem to be
enough in the long term.

What do people think?

-- 
Josselin Poiret

bug#57922: Shepherd doesn't seem to correctly handle waitpid itself

[Josselin Poiret via Bug reports for GNU Guix]

Hi Maxim,

Maxim Cournoyer  writes:

> Hi,
>
> I've tried to determine why a workaround in the jami-service-type is
> required in the 'stop' slot to avoid failures in 'herd restart jami',
> and haven't quite found the culprit, but it appears to me that:
>
> 1. waipid is only called in one place in Shepherd, which is in the
> handle-SIGCHLD procedure in (shepherd service), which does not
> specifically wait for an exact PID but rather does:
>
> (waitpid* WAIT_ANY WNOHANG), which is waitpid with some special handling
> in the case a system-error exception is thrown with an ECHILD or EINTR
> error number.
>
> This doesn't strike me as a strong guarantee that waitpid occurs when
> stop is called, because:
>
> 1. It requires to be installed in the signal handlers for each
> processes, with something like:
>
> --8<---cut here---start->8---
>   (unless %sigchld-handler-installed?
> (sigaction SIGCHLD handle-SIGCHLD SA_NOCLDSTOP)
> (set! %sigchld-handler-installed? #t))
> --8<---cut here---end--->8---
>
> Done for fork+exec-command and make-inetd-forkexec-constructor, but not
> for make-forkexec-constructor/container, AFAICT;

The signal handler is only installed once in PID 1 (in fact, you haven't
forked yet here), since it's the one that receives the SIGCHLD.

What I don't understand that well is that this signal handler could be
installed only once when shepherd starts, right?  That way, it wouldn't
need to depend on specific start actions being chosen.

> 2. it has the WNOHANG flag, which means the stop simply does a kill the
> the signal handling weakly (because of WNOHANG) waits on it, which means
> the start may begin before the process was actually completely
> terminated.
>
> Here's a small reproducer to apply on our code base:
>
> --8<---cut here---start->8---
> modified   gnu/services/telephony.scm
> @@ -685,13 +685,7 @@ (define (archive-name->username archive)
>  
>  ;; Finally, return the PID of the daemon process.
>  daemon-pid))
> -   (stop
> -#~(lambda (pid . args)
> -(kill pid SIGKILL)
> -;; Wait for the process to exit; this prevents 
> overlapping
> -;; processes when issuing 'herd restart'.
> -(waitpid pid)
> -#f
> +   (stop #~(make-kill-destructor
>  
>  (define jami-service-type
>(service-type
> --8<---cut here---end--->8---

The real problem here is not really the WNOHANG flag (you could remove
that and still get issues) but rather that the waitpid is run inside a
signal handler, which in Guile means that it's run through asyncs.  You
have no guarantees wrt. when asyncs run, so they could run after or in
the middle of the next action.  I also think make-kill-destructor should
waitpid the processes it's killing, as you're implying, and leave the
signal handler only for unexpected service crashes.

Best,
-- 
Josselin Poiret