bug#56114: Guix does not have a documented general and practical procedure for lowering a single lowerable object to the /gnu/store/... string.

[zimoun]

Hi,

On Mon, 04 Jul 2022 at 22:13, Ludovic Courtès  wrote:

> I explicitly made “,build” hide that difference; I thought one would
> just want “,build” to do the right thing and display the resulting store
> item regardless of that kind of detail.
>
> Conversely, “,lower” is for die-hard hackers and it doesn’t hide any
> subtlety.

Both make sense. :-)


> Right, that’s because ‘plain-file’ lowers directly to a store item, not
> to a derivation.

My comment was about an unrelated thing.  Well, I do not use every day
G-exp nor ’plain-file’ and the like.  The interface appears to me
unexpected each time I use it but hey I can live with it. :-) However,
the documentation (or docstring) does not appear clear, each time I have
my «aaah right!» moment.  For instance, the manual says:

The local-file, plain-file, computed-file, program-file, and
scheme-file procedures below return file-like objects. That is,
when unquoted in a G-expression, these objects lead to a file in
the store.

and the docstrings say:

--8<---cut here---start->8---
(define (plain-file name content)
  "Return an object representing a text file called NAME with the given
CONTENT (a string) to be added to the store.

This is the declarative counterpart of 'text-file'."
--8<---cut here---end--->8---

or

--8<---cut here---start->8---
(define* (computed-file name gexp
#:key guile (local-build? #t) (options '()))
  "Return an object representing the store item NAME, a file or directory
computed by GEXP.  When LOCAL-BUILD? is #t (the default), it ensures the
corresponding derivation is built locally.  OPTIONS may be used to pass
additional arguments to 'gexp->derivation'.

This is the declarative counterpart of 'gexp->derivation'."
--8<---cut here---end--->8---

when ’plain-file’ and ’computed-file’ does not return the same type of
“file-like object“.  Especially when reading,

--8<---cut here---start->8---
(define* (mixed-text-file name #:key guile #:rest text)
  "Return an object representing store file NAME containing TEXT.  TEXT is a
sequence of strings and file-like objects, as in:

  (mixed-text-file \"profile\"
   \"export PATH=\" coreutils \"/bin:\" grep \"/bin\")

This is the declarative counterpart of 'text-file*'."
--8<---cut here---end--->8---

it is hard to guess beforehand that ’plain-file’ and ’mixed-text-file’
do not return the same type of file-like object.

Therefore, I was thinking to tweak these docstrings to better underline
their difference.  Well, maybe it is only me. :-)


Cheers,
simon


PS:
It remembers me unrelated [1] mentioning confusion about “file or
file-like object”. :-)

1: 

bug#56297: Guix style imperfections

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

>>> (define-public guile-next
>>>  (let ((version "3.0.7") (revision "0")
>>>(commit "d70c1dbebf9ac0fd45af4578c23983ec4a7da535"))
>>
>> Conventionally 'revision' is put on another line -- for these kind of let 
>> bindings,
>> (maybe all?), I would recommend to put all of them on separate lines.
>
> This one is a bug IMO: ‘let’ bindings should be treated specially, and
> currently they’re not.

Commit 8d9291bd2c36810be50ea340cefa481a42c60a2b fixes this, and…

>>>   (substitute-keyword-arguments (package-arguments guile-3.0)
>>> ((#:phases phases
>>>   '%standard-phases) `(modify-phases ,phases
>>
>> Put %standard-phases on the same line ad #:phases phases and `(modify-phases 
>> ,phases
>> on a new lineg 

… the second part of this one.

Ludo’.

bug#36924: GDM, GNOME Shell, etc. break when there are stale caches

[reyman via web]

Hi there
After removing `gdm login` using a transformer and forget to modify/amend it 
into build-custom-services i break my system : 

(define-public %dm/system-services
  (append (build-custom-services identity)
(modify-services %desktop-services
(delete gdm-service-type

My gnome crash, and when i even when i try to roll-back, it was impossible to 
login, my screen freeze at login/password, just before gnome start.

Error in message : 

ul  4 17:44:11 localhost elogind[427]: New session c1 of user gdm.
Jul  4 17:44:11 localhost gdm-session-worker: GLib-GObject: g_object_unref: 
assertion 'G_IS_OBJECT (object)' failed 
Jul  4 17:44:11 localhost gdm: Gdm: GdmDisplay: Session never registered, 
failing 
Jul  4 17:44:11 localhost elogind[427]: Removed session c1.
Jul  4 17:44:11 localhost gdm: Gdm: Child process -552 was already dead. 
Jul  4 17:44:11 localhost gdm: Gdm: GdmDisplay: Session never registered, 
failing 
Jul  4 17:44:11 localhost gdm: Gdm: Child process -552 was already dead. 

Removing /var/lib/gdm and mkdir gdm, rebooting with rollback solving the 
problem. 

during a guix system reconfigure

bug#36924: GDM, GNOME Shell, etc. break when there are stale caches

[Ludovic via web]

Test (ignore).

bug#56114: Guix does not have a documented general and practical procedure for lowering a single lowerable object to the /gnu/store/... string.

[Ludovic Courtès]

Hello!

zimoun  skribis:

> However, note that,
>
> scheme@(guix-user)> ,build (plain-file "foo" "bar")
> $1 = "/gnu/store/798sxvdgr0680czdggbls7rd3sfwk2yx-foo"
> scheme@(guix-user)> ,lower (plain-file "foo" "bar")
> $2 = "/gnu/store/798sxvdgr0680czdggbls7rd3sfwk2yx-foo"
>
>
> which is confusing, especially when,
>
> scheme@(guix-user)> ,lower (mixed-text-file "foo" "bar")
> $6 = # 
> /gnu/store/raihpcxdz6wmdpyj67bwd4bjk02xq0x3-foo 7f6f9bc5cd20>
> scheme@(guix-user)> ,build (mixed-text-file "foo" "bar")
> $7 = "/gnu/store/raihpcxdz6wmdpyj67bwd4bjk02xq0x3-foo"

Right, that’s because ‘plain-file’ lowers directly to a store item, not
to a derivation.

I explicitly made “,build” hide that difference; I thought one would
just want “,build” to do the right thing and display the resulting store
item regardless of that kind of detail.

Conversely, “,lower” is for die-hard hackers and it doesn’t hide any
subtlety.

>> +(define* (evaluate/print-with-store mvalue #:key build?)
>> +  "Run monadic value MVALUE in the store monad and print its value."
>
> I do not know if it makes sense to have a list of monadic values,
> allowing something like:
>
> ,build hello coreutils

I don’t think the REPL can support this syntax, but we could add support
for:

  ,build (list hello coreutils)

Thanks for your feedback!

Ludo’.

bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?

[Pierre Neidhardt]

Find the first draft attached.  Do not merge, we need to figure out what
to do with sbcl-stumpwm-kbd-layouts.


signature.asc
Description: PGP signature
This fixes 2 flaws in the asdf-build-system:

1. Use asdf:load-system instead of asdf:compile-system.  The latter is not
recommended by the manual and fails with at least 2 systems.

2. Add the build directory to the ASDF registry so that .asd files are
automatically found.  This has a double benefit:
  - It dramatically simplifies package definition writing.
  - It fixes a bug which used to cause the check phase to fail.

All commits after the first two adapt the Common Lisp package definitions to
the new build system and in particular fix many check phases.
>From fd4eb6c4d5fce8d3c1ef205b541ddf76ed0c478a Mon Sep 17 00:00:00 2001
From: Pierre Neidhardt 
Date: Fri, 1 Jul 2022 16:37:44 +0200
Subject: [PATCH 01/18] guix: build: Switch from asdf:compile-system to
 asdf:load-system.

* guix/build/lisp-utils.scm (compile-systems): Switch from asdf:compile-system
to asdf:load-system.

According to the ASDF manual:

This will make sure all the files in the system are compiled, but not
necessarily load any of them in the current image; on most systems, it
will _not_ load all compiled files in the current image.  This function
exists for symmetry with 'load-system' but is not recommended unless you
are writing build scripts and know what you're doing.
---
 guix/build/lisp-utils.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guix/build/lisp-utils.scm b/guix/build/lisp-utils.scm
index 17d2637f87..bd6b21d5a6 100644
--- a/guix/build/lisp-utils.scm
+++ b/guix/build/lisp-utils.scm
@@ -116,7 +116,7 @@ (define (compile-systems systems asd-files)
   `(asdf:load-asd (truename ,asd-file)))
 asd-files)
  ,@(map (lambda (system)
-  `(asdf:compile-system ,system))
+  `(asdf:load-system ,system))
 systems
 
 (define (test-system system asd-files test-asd-file)
-- 
2.32.0

>From 2395f5bef855cb734d13745b9c90a3bbae550d56 Mon Sep 17 00:00:00 2001
From: Pierre Neidhardt 
Date: Fri, 1 Jul 2022 17:17:32 +0200
Subject: [PATCH 02/18] build-system: asdf: Let ASDF locate the .asd files.

* guix/build-system/asdf.scm (package-with-build-system): Remove 'asd-files'
and replace 'test-asd-file' by 'asd-test-systems'.
(lower): Same.

* guix/build/asdf-build-system.scm (source-asd-file): Remove since ASDF does
it better than us.
(find-asd-files): Same.
(build): Remove unused asd-files argument.
(check): Remove asd-files argument and replace asd-systems by
asd-test-systems.

* guix/build/lisp-utils.scm (compile-systems): Call to ASDF to find the
systems.
(test-system): Same.

This approach has many benefits:

- It's simplifies the build system.
- The package definitions are easier to write.
- It fixes a bug with systems that call asdf:clear-system which would cause
  the load to fail.  See for instance test systems using Prove.
---
 guix/build-system/asdf.scm   | 13 +++-
 guix/build/asdf-build-system.scm | 28 ++---
 guix/build/lisp-utils.scm| 35 ++--
 3 files changed, 29 insertions(+), 47 deletions(-)

diff --git a/guix/build-system/asdf.scm b/guix/build-system/asdf.scm
index a0f4634db0..98231714d9 100644
--- a/guix/build-system/asdf.scm
+++ b/guix/build-system/asdf.scm
@@ -202,7 +202,7 @@ (define (new-inputs inputs-getter)
   (define base-arguments
 (if target-is-source?
 (strip-keyword-arguments
- '(#:tests? #:asd-files #:lisp #:asd-systems #:test-asd-file)
+ '(#:tests? #:lisp #:asd-systems #:asd-test-systems)
  (package-arguments pkg))
 (package-arguments pkg)))
 
@@ -270,9 +270,8 @@ (define (asdf-build lisp-type)
   (lambda* (name inputs
  #:key source outputs
  (tests? #t)
- (asd-files ''())
  (asd-systems ''())
- (test-asd-file #f)
+ (asd-test-systems ''())
  (phases '%standard-phases)
  (search-paths '())
  (system (%current-system))
@@ -292,6 +291,11 @@ (define systems
 `(quote ,(list package-name)))
   asd-systems))
 
+(define test-systems
+  (if (null? (cadr asd-test-systems))
+  systems
+  asd-test-systems))
+
 (define builder
   (with-imported-modules imported-modules
 #~(begin
@@ -302,9 +306,8 @@ (define builder
(%lisp-type #$lisp-type))
   (asdf-build #:name #$name
   #:source #+source
-  #:asd-files #$asd-files
   #:asd-systems #$systems
-  #:test-asd-file #$test-asd-file
+  #:asd-test-systems #$test-systems
   #:system #$system
   #:tests? #$tests?
 

bug#56383: Neither Gnome nor udisksctl can mount an nfs filesystem

[Liliana Marie Prikler]

Am Montag, dem 04.07.2022 um 16:03 +0200 schrieb Alexandre Hannud Abdo:
> Ni! Connecting an external USB hard drive with an NTFS partition
> fails to mount it on both Gnome (Nautilus) and manually through
> udisksctl.
Note that NTFS != NFS.  But to solve your problem, simply add ntfs-3g
to your operating-system's packages field.

bug#56114: Guix does not have a documented general and practical procedure for lowering a single lowerable object to the /gnu/store/... string.

[zimoun]

Hi,

If I read correctly, this snippet from the manual,

>>  scheme@(guile-user)> ,run-in-store (package->derivation hello)
>>  $1 = # ...>

becomes

scheme@(guile-user)> ,lower hello

and this snippet,

> scheme@(guix-user)> ,run-in-store (lower-object (plain-file "foo" "bar"))
> $15 = "/gnu/store/798sxvdgr0680czdggbls7rd3sfwk2yx-foo"

becomes

scheme@(guile-user)> ,build (plain-file "foo" "bar")


However, note that,

--8<---cut here---start->8---
scheme@(guix-user)> ,build (plain-file "foo" "bar")
$1 = "/gnu/store/798sxvdgr0680czdggbls7rd3sfwk2yx-foo"
scheme@(guix-user)> ,lower (plain-file "foo" "bar")
$2 = "/gnu/store/798sxvdgr0680czdggbls7rd3sfwk2yx-foo"
--8<---cut here---end--->8---

which is confusing, especially when,

--8<---cut here---start->8---
scheme@(guix-user)> ,lower (mixed-text-file "foo" "bar")
$6 = # 
/gnu/store/raihpcxdz6wmdpyj67bwd4bjk02xq0x3-foo 7f6f9bc5cd20>
scheme@(guix-user)> ,build (mixed-text-file "foo" "bar")
$7 = "/gnu/store/raihpcxdz6wmdpyj67bwd4bjk02xq0x3-foo"
--8<---cut here---end--->8---


The issue – unrelated to the nice patch – is a potential “inconsistency”
between ’’ and ’’; ’plain-file’ refers to
’text-file’ and ’mixed-text-file’ refers to ’text-file*’; and both are
really different despite close names around. :-)

Maybe the docstring of ’plain-file’ and of ’mixed-text-file’ could be
extended.  For instance,

--8<---cut here---start->8---
(define (plain-file name content)
  "Return an lowered object representing a text file called NAME with the given
CONTENT (a string) to be added to the store.

This is the declarative counterpart of 'text-file'."
--8<---cut here---end--->8---

--8<---cut here---start->8---
(define* (mixed-text-file name #:key guile #:rest text)
  "Return an object representing store file NAME containing TEXT.  TEXT is a
sequence of strings and file-like objects, as in:

  (mixed-text-file \"profile\"
   \"export PATH=\" coreutils \"/bin:\" grep \"/bin\")

This is the declarative counterpart of 'text-file*' but note that a
'computed-file' object is returned."
--8<---cut here---end--->8---



> diff --git a/guix/monad-repl.scm b/guix/monad-repl.scm
> index aefabdeebb..15c10efe01 100644
> --- a/guix/monad-repl.scm
> +++ b/guix/monad-repl.scm
> @@ -1,5 +1,5 @@

All LGTM.


> +(define* (evaluate/print-with-store mvalue #:key build?)
> +  "Run monadic value MVALUE in the store monad and print its value."

I do not know if it makes sense to have a list of monadic values,
allowing something like:

,build hello coreutils



Cheers,
simon

bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?

[Pierre Neidhardt]

I found a blocker: Some StumpWM contribs like sbcl-stumpwm kbd-layout
make calls at the top level which expect a running session of StumpWM,
and thus asd:load-system will fail on them, while asdf:compile-system
used to work.

Suggestion: add an option to our build system to choose between
asdf:load-system and asdf:compile-system.  We default to
asdf:load-system and use asdf:compile-system in stumpwm-contrib.

Thoughts?


signature.asc
Description: PGP signature

bug#56383: Neither Gnome nor udisksctl can mount an nfs filesystem

[Alexandre Hannud Abdo]

Ni! Connecting an external USB hard drive with an NTFS partition fails to mount 
it on both Gnome (Nautilus) and manually through udisksctl.

On nautilus, it shows the partition but clicking on it pops a window: "wrong fs 
type, bad option, bad superblock on /dev/sdb2, missing codepage or helper program, or 
other error".

I've managed to successfully mount it with my non-root user using udisksctl:

$ udisksctl mount -b /dev/sdb2 -t auto

Strangely, "-t ntfs" didn't work, but "-t auto" did the trick. Even when it 
worked, the drive is mounted without permissions for my user (uid 1000), though I could copy files 
with sudo.

System logs show:

Jul  2 12:45:44 localhost vmunix: [16392.469209] ntfs: volume version 3.1.
Jul  2 12:45:44 localhost shepherd[1]: [dbus-daemon]
Jul  2 12:45:44 localhost shepherd[1]: [dbus-daemon] (udisksd:1057): 
udisks-WARNING **: 12:45:44.302: Failed to setup systemd-based mount point 
cleanup: Failed to execute child process ?systemd-escape? (No such
file or directory)
Jul  2 12:45:44 localhost shepherd[1]: [dbus-daemon] udisks-Message: 
12:45:44.303: Mounted /dev/sdb2 at /media/myuser/TOURO Mobile USB3.0 on behalf 
of uid 1000

My config.scm declares :

 (services (append (list (service gnome-desktop-service-type) ...

and also

 (packages (append (list
    ;; for user mounts
    gvfs
    ;; for mtp and fat mounts
    jmtpfs dosfstools
    ;; for gnome-disks via udisksd
    gptfdisk
    ...

.~´



OpenPGP_0x10508FA593B7BE6D.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#40641: Building from git breaks when /bin/sh isn't bash

[elaexuotee--- via Bug reports for GNU Guix]

"pelzflorian (Florian Pelz)"  wrote:
> Thank you for getting back to the bug.  I am in the same situation in
> that I use Guix System now. :D
> 
> On Tue, Jun 21, 2022 at 09:20:28AM +0900, elaexuo...@wilsonb.com wrote:
> > so you could be able to sanity
> > check with something like
> > 
> > $ guix shell -C dash guix make 
> > $ ln -s $(command -v dash) /bin/sh
> > $ ./configure --localstatedir && make
> 
> I had done exactly this.
> 
> guix shell --container --network dash git pkg-config gnutls guile guile-avahi 
> guile-gcrypt guile-json guile-lib guile-sqlite3 guile-zlib guile-lzlib 
> guile-zstd guile-ssh guile-git autoconf automake gettext texinfo graphviz 
> help2man po4a findutils sed coreutils tar xz m4 diffutils grep gcc-toolchain 
> sqlite libgcrypt gawk make glibc-locales -- dash
> 
> Many tests fail because of the container though, so I’m not sure how
> big the effect is.  At least tests/guix-package.sh still use type -P
> which is not POSIX, but I don’t think it should be changed nor should
> there be a check if $SHELL can do what we need, because we don’t know
> which bash features we need.

Excellent. I agree it's probably not worth POSIXifying the scripts. Forcing
make to default to guix's bash seems like the right approach IMHO, so +1 for
that fix.

FWIW, I ended up working around the original issue by explicitly telling make
to use guix's bash, anyway:

$ guix environment guix bash
$ CONFIG_SHELL=$(command -v bash) ./configure --localstatedir=/var

bug#53355: bug#51466: bug#53355: guix shell --check: confusing error message

[Ludovic Courtès]

Hi,

"("  skribis:

> On Tue Jun 28, 2022 at 11:38 AM BST, Maxime Devos wrote:
>> Then it could be fixed in that distro?  And if the distro intentionally
>> keeps it broken for years, then that seems more a problem in the distro
>> than Guix to me.
>
> I believe Ludo' is referring to LTS distros and other situations where
> somebody might not update for a long time.

Yeah.  Whatever the reason, it’s a fact that our users might run Guix on
a system with a broken Dash, which is why I think we have to cope with it.

Ludo’.

bug#56376: emacs-guix missing from package-activated-list

[Liliana Marie Prikler]

Am Sonntag, dem 03.07.2022 um 21:33 -0400 schrieb Philip McGrath:
> Hi,
> 
> I've been looking into managing my Emacs packages with Guix. I found
> that the `emacs-guix` package doesn't seem to show up in the
> `package-activated-list`, even though its dependencies do, which
> seems like a bug.
This might be related to the fact that Emacs doesn't see guix as a
package.  I think the recipe might be missing the -pkg.el
autogeneration we added to emacs-build-system.