bug#56076: guix shell -P behavior is surprising with persistent home

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> Ludovic Courtès schreef op vr 24-06-2022 om 23:10 [+0200]:
>> That said, for this particular use case, you could do:
>> 
>>   guix shell syncthing nss-certs openssl -- syncthing
>> 
>> Adding ‘openssl’ to the mix is a trick to ensure that SSL_CERT_DIR is
>> defined, thanks to the search path mechanism:
>> 
>>   https://guix.gnu.org/manual/devel/en/html_node/Search-Paths.html
>> 
>> Thoughts?
>
> Having to add openssl looks like a bug,

It is, but it’s a reasonable solution for the problem at hand.

> so I'd go for something like 
> instead, which resolves that.

That’s a bit of a hack to work around this venerable bug:

  https://issues.guix.gnu.org/22138

:-)

Ludo’.

bug#56250: File systems not cleanly unmounted?

[Ludovic Courtès]

Hi!

I don’t reboot my laptop very often but over the last couple of months
maybe, I’ve had the impression that I see the “not cleanly unmounted”
message from fsck.ext4 during boot almost every time.

Someone on IRC just reported seeing the same kind of message for
/boot/efi (VFAT) and I’ve seen it on a recently-installed machine,
though I didn’t investigate.

It’s benign but it suggests that file systems are not being properly
unmounted upon shutdown.

Anyone else seeing that?  Ideas as to what might be wrong?

Thanks,
Ludo’.

bug#56076: guix shell -P behavior is surprising with persistent home

[Maxime Devos]

> > Having to add openssl looks like a bug,
> 
> It is, but it’s a reasonable solution for the problem at hand.

I don't think it is.  The point of a package manager or distribution is
to automatically install dependencies where required -- in case of
Guix, dependencies can be considered in a more general sense to include
search paths and not only store items.  Having to search #guix or the
ML for work-arounds defeats the point.

My patch  could be considered a
work-around, but at least it's automatic for the users, users don't
need to remember random Guix bug facts.

Ludovic Courtès schreef op ma 27-06-2022 om 09:55 [+0200]:
> That’s a bit of a hack to work around this venerable bug:
> 
>   https://issues.guix.gnu.org/22138
> 
> :-)

