bug#54350: Profile collisions in "guix shell"

[Konrad Hinsen]

Konrad Hinsen  writes:

> I run everything that is part of a research project in containers,
> meaning "guix shell -C".

Related: HPC users on clusters using NFS are also advised to use
"guix shell" rather than profiles:

  https://lists.gnu.org/archive/html/guix-science/2023-12/msg7.html
  https://lists.gnu.org/archive/html/guix-science/2023-12/msg8.html

Cheers,
  Konrad.

bug#67829: qtwebengine new failure on i686

[John Kehayias via Bug reports for GNU Guix]

Hello Maxim,

On Thu, Dec 14, 2023 at 03:33 PM, Maxim Cournoyer wrote:

> Hello,
>
> qtwebengine was marked as newly failing by Cuirass on Berlin, as a

This "newly failing" is the same false alarm as we saw recently. I
think Cuirass gets confused on same package with different versions as
the only one I see on i686-linux building in the past year is v5.

> result to the xorg-server update in
> .
>
> v8_use_external_startup_data=false
> CMake Error at 
> /tmp/guix-build-qtwebengine-6.5.2.drv-0/qtwebengine-everywhere-src-6.5.2/cmake/Gn.cmake:75
>  (message):
>
>
>   -- GN FAILED
>
>   ERROR at //BUILD.gn:1652:1: Assertion failed.
>
>   assert(
>
>   ^-
>
>   'target_cpu=x86' is not supported for 'target_os=linux'.  Consider omitting
>   'target_cpu' (default) or using 'target_cpu=x64' instead.
>
>   See //BUILD.gn:1653:5:
>
>   is_valid_x86_target || target_cpu != "x86" || v8_target_cpu == "arm",
>   ^---
>
>   This is where it was set.
>
>   1
>
> ninja: build stopped: subcommand failed.
>
> I don't see how the two would be related, but I've CC'd John in case
> they'd have some hunch.
>
> Perhaps some non-deterministic issue with the 'gn' build system?  It had
> succeeded here:  about a
> week ago.

As for the actual error, no idea (I saw the same thing when I noticed
the "new failure"). But I'm cc'ing Efraim as having figured out the
fix for the other package (sorry don't remember which, qt something)
on i686 recently...

John

bug#67738: [PATCH v2] services: xorg: Find sessions from guix home directory.

[Feng Shu]

>From 0e3968aff482ed8ef912f02b744631bb8899f9e4 Mon Sep 17 00:00:00 2001
From: Feng Shu 
Date: Thu, 14 Dec 2023 10:58:02 +0800
Subject: [PATCH v2] services: xorg: Find sessions from guix home directory.

* gnu/services/xorg.scm (xinitrc): Find sessions from guix home directory.
---
 gnu/services/xorg.scm | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index f8cf9f25b6..9235295dd6 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -458,6 +458,11 @@ (define user-profile
  (lambda (pw)
(string-append (passwd:dir pw) "/.guix-profile"
 
+(define guix-home-profile
+  (and=> (getpw (getuid))
+ (lambda (pw)
+   (string-append (passwd:dir pw) "/.guix-home/profile"
+
 (define (xsession-command desktop-file)
   ;; Read from DESKTOP-FILE its X session command and return it as a
   ;; list.
@@ -503,6 +508,7 @@ (define (find-session profile)
   (apply exec-from-login-shell
  (or session
  (find-session user-profile)
+ (find-session guix-home-profile)
  (find-session system-profile)))
 
   (program-file "xinitrc" builder))
-- 
2.39.2


-- 

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

[Timo Wilken]

After a bit of searching, it looks like 67538, 67230 and 65178 may be the same
issue.

Attila Lendvai wrote:
> > > my suspicion is that it's due to some error coming from a start
> > > GEXP that somehow derails shepherd's event loop.
> >
> > iirc I once managed to get a debugger out when it happened and it's
> > stuck waiting in one of the epoll/select/alike calls,
>
> ...or one of the start/stop GEXP's calls something that (sometimes?) blocks
> indefinitely (which violates the API of shepherd).

Same symptoms here again.

For context: this time I was trying to deploy some OCI/Docker containers using
Guix' `oci-container-service-type', specifically a Shepherd service called
"conduit". My code is here:

https://cgit.twilken.net/dotfiles/log/?h=matrix-containers

(Specifically, commits bf94f7872a1df293bd904bbd2c1ef7229f4f98a8 and
c87dcdae79c6266ac3dac70af08fbef5eb21629b.)

This is with Guix commit 1b2505217cf222d98cc960b8510660976a01cfa1.

I first ran "guix system reconfigure -L . tw/system/lud.scm" with commit
bf94f7872a1df293bd904bbd2c1ef7229f4f98a8, which had a bug (an env var was
wrong, so the container failed to start). This worked as expected in that
Shepherd tried to start the service, which failed, so Shepherd disabled it.

Then, I fixed the env var and re-ran "guix system reconfigure -L .
tw/system/lud.scm" with commit c87dcdae79c6266ac3dac70af08fbef5eb21629b.
Shepherd loaded the new "conduit" service fine, as far as I can tell, but
didn't restart it because it was still disabled.

I then enabled and started the service manually. Enabling worked fine, but on
start, I got no terminal output from Shepherd, and it hung.

I still had an error in my setup (directory permissions were wrong), and I got
a message in /var/log/messages to that effect:

--8<---cut here---start->8---
Dec 14 21:33:50 localhost shepherd[1]: Service conduit is currently disabled. 
Dec 14 21:34:04 localhost shepherd[1]: Enabled service conduit. 
Dec 14 21:34:07 localhost shepherd[1]: Starting service user-homes... 
Dec 14 21:34:07 localhost shepherd[1]: Service user-homes has been started. 
Dec 14 21:34:07 localhost shepherd[1]: Service user-homes started. 
Dec 14 21:34:07 localhost shepherd[1]: Service user-homes running with value 
#t. 
Dec 14 21:34:07 localhost shepherd[1]: Starting service conduit... 
Dec 14 21:34:07 localhost shepherd[1]: Service conduit has been started. 
Dec 14 21:34:07 localhost shepherd[1]: Service conduit started. 
Dec 14 21:34:07 localhost shepherd[1]: Service conduit running with value 
13226. 
Dec 14 21:34:07 localhost shepherd[1]: [docker] conduit: [...] "IO error: While 
open a file for appending: /var/lib/matrix-conduit/LOG: Permission denied"
--8<---cut here---end--->8---

...showing that Shepherd had at least tried to start the new container. The
container is not running, though (due to the error shown above), and nothing
with PID 13226 is running.

The "herd start conduit" command did not return, and ^C-ing it did not help.
Afterwards, every "herd" command also hung without any output.

Here are the last four lines of the output of "sudo strace -s1000 herd status"
on such a hung machine:

--8<---cut here---start->8---
connect(10, {sa_family=AF_UNIX, sun_path="/var/run/shepherd/socket"}, 26) = 0
getcwd("/home/timo", 100)   = 11
write(10, "(shepherd-command (version 0) (action status) (service root) 
(arguments ()) (directory \"/home/timo\"))", 101) = 101
read(10,
--8<---cut here---end--->8---

The "read(10, " call never completes.

At least in this case, Shepherd still seems to be processing inbound inet
connections, so I can open new SSH connections to the machine.

Attaching to PID 1 with strace shows it is stuck in "epoll_wait(13, "
(unsurprisingly, fd 13 points to "anon_inode:[eventpoll]"). Here's a backtrace
of all threads in "gdb -p 1":

--8<---cut here---start->8---
(gdb) info threads
  Id   Target Id Frame 
* 1Thread 0x7f786544c380 (LWP 1) "shepherd"  0x7f7865552626 in 
epoll_wait ()
   from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6
  2Thread 0x7f7864e16640 (LWP 186) "GC-marker-0" 0x7f78654cf16a in 
__futex_abstimed_wait_common ()
   from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6
  3Thread 0x7f7864615640 (LWP 187) "GC-marker-1" 0x7f78654cf16a in 
__futex_abstimed_wait_common ()
   from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6
  4Thread 0x7f7863e14640 (LWP 188) "GC-marker-2" 0x7f78654cf16a in 
__futex_abstimed_wait_common ()
   from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6
  5Thread 0x7f78634c6640 (LWP 190) "shepherd"0x7f786554300c in read 
()
   from 

bug#67829: qtwebengine new failure on i686

[Maxim Cournoyer]

Hello,

qtwebengine was marked as newly failing by Cuirass on Berlin, as a
result to the xorg-server update in
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8083c7abbf3a346162fcc4b8d5aa50555c0f3179.

--8<---cut here---start->8---
v8_use_external_startup_data=false
CMake Error at 
/tmp/guix-build-qtwebengine-6.5.2.drv-0/qtwebengine-everywhere-src-6.5.2/cmake/Gn.cmake:75
 (message):
  

  -- GN FAILED

  ERROR at //BUILD.gn:1652:1: Assertion failed.

  assert(

  ^-

  'target_cpu=x86' is not supported for 'target_os=linux'.  Consider omitting
  'target_cpu' (default) or using 'target_cpu=x64' instead.

  See //BUILD.gn:1653:5:

  is_valid_x86_target || target_cpu != "x86" || v8_target_cpu == "arm",
  ^---

  This is where it was set.

  1

ninja: build stopped: subcommand failed.
--8<---cut here---end--->8---

I don't see how the two would be related, but I've CC'd John in case
they'd have some hunch.

Perhaps some non-deterministic issue with the 'gn' build system?  It had
succeeded here: https://ci.guix.gnu.org/build/2803939/details about a
week ago.

-- 
Thanks,
Maxim

bug#67586: guix package: error: package glibc-locales@2.37 does not support x86_64-linux

[Ludovic Courtès]

Hi,

Nils Landt  skribis:

>> Ludovic Courtès  hat am 06.12.2023 23:58 CET geschrieben:
>> 
>>  
>> Hi,
>> 
>> Nils Landt  skribis:
>> 
>> > I use guix home for almost everything, but I have installed glibc-locales 
>> > in my "regular" guix (just by running guix package install glibc-locales).
>> > Now, running guix package --upgrade fails with:
>> > guix package: error: package glibc-locales@2.37 does not support 
>> > x86_64-linux
>> 
>> Fixed with 4a6cef9d66ff26e96d63f2f1f886b8212154ca00.
>> 
>> The problem was that glibc-locales@2.37 is marked as supported for
>> i586-gnu only (that’s GNU/Hurd).
>
> Thank you for the quick fix! 
> But isn't the the real bug that guix package (--install, --upgrade) consider 
> an unsupported package as the version to install / upgrade to? Expected 
> behaviour for me would be that it checks for the newest version that can 
> actually be installed on the architecture.

Yes, you’re right, we should fix this.

Thanks,
Ludo’.

bug#67792: txr: certain string substitution in recipe obsolete.

[Guillaume Le Vaillant]

Fixed in ac61e9705fb8c450c6cd0c1731fbb1b909c1f944.
Thanks.


signature.asc
Description: PGP signature