bug#62287: Ungexp inside vector problem

[Andrew Tropin]

On 2023-03-20 11:45, Josselin Poiret wrote:

> Hi Andrew,
>
> Andrew Tropin  writes:
>
>> I would expect two last expressions return the same result, but the
>> former one doesn't do ungexp:
>>
>> --8<---cut here---start->8---
>> (define a '(3 4))
>>
>> (define b `#(1 2 ,a))
>>
>> (eval-with-store
>>  #~(list '(1 2 #$a))) ;; => ((1 2 (3 4)))
>>
>> (eval-with-store
>>  #~(list #(1 2 #$a))) ;; => (#(1 2 (ungexp a)))
>>
>> (eval-with-store
>>  #~(list #$b)) ;; => (#(1 2 4))
>> --8<---cut here---end--->8---
>>
>> Am I doing/expecting something wrong or there is a bug here?
>
> It's more related to how the guile reader works, and this is such a
> corner case that I don't know whether we should fix.  Basically,
> anything starting with # is a reader extension, and the next character
> identifies which extension it is.  #( is the reader extension for
> vectors, #~ for gexp and #$ for ungexp.
>
> To simplify, whenever you use #~, guile will insert (gexp ...) instead,
> which is a hygienic macro (not just a procedure!), that will look for
> ungexps inside the expression.  That traversal is only made on cons
> cells though, so it doesn't try to go through any piece of syntax that
> is not a cons cell!  Since #( doesn't expand to a (vector ...)
> cons-cell, the subexpression gets ignored for traversal.
>
> This is in contrast to another reader extension, #' (for syntax), which
> does expand to (syntax ...), and is thus further traversed!
>
> You can find how both of these reader extensions operate in
> .
>
> I guess the immediate fix is to use (vector ...) rather than #(...).  We
> could also add code to the gexp traversal to also traverse vectors, but
> I am not even sure if they go through the gexp->sexp dance unharmed, and
> we also should in principle do that for everything that can get into a
> gexp, not just vectors (eg. bytevectors).
>

Thank you very much for extensive explanation!  I have a few tasks
related to the guile reader extensions, so when I get my hands dirty
with it, I'll probably share my new thoughts and opinions on this topic.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

bug#62948: Using home-ssh-agent-configuration on Ubuntu breaks login

[Andrew Tropin]

On 2023-04-19 18:28, Janneke Nieuwenhuizen wrote:

> Hi,
>
> Using home-openssh-service-type on Ubuntu 22.10 (OpenSSH_9.3p1, OpenSSL
> 1.1.1t 7 Feb 2023) always creates an ~/.ssh/authorized_keys that breaks
> key-based login.  I cannot access the logs and don't know what the
> problem might be.
>
> When, after running `guix home reconfigure', you do something like:
>
> --8<---cut here---start->8---
> mv .ssh/authorized_keys .ssh/authorized_keys-
> cat .ssh/authorized_keys- > .ssh/authorized_keys
> chmod 400 .ssh/authorized_keys
> --8<---cut here---end--->8---
> 
> key-based login succeeds.
>
> A workaround would be to have home-openssh-service-type leave
> ~/.ssh/authorized_keys alone.  However, when using
>
> --8<---cut here---start->8---
> (service
>   home-openssh-service-type
>   (home-openssh-configuration
>(authorized-keys '(
> --8<---cut here---end--->8---
>
> any existing ~/.ssh/authorized_keys file is removed and replaced by a
> symlink to an empty file.  I don't see how that is useful, it certainly
> breaks key-based login.
>
> Using
>
> --8<---cut here---start->8---
> (service
>   home-openssh-service-type
>   (home-openssh-configuration
>(authorized-keys #f)))
> --8<---cut here---end--->8---
>
> yields a backtrace.
>
> The attached patch fixes that and allows using (authorized-keys #f),
> also making this the default.
>
> WDYT?

It make perfect sense.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

bug#64076: Error message leads user to a false cause of issue

[Christian Miller via Bug reports for GNU Guix]

If someone imports a module that has code which requires additional modules to 
be imported but does not do that, the error message will fool the user that he 
made a mistake with his own defined modules.

cm@gnu /tmp/bug/demo$ guix build -L /tmp -f example.scm
ice-9/eval.scm:223:20: In procedure proc:
error: emacs-dash: unbound variable
hint: Did you forget `(use-modules (bug demo var))'?

I already have it imported but if I run the following command:
cm@gnu /tmp/bug/demo$ guix build -L /tmp -f var.scm
bug/demo/var.scm:14:22: error: git-fetch: unbound variable
hint: Did you forget a `use-modules' form?

We can see that the actual cause of the problem is that in the imported module 
(var) we forgot to import (guix git-download).

The original command should directly tell that the user.  I am new to Guile 
Scheme and created a module with some copy/paste since I was just quickly 
trying something out and thought I did something wrong how I defined those 
modules.

Example:
/tmp
├── bug
│   └── demo
│   ├── example.scm
│   └── var.scm

// example.scm
(define-module (bug demo example)
  #:use-module (bug demo var)
  #:use-module (guix packages)
  #:use-module (guix git-download)
  #:use-module (guix build-system emacs)
  #:use-module ((guix licenses) #:prefix license:))

(define-public emacs-solarized-theme
  (package
(name "emacs-solarized-theme")
(version "2.0.1")
(source
 (origin
   (method git-fetch)
   (uri (git-reference
 (url "https://github.com/bbatsov/solarized-emacs/;)
 (commit (string-append "v" version
   (file-name (git-file-name name version))
   (sha256
(base32 "0l2lcdm2hsjasfkg4rmypa4mvbhglbkkyv0jg88ygc6py9klcccd"
(build-system emacs-build-system)
(propagated-inputs
 (list emacs-dash))
(home-page "https://github.com/bbatsov/solarized-emacs;)
(synopsis "Port of the Solarized theme for Emacs")
(description
 "Solarized for Emacs is a port of the Solarized theme for Vim.  This
package provides a light and a dark variant.")
(license license:gpl3+)))

emacs-solarized-theme

// var.scm
(define-module (bug demo var)
  #:use-module (guix packages)
  #:use-module (guix gexp)
  ;;#:use-module (guix git-download)
  #:use-module (guix build-system emacs)
  #:use-module ((guix licenses) #:prefix license:)
  #:export (emacs-dash))

(define-public emacs-dash
  (package
(name "emacs-dash")
(version "2.19.1")
(source (origin
  (method git-fetch)
  (uri (git-reference
(url "https://github.com/magnars/dash.el;)
(commit version)))
  (file-name (git-file-name name version))
  (sha256
   (base32
"0z6f8y1m9amhg427iz1d4xcyr6n0kj5w7kmiz134p320ixsdnzd8"
(build-system emacs-build-system)
(arguments
 (list #:tests? #t
   #:phases
   #~(modify-phases %standard-phases
   (add-after 'unpack 'disable-byte-compile-error-on-warn
 (lambda _
   (substitute* "Makefile"
 (("\\(setq byte-compile-error-on-warn t\\)")
  "(setq byte-compile-error-on-warn nil)")))
(home-page "https://github.com/magnars/dash.el;)
(synopsis "Modern list library for Emacs")
(description "This package provides a modern list API library for Emacs.")
(license license:gpl3+)))

Go to /tmp/bug/demo and run guix build -L /tmp -f example.scm

Note that if you go to var.scm and uncomment line 4, it will build the package.



Also, shouldn't here the correct path be shown where the variable could be 
imported like it normally does?

demo/var.scm:10:22: error: git-fetch: unbound variable
hint: Did you forget a `use-modules' form?

demo/var.scm:19:18: error: emacs-build-system: unbound variable
hint: Did you forget a `use-modules' form?

Since normally I get the following back:
bug/demo/example.scm:8:3: error: package: unbound variable
hint: Did you forget `(use-modules (guix packages))'?

which makes it really easy to work with it even if you are new to all this 
stuff.

bug#64074: guix [COMMAND] --load-path does not check if path is valid

[Christian Miller via Bug reports for GNU Guix]

User can set load path with -L or --load-path in commands like guix build, guix 
time-machine and so on. But this flag does not check if the path is actually a 
valid directory. You can point to a directory that doesn't even exist on the 
filesystem. It should do that just like the -f or --file flag for the guilx 
build command.

bug#64073: libvirtd requires restart to function

[Christian Miller via Bug reports for GNU Guix]

Currently libvirtd does not work without running "sudo herd restart libvirtd". 
Upon starting virt-manager I can't connect to the socket but if I restart 
libvirtd it works fine.

I tested the 1.4.0 image in a VM and there is no issue. After that I did a guix 
pull and reconfigured the system and I have the same issue again in the VM.

bug#63516: Static networking should wait for interfaces to be up

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Ludovic Courtès  skribis:
>
>> Before doing ‘addr-add’ in ‘network-set-up/linux’, should we wait for
>> the interface to show up, by calling ‘get-links’ from Guile-Netlink or
>> something like that?
>
> Below is a simple workaround.  How does that sound?
>
> A better fix would be to poll(2) on the underlying AF_NETLINK socket.
> In fact, we could also implement something like systemd’s
> ‘network-online.target’ by doing that.  For that we’d need Guile-Netlink
> to let us create SOCK_NONBLOCK sockets and to use real ports instead of
> raw file descriptors; Fibers would then take care of the rest.

Pushed the “better fix” as 26602f4063a6e0c626e8deb3423166bcd0abeb90,
building upon ‘wait-for-link’ from Guile-Netlink 1.2.

Thank you Julien for the Guile-Netlink release!

Ludo’.

bug#54097: bug#63631: [PATCH] import: go: Handle subpackage versioning correctly.

[Ludovic Courtès]

Hi Timo,

Timo Wilken  skribis:

> Some Go source repositories (notably the Google Cloud SDK) contain multiple
> submodules and use a `refs/tags//' tagging scheme.
>
> Fixes .
>
> * guix/import/go.scm (vcs->origin): Accept a module-path-suffix.
> (go-module->guix-package): Use the new parameter.
> ---
> Here's a patch that fixes the reported issue (bug#54097) for me. I've only
> tested this on the github.com/googleapis/google-cloud-go/compute package so
> far, though it seems to work there. Perhaps others have more testcases?
>
> I don't know enough about Go tooling to use it, so I've just patched the Guile
> logic of the importer. (I don't write Go, I just want to package stuff written
> in it.) In terms of performance, at least the repo contents are apparently
> cached by the first `git-checkout-hash' call, even if it fails, so the second
> call doesn't have to redownload them.

What you propose looks similar to part of the work Simon Tournier
submitted at .

What would you suggest?  Simon?

Thanks for the patch, Timo!

Ludo’.

bug#64008: shepherd respawns a service even when it's disabled

[Ludovic Courtès]

Hi Attila,

Attila Lendvai  skribis:

> i'm in a situation where my service quits after a few seconds of CPU usage 
> (i.e. the default-respawn-limit is not triggered). therefore shepherd keeps 
> restarting it, practically in a busy loop.
>
> suggested solution:
>
> maybe respawn-service should check for the disabled state, so that the admin 
> can intervene by `herd disable myservice`.

Turns out the service controller was ignoring the ‘enabled?’  flag,
leaving it up to the caller to check it.

This is fixed by Shepherd commit
7c88d67076a0bb1d9014b3bc23ed9c68f1c702ab.

Thanks again,
Ludo’.

bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`

[Ludovic Courtès]

Hi Maxim & Attila,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:

[...]

 When a service is stopped at the time of reconfigure, it is immediately
 replaced and then started.

 Replacing works by unregistering the old instance from the registry and
 registering a new one.  As a side effect, you end up with an instance
 that’s enabled (see ‘service-registry’ in (shepherd services)).

 I never thought it could be a problem.  WDYT?
>>>
>>> I think it probably goes against users' expectation (i.e., systemd) that
>>> a disabled service stays disabled unless manually re-enabled (I think
>>> that's the way it is for systemd, even when the system is upgraded?).
>>
>> Does systemd have a notion of enabled/disabled?
>
> Yes!  'systemctl disable ' [0].  It does stick around until the
> user changes it, I can confirm the behavior which I've recently seen on
> a Debian system upgrade (the service remained disabled and the updater
> warned it wouldn't be restarted because of that).
>
> [0]  
> https://www.freedesktop.org/software/systemd/man/systemctl.html#disable%20UNIT%E2%80%A6
>
>> I’m fine either way.  We can also change it such that replacing a
>> disabled service does not re-enable it; that’s probably more logical.
>
> I guess sticking to the established convention set by systemd would
> cause the least friction down the road.  If we agree on this, we should
> reopen this bug (and eventually fix it :-)).

Agreed, fixed in Shepherd commit
52db31e5b061440cd110da4848ab230ce09f365a.

Thanks!

Ludo’.

bug#63986: Julia is very slow

[Ludovic Courtès]

Hi Cayetano,

Cc’in Efraim, Simon, and Nicolas who’ve looked into Julia packaging in
the past.  Hopefully we can get inspiration from Arch’s build recipe!

Thanks,
Ludo’.

Cayetano Santos  skribis:

> Hi guix,
>
>   I just noticed that the following line
>
> julia -e 'using Pkg; Pkg.add("BenchmarkTools"); using BenchmarkTools; N = 
> 1000; A = rand(N, N); B = rand(N, N); @btime $A*$B'
>
>   gives around 530 ms in my laptop when using guix provided julia. Same
>   behavior when running within a guix container.
>
>   This very same code, using the binary one may download from the julia
>   site gives 15 ms.
>
>   I’m using here an up to date guix. As a reference, julia binary
>   provided by archlinux takes also 15 ms.
>
> Thanks,
>
> Cayetano Santos

bug#63982: Shepherd can crash when a user service fails to start

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

>> I believe this is fixed by Shepherd commit
>> 24c964021ebd3d63ce6e22808dd09dbe16116a6c, which introduces an additional
>> change: loading the config file asynchronously.
>
> Nitpick: I'd use a git message tag for 'Reported-by', as can be inserted
> in the commit buffer in Magit with C-c C-p.  They should be placed at
> the bottom of the git message to be considered by tools parsing them.

Neat, I didn’t know about it, I’ll do that now (I think I started using
the “Reported by” convention before Git came into existence…).

>> If you wish to test it, you can use the ‘shepherd’ channel.
>
> I've done so by placing in my ~/.config/guix/channels.scm file:
>
>(channel
> (name 'shepherd)
> (url "https://git.savannah.gnu.org/git/shepherd.git;)
> (introduction
>  (make-channel-introduction
>   "788a6d6f1d5c170db68aa4bbfb77024fdc468ed3"  ;2022-05-21
>   (openpgp-fingerprint
>"3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5"
>
>
> It'd be nice to have this in the Shepherd doc for easy copy & paste.

I’ll add that to ‘README’.

>> Let me know how it goes!
>
> I've edited my ~/.xsession file to use
> /gnu/store/ahzl8vxxcd5bqlljwgn8wkp4884sr72l-shepherd-0.10.99-tarball,
> and I'm now seeing this:
>
> $ herd status
> Démarrés :
>  + root
> Starting:
>  ^ emacs
> Arrêtés :
>  - gpg-agent
>  - ibus-daemon
>  - jackd
>  - workrave

Uh, so it remains in “starting” state?

> Interestingly, the Emacs client is usable.  It doesn't change from
> there, and requesting it to be stopped hangs Shepherd:

Technically it’s waiting for ‘emacs’ to be in “running” state before
attempting to stop it.

> If I comment out the Emacs service from the ~/.config/shepherd/init.scm
> file, the same seems to happen on my next service, gpg-agent:
>
> $ herd status
> Démarrés :
>  + root
> Starting:
>  ^ gpg-agent
> Arrêtés :
>  - emacs
>  - ibus-daemon
>  - jackd
>  - workrave
>
> Etc. if I comment that one (now hanging on starting ibus-daemon).  It
> seems something is still off?

Looks like it.  Could you share ~/.local/var/log/shepherd.log?

Thanks,
Ludo’.

bug#63912: Acknowledgement (python-scikit-learn can't be imported "module compiled against API version 0x10 but this version of numpy is 0xf")

[Edouard Klein]

I found the cause:

.local/lib/python3.10/site-packages/  is part of the interpreter's load
path, and so an old version of numpy was imported in priority over
guix's.

I don't know if this is by design, but if so, it means that any
pip --user installed package will overshadow any guix install package,
even when giving --pure to guix shell. It may not be what we want.

What made me find this is that sklearn worked when in a container, but
not in a shell, that meant that something from the local system was
leaking into the shell.



help-debb...@gnu.org (GNU bug Tracking System) writes:

> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  bug-guix@gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 63...@debbugs.gnu.org.
>
> Please do not send mail to help-debb...@gnu.org unless you wish
> to report a problem with the Bug-tracking system.