Maybe yes, but there's no progress there, so work-arounds are needed,
and I consider my  to be less of a
hack than ‘add random packages’ (at least 55297 is automatic for the
user, the user doesn't have to remember random packages).  And even if
we do 55297 now, it's still possible to do 22138 later if deemed
proper.

And the patch there is fragile (e.g., if you have gcc:lib in the
references, you automatically get $LIBRARY_PATH TOO, if you have a
cross-gcc:lib, you'd get a $CROSS_LIBRARY_PATH (untested), it's also
not really lexical (+) -- wrap-program boundaries aren't respected.  It
could also easily go wrong in case of static linking (because then
references disappear).  So I consider 22138 not be be a bug/working
patch but a source of more bugs and 55297 to be a proper fix (*).

(*) Except for $GUIX_LOCPATH, but that could be made magical in the
same sense of $PATH.

(+) E.g., suppose that pkg-config and a cross-pkg-config are somewhere
in the references for whatever reason, but only a single one is in the
(propagated) native-inputs.  They both ahave a $PKG_CONFIG_PATH search
path.  However, they are different search paths (one is native-inputs,
other is inputs), so we would get in trouble when "guix shell -D
package" is extended with a --target option or such to make a cross-
compilation environment.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

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

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> It turns out that it is probably not OK to rely on shell redirection in
> this case, after all.  For example, "dash does not support multi-digit
> file descriptors":
>
> https://bugs.launchpad.net/ubuntu/+source/dash/+bug/249620

Bah.  :-/

[...]

> To resolve this, I changed the code so that it just writes to a
> temporary file.  This is simple and more robust.  With the attached
> patch, I was able to use a command like the one above to verify that
> "guix environment --check" works correctly for Guix-built bash, dash,
> ksh, fish, zsh, and ash.  I also verified that it works for Fedora's
> /bin/sh and /bin/bash.
>
> What do you think of this file-based approach?  Supporting many
> different shells is pretty tricky, but I think this patch does a good
> enough job.

Like Maxime, I’d rather not create a temporary file.

I agree that Dash should be fixed, but in the meantime, we still want
our stuff to work with the broken Dash (it’s the default on
Debian/Ubuntu, isn’t it?).

I don’t have a better idea to offer though…

Ludo’.

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

[Maxime Devos]

Ludovic Courtès schreef op ma 27-06-2022 om 12:17 [+0200]:
> I agree that Dash should be fixed, but in the meantime, we still want
> our stuff to work with the broken Dash (it’s the default on
> Debian/Ubuntu, isn’t it?).

If Dash is fixed, then it's non-broken, and we don't have to work with
the broken Dash.  I don't expect fixing it to be more complicated than
the work-arounds in Guile.

> On 26 June 2022 13:07:11 UTC, Maxime Devos 
> wrote:
> >(To be clear, I still recommend just fixing dash ...)
> 
> That's the long-term solution, but Guix needs a work-around
> regardless.

Fixing dash seems to me something that could be done in the short term?

Greetings,
Maxime


signature.asc
Description: This is a digitally signed message part

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

[bokr]

On +2022-06-27 12:17:08 +0200, Ludovic Courtès wrote:
> Hi Chris,
> 
> Chris Marusich  skribis:
> 
> > It turns out that it is probably not OK to rely on shell redirection in
> > this case, after all.  For example, "dash does not support multi-digit
> > file descriptors":
> >
> > https://bugs.launchpad.net/ubuntu/+source/dash/+bug/249620
> 
> Bah.  :-/
> 
> [...]
> 
> > To resolve this, I changed the code so that it just writes to a
> > temporary file.  This is simple and more robust.  With the attached
> > patch, I was able to use a command like the one above to verify that
> > "guix environment --check" works correctly for Guix-built bash, dash,
> > ksh, fish, zsh, and ash.  I also verified that it works for Fedora's
> > /bin/sh and /bin/bash.
> >
> > What do you think of this file-based approach?  Supporting many
> > different shells is pretty tricky, but I think this patch does a good
> > enough job.
> 
> Like Maxime, I’d rather not create a temporary file.
> 
> I agree that Dash should be fixed, but in the meantime, we still want
> our stuff to work with the broken Dash (it’s the default on
> Debian/Ubuntu, isn’t it?).
> 
> I don’t have a better idea to offer though…
> 
> Ludo’.
> 
> 
>
If this is all about capturing an environment as text,
how about

--8<---cut here---start->8---
xargs -0 < /proc/$$/environ
--8<---cut here---end--->8---

(not limited to $$ I would think)
--
Regards,
Bengt Richter

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

[Bengt Richter]

On +2022-06-27 13:23:15 +0200, b...@bokr.com wrote:
> >
> If this is all about capturing an environment as text,
> how about
> 
> --8<---cut here---start->8---
> xargs -0 < /proc/$$/environ
> --8<---cut here---end--->8---
> 
> [...]
>
Actually, why fight shell stuff when guile can read it?
Or are these modules not available in your context?
--8<---cut here---start->8---
scheme@(guile-user)> (use-modules (ice-9 textual-ports))
scheme@(guile-user)> (define ep (open-input-file "/proc/12430/environ"))
scheme@(guile-user)> (define es (get-string-all ep))
--8<---cut here---end--->8---
es from above got it all, when I tried manually as above.

FWIW I also did the same with (use-modules (rnrs bytevectors))
and the nulls show up as the expected zeroes.
--
Regards,
Bengt Richter

bug#56250: File systems not cleanly unmounted?

[angry rectangle]

Ludovic Courtès  writes:

> Hi!
>
> I don’t reboot my laptop very often but over the last couple of months
> maybe, I’ve had the impression that I see the “not cleanly unmounted”
> message from fsck.ext4 during boot almost every time.
>
> Someone on IRC just reported seeing the same kind of message for
> /boot/efi (VFAT) and I’ve seen it on a recently-installed machine,
> though I didn’t investigate.
>
> It’s benign but it suggests that file systems are not being properly
> unmounted upon shutdown.
>
> Anyone else seeing that?  Ideas as to what might be wrong?
>
> Thanks,
> Ludo’.

Hi.
I have this problem too. I posted a bug report a few days ago.
bug#56209 https://lists.gnu.org/archive/html/bug-guix/2022-06/msg00291.html
All I know is that it was introduced with Shepherd 0.9.

It's good to hear that it's harmless though.

bug#56263: set-paths phase throws match-error "match" "no matching pattern" while cross-compiling a kernel module

[Pavel Shlyak]

I don’t know the reason it happens. Maybe it’s somehow related to file-append 
hack that is used to set driver location in the repo. The other problem can be 
about 
inputs or native-inputs being empty. Anyway, package definition looks fine to 
me and I suppose there’s a problem with set-paths phase.
Package definition:
https://git.pantherx.org/development/hardware/raspberry/-/blob/c9260f1720f63c409ef3ce88cefa677a21eb9e0b/reterminal.scm
Package ltr30x-linux-module builds successfully here with aarch64 host and it 
fails if I cross-compile it with x86_64 host
Error log here:
https://gist.github.com/shlyakpavel/b8b53e9bb4392cce1bba3c77c6d35d58

bug#56263: Another reproducer

[Pavel Shlyak]

Another reproducer:
guix build librem-ec-acpi-linux-module --target=aarch64-linux-gnu
Fails with the same error. It doesn’t require external packages like the 
previous reproducer.

bug#56209: Shepherd 0.9 not cleanly unmounting root

[Ludovic Courtès]

Hi,

angry rectangle  skribis:

> Since the upgrade to shepherd 0.9, I get "recovering journal" every single 
> time I start my computer.
> To be specific, "recovering journal" appears after I enter my encryption 
> password in the initrd.
> I assume this means the filesystem wasn't cleanly unmounted.
> I am doing a proper shutdown, using either "reboot" or "halt." 

I can see that as well.

> The guix commit 400c9ed3d779308e56038305d40cd93acb496180 is the specific 
> commit that upgrades shepherd and causes me this problem. The previous commit 
> is fine.
> I'm can confirm that it's still broken on recent commits. I'm on 
> 696e2cc345f015c32f211bf0d0330c04b1cf5f15.

Preliminary investigation suggests this is because shepherd doesn’t
close log files beforehand (in 0.9, those specified as #:log-file to
‘make-forkexec-constructor’ & co. are opened by PID 1; conversely,
shepherd 0.8 would open them in the child process.)

To be continued…

Thanks for reporting the issue and finding the offending commit!

Ludo’.

PS: Below my (ugly) debugging tricks for posterity.  To see those
messages, you typically need to start a VM with ‘-serial stdio’ and
pass “console=ttyS0” to the kernel.  (It’s best to start a
standalone VM with an image created by ‘guix system image -t
qcow2’.)

diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index d58afb27e3..25d747d226 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -299,6 +299,9 @@ (define %root-file-system-shepherd-service
(stop #~(lambda _
  ;; Return #f if successfully stopped.
  (sync)
+ (call-with-port (open-file "/dev/console" "w0")
+   (lambda (port)
+ (display "This is my last message.\n" port)))
 
  (call-with-blocked-asyncs
   (lambda ()
@@ -314,11 +317,24 @@ (define %root-file-system-shepherd-service
   ;; Close /dev/console.
   (for-each close-fdes '(0 1 2))
 
-  ;; At this point, there are no open files left, so the
-  ;; root file system can be re-mounted read-only.
-  (mount #f "/" #f
- (logior MS_REMOUNT MS_RDONLY)
- #:update-mtab? #f)
+  (open-fdes "/dev/null" O_RDONLY)
+  (open-fdes "/dev/console" O_WRONLY)
+  (open-fdes "/dev/console" O_WRONLY)
+  (current-output-port (fdopen 1 "w0"))
+  (current-error-port (fdopen 2 "w0"))
+  (pk 'umount-root)
+
+  (catch 'system-error
+(lambda ()
+  ;; At this point, there are no open files left, so the
+  ;; root file system can be re-mounted read-only.
+  (mount #f "/" #f
+ (logior MS_REMOUNT MS_RDONLY)
+ #:update-mtab? #f))
+(lambda args
+  (pk 'umount-root-error args)
+  #f))
+  (pk 'done-umount-root)
 
   #f)
(respawn? #f)))
@@ -406,7 +422,28 @@ (define (file-system-shepherd-service file-system)
   ;; Make sure PID 1 doesn't keep TARGET busy.
   (chdir "/")
 
-  (umount #$target)
+  (call-with-port (open-file "/dev/console" "w0")
+(lambda (port)
+  (parameterize ((current-output-port port)
+ (current-error-port port))
+(pk 'umount #$target)
+#$(if (file-system-mount-may-fail? file-system)
+  #~(catch 'system-error
+  (lambda ()
+(umount #$target))
+  (const #f))
+  #~(catch 'system-error
+  (lambda ()
+(umount #$target))
+  (lambda args
+(pk 'umount-error args)
+(system* #$(file-append (@ (gnu
+packages
+lsof)
+   lsof)
+"/bin/lsof"))
+#f)))
+(pk 'done-umount #$target
   #f))
 
 ;; We need additional modules.
diff --git a/gnu/system/examples/bare-bones.tmpl b/gnu/system/examples/bare-bones.tmpl
index 387e4b12ba..1f9012c167 100644
--- a/gnu/system/examples/bare-bones.tmpl
+++ b/gn

bug#50665: Docker 19.03 is no longer receiving updates.

[John Kehayias via Bug reports for GNU Guix]

Hello,

I believe this can be closed with Docker having been updated to the latest 
version in this patch series: https://issues.guix.gnu.org/52790

However, on the Go front, this leaves docker-compose to be updated to v2 which 
moves to Go. I tried to import the go package definition but it fails if using 
recursive to get the (many many) dependencies:

guix import go github.com/docker/compose/v2 -r
...
ice-9/boot-9.scm:1683:16: In procedure raise-exception:
Git error: reference 'refs/tags/v0.30.0' not found

In just doing the base package and finding what dependencies are missing, I hit 
this again with

guix import go k8s.io/client-go -r
...
ice-9/boot-9.scm:1683:16: In procedure raise-exception:
Git error: reference 'refs/tags/v0.9.20' not found

Anyway, I should open (after searching for any relevant issues) an issue for 
the Go importer and/or docker-compose updates. Just thought I capture what I've 
seen so far in trying to complete the Docker update.

John

bug#55657: libgccjit is unusable

[John Kehayias via Bug reports for GNU Guix]

Hello,

I currently use the flatwhatson channel (cc'ed on this email, hope that is okay 
Andrew!) and it has worked well for Emacs, though never tried anything else 
with libgccjit. It would be great to get this upstreamed in Guix, especially 
since libgccjit is a beast to build (more than emacs if I remember correctly).

Happy to help test and work on this, let me know anything I can do.

Thanks,
John

bug#55657: libgccjit is unusable

[Liliana Marie Prikler]

Hi,

Am Dienstag, dem 28.06.2022 um 00:53 + schrieb John Kehayias:
> Hello,
> 
> I currently use the flatwhatson channel (cc'ed on this email, hope
> that is okay Andrew!) and it has worked well for Emacs, though never
> tried anything else with libgccjit. It would be great to get this
> upstreamed in Guix, especially since libgccjit is a beast to build
> (more than emacs if I remember correctly).
Keyword here is "has worked for emacs".  I've tried porting the logic
from flatwhatson's channel over, but regardless of what I do, it
already fails in the configure step of Emacs (in a manner that's
reproducible outside as well).  Thus, I think this is a bug in
libgccjit (or perhaps our packaging of it) that simply happened to be
ignored during development of Emacs 28, but no longer in the release.

Cheers

bug#56223: h-client not running with a host distribution

[Maxim Cournoyer]

Hello,

This should be fixed in 8d810c209f18ffb635a1db2488a939543c6f060f.

Josselin Poiret  writes:

> Hello Denis, 
>
> Denis 'GNUtoo' Carikli  writes:
>>> ValueError: Namespace GdkPixbuf not available
>>
>> I vaguely remember that I could launch it on top of Parabola before, so
>> it seems to be related to recent updates to the h-client packages
>> (through before sending data didn't always work due to a bug in the
>> server that is now fixed).
>
> Seems to me that gdk-pixbuf will need to be propagated, which will also
> in turn propagate glib and set the search-path `GIO_EXTRA_MODULES` so
> that GdkPixbuf can be found.

It's odd, but the problem was caused by the lack of GI_TYPELIB_PATH.  I
wrapped that variable and also combined the phases from
glib-or-gtk-build-system and PATH (already wrapped scripts are skipped
instead of of composed) and now, the following works:

--8<---cut here---start->8---
./pre-inst-env guix shell --pure h-client adwaita-icon-theme glib
--8<---cut here---end--->8---

glib is only added above to set XDG_DATA_DIRS and find the icons.

Thanks for the report!

Closing.

Maxim