bug#59529: fail to re-prompt after mistyped disk encryption passphrase

[François-René Rideau]

When booting into an encrypted disk, guix correctly prompts for an
encryption passphrase, but should the passphrase be somehow mistyped
(which happens more often than not for an appropriately long
passphrase on some devices' bad keyboards), guix drops to the scheme
repl, without any obvious way to usefully restart the process. The
only thing left to do is then to reboot and go through the lengthy
BIOS cycle again.

Could guix, like nix, offer the user many attempts to type the passphrase?

Maybe after 3 to 10 failed attempts, or an attempt using an empty
string, then dropping to the debugger makes sense—but even then, could
some message give a hint about how to do anything useful at the repl,
like restarting for instance?

NB: Using guix 437718442ca758a3857702cecfe5c80aa5df272b.

—♯ƒ • François-René Rideau • Co-Founder and President, MuKn.io
“If instead of teaching other people what government should be and
should do, you'd teach yourself what government actually is and does
do, you'd be a libertarian.”

bug#59508: mpv compiled without x11 support

[Ludovic Courtès]

Hi,

Saku Laesvuori  skribis:

> The mpv package from (gnu packages video) is compiled without x11
> support and fails with:
>
> [vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device
> [vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be 
> unavailable.
> [vo/gpu] Failed to commit ModeSetting atomic request (-13)
> [vo/gpu/opengl] Failed to set CRTC for connector 95: Permission denied

I believe this was fixed by commit
78f03567f44f704dfbc03cb64368aa42a01e78ad, though not by adding
‘--enable-x11’ (see ).

Anyway it definitely works for me on X11.  Could you confirm?

Thanks,
Ludo’.

bug#59508: mpv compiled without x11 support

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

On Tue Nov 22, 2022 at 8:33 PM GMT, Saku Laesvuori via Bug reports for GNU Guix 
wrote:
> I'm not sure  is that enough to make guix consider the package updated
> (though I would assume so), so I didn't prepare a patch. Anyway the fix
> is a trivial one line addition.

It is.

-- (

bug#59521: package installation fail when home dir contains a @

[Julien Lepiller]

Oh no, do we have a Texi injection vulnerability in Guix? :)

What I understand is that an error occurs when trying to show a hint to the 
user (display-hint in the backtrace). This calls texi->plain-text which 
transforms texinfo markup to text for displaying on a terminal. With your user 
name, it tries to read something like:

/home/~a/.guix-profile/etc/profile

Which is expanded into:

/home/u...@foo.bar/.guix-profile/etc/profile

And the @ is understood as texinfo markup but there is no @foo command in 
texinfo. How do we fix that though?

Le 23 novembre 2022 13:46:30 GMT+01:00, pof...@free.fr a écrit :
>Hello!
>
>I use the guix package manager on ubuntu 22.04.
>
>I have successfully installed fdm and mu packages but I got an error when 
>installing emacs package.
>
>My user is a domain user, the domain name is 'foo.bar' and then sssd use a 
>home directory like '/home/u...@foo.bar' which seems to cause that error.
>
>Installation log:
>$ LANG=C guix install emacs
>The following package will be installed:
>   emacs 28.2
>
>hint: Backtrace:
>  17 (primitive-load "/home/u...@foo.bar/.config/guix?")
>In guix/ui.scm:
>   2275:7 16 (run-guix . _)
>  2238:10 15 (run-guix-command _ . _)
>In ice-9/boot-9.scm:
>  1752:10 14 (with-exception-handler _ _ #:unwind? _ # _)
>In guix/status.scm:
>835:3 13 (_)
>815:4 12 (call-with-status-report _ _)
>In guix/store.scm:
>   1300:8 11 (call-with-build-handler _ _)
>   1300:8 10 (call-with-build-handler # ?)
>In guix/build/syscalls.scm:
>   1435:3  9 (_)
>   1402:4  8 (call-with-file-lock/no-wait _ _ _)
>In guix/scripts/package.scm:
>325:7  7 (build-and-use-profile _ "/var/guix/profiles/per-user/?" ?)
>In guix/ui.scm:
>312:5  6 (display-hint _ _)
>  1448:24  5 (texi->plain-text _)
>In texinfo.scm:
>  1132:22  4 (parse _)
>   980:31  3 (loop # (*fragment*) _ _ _)
>   967:36  2 (loop # #f # ?)
> 92:2  1 (command-spec _)
>In ice-9/boot-9.scm:
>  1685:16  0 (raise-exception _ #:continuable? _)
>
>ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>Throw to key `parser-error' with args `(#f "Unknown command" foo)'.
>
>
>

bug#59508: mpv compiled without x11 support

[Saku Laesvuori via Bug reports for GNU Guix]

The mpv package from (gnu packages video) is compiled without x11
support and fails with:

[vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device
[vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be 
unavailable.
[vo/gpu] Failed to commit ModeSetting atomic request (-13)
[vo/gpu/opengl] Failed to set CRTC for connector 95: Permission denied

when trying to play a video. This can be fixed by adding "--enable-x11"
to configure-flags (tested with guix shell).

I'm not sure  is that enough to make guix consider the package updated
(though I would assume so), so I didn't prepare a patch. Anyway the fix
is a trivial one line addition.

- Saku


signature.asc
Description: PGP signature

bug#59512: gtk-4.8.1 grafting fails

[Marek Paśnikowski via Bug reports for GNU Guix]

Evidence:

applying 20 grafts for gtk-4.8.1 ...
grafting '/gnu/store/vgm4f5k65kn6nwdlhziwzlgc0pli18d7-gtk-4.8.1-bin' -> 
'/gnu/store/ar0qphva0q53vavqqihgi4pq46f4z1z4-gtk-4.8.1-bin'...
grafting '/gnu/store/vp4ybqhxdrf4b2fk37c0s72g6iafqsmz-gtk-4.8.1-doc' -> 
'/gnu/store/7hfq1hbhfsmzjil433cjd8mngvxd05xv-gtk-4.8.1-doc'...
ERROR: In procedure fport_fill_input: Input/output error
builder for `/gnu/store/f8sjy3w9c1a9cdndkvflpbqnic7rik8g-gtk-4.8.1.drv' failed 
with exit code 1

Workaround:

guix system reconfigure --no-grafts

bug#59521: package installation fail when home dir contains a @

[pofman]

Hello!

I use the guix package manager on ubuntu 22.04.

I have successfully installed fdm and mu packages but I got an error when 
installing emacs package.

My user is a domain user, the domain name is 'foo.bar' and then sssd use a home 
directory like '/home/u...@foo.bar' which seems to cause that error.

Installation log:
$ LANG=C guix install emacs
The following package will be installed:
   emacs 28.2

hint: Backtrace:
  17 (primitive-load "/home/u...@foo.bar/.config/guix?")
In guix/ui.scm:
   2275:7 16 (run-guix . _)
  2238:10 15 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 14 (with-exception-handler _ _ #:unwind? _ # _)
In guix/status.scm:
835:3 13 (_)
815:4 12 (call-with-status-report _ _)
In guix/store.scm:
   1300:8 11 (call-with-build-handler _ _)
   1300:8 10 (call-with-build-handler # ?)
In guix/build/syscalls.scm:
   1435:3  9 (_)
   1402:4  8 (call-with-file-lock/no-wait _ _ _)
In guix/scripts/package.scm:
325:7  7 (build-and-use-profile _ "/var/guix/profiles/per-user/?" ?)
In guix/ui.scm:
312:5  6 (display-hint _ _)
  1448:24  5 (texi->plain-text _)
In texinfo.scm:
  1132:22  4 (parse _)
   980:31  3 (loop # (*fragment*) _ _ _)
   967:36  2 (loop # #f # ?)
 92:2  1 (command-spec _)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `parser-error' with args `(#f "Unknown command" foo)'.

bug#59515: nginx: Fails to start on boot while upstream service is not yet running

[mirai]

nginx-configuration has a 'shepherd-requirement' parameter that can be used here

bug#59519: LibreOffice 7.3.5.2 fails to build on i686-linux

[Ludovic Courtès]

The end of the log of the build for commit
2c9635cb47b0f52de635e93ebd137f1f7191c5fd looks like this:

--8<---cut here---start->8---
[build LNK] Executable/unopkg.bin
[build DEP] LNK:Library/libicglo.so
[build LNK] Library/libicglo.so
[build MOD] shell
[build BIN] toolkit
[build MOD] ucb
[build MOD] vcl
[build MOD] xmlhelp
[build MOD] toolkit
[build DEP] LNK:Library/libsimplecanvaslo.so
[build LNK] Library/libsimplecanvaslo.so
[build DEP] LNK:Library/libcairocanvaslo.so
[build LNK] Library/libcairocanvaslo.so
[build DEP] LNK:Library/liboglcanvaslo.so
[build LNK] Library/liboglcanvaslo.so
[build DEP] LNK:Library/libOGLTranslo.so
[build LNK] Library/libOGLTranslo.so
ld: 
/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/workdir/CxxObject/svtools/source/misc/imageresourceaccess.o:
 warning: relocation against 
`_ZThn20_N4cppu21ImplInheritanceHelperIN3utl19OInputStreamWrapperEJN3com3sun4star2io9XSeekableEEE7acquireEv'
 in read-only section `.text'
[build CMP] canvas/source/simplecanvas/simplecanvas
ld: 
/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/workdir/CxxObject/svtools/source/misc/imageresourceaccess.o:
 in function 
`svt::GraphicAccess::getImageStream(com::sun::star::uno::Reference
 const&, rtl::OUString const&)':
imageresourceaccess.cxx:(.text+0xabb): undefined reference to `non-virtual 
thunk to cppu::ImplInheritanceHelper::acquire()'
ld: 
/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/workdir/CxxObject/svtools/source/misc/imageresourceaccess.o:
 in function 
`svt::GraphicAccess::getImageXStream(com::sun::star::uno::Reference
 const&, rtl::OUString const&)':
imageresourceaccess.cxx:(.text+0x100e): undefined reference to `non-virtual 
thunk to cppu::ImplInheritanceHelper::acquire()'
[build CMP] slideshow/source/engine/opengl/ogltrans
[build CMP] canvas/source/opengl/oglcanvas
[build CMP] canvas/source/cairo/cairocanvas
ld: warning: creating DT_TEXTREL in a shared object
collect2: error: ld returned 1 exit status
make[1]: *** 
[/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/svtools/Library_svt.mk:20:
 
/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/instdir/program/libsvtlo.so]
 Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:289: build] Error 2
error: in phase 'build': uncaught exception:
%exception #< program: "make" arguments: ("-j" "24" 
"gtk_update_icon_cache=true") exit-status: 2 term-signal: #f stop-signal: #f> 
phase `build' failed after 1201.4 seconds
command "make" "-j" "24" "gtk_update_icon_cache=true" failed with status 2
builder for 
`/gnu/store/dcb1snan1sx0wdbdy7qq4jdn64is7mwf-libreoffice-7.3.5.2.drv' failed 
with exit code 1
@ build-failed 
/gnu/store/dcb1snan1sx0wdbdy7qq4jdn64is7mwf-libreoffice-7.3.5.2.drv - 1 builder 
for `/gnu/store/dcb1snan1sx0wdbdy7qq4jdn64is7mwf-libreoffice-7.3.5.2.drv' 
failed with exit code 1
--8<---cut here---end--->8---

Ludo’.

bug#59493: cuirass-remote-worker crash

[Mathieu Othacehe]

Hey,

> Oh I see.  It would be nice to avoid non-backward-compatible changes in
> the protocol so we can upgrade more smoothly.

Right, sorry. We should introduce a protocol version to avoid that in
the future.

> Fixed in Cuirass commit 9fb6f21d29c5398b35f4c1a77cf6c20f207c9ebb.

Awesome, thanks :)

> To me, ideally this would be either multi-threaded or Fiberized.  The
> latter would be more fruitful but what might be difficult is
> guile-simple-zmq integration with Fibers (but maybe not: zmq_getsockopt
> + ZMQ_FD lets us get the file descriptor of a socket).

I would prefer the multi-threaded approach if possible. While the
concept of Fiber is nice it adds another layer of complexity and
instability to those programs which are already hard to debug.

Mathieu

bug#59493: cuirass-remote-worker crash

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

>> 2022-11-21 14:27:24   1685:16  0 (raise-exception _ #:continuable? _)
>> 2022-11-21 14:27:24
>> 2022-11-21 14:27:24 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> 2022-11-21 14:27:24 Throw to key `match-error' with args `("match" "no 
>> matching pattern" (#vu8()))'.
>
> Yes this is because a new remote-server is running on Berlin and it
> sends an empty sequence at every connection:
> https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/commit/?id=fc1641381d2a8a0472a71ef5ad2b64361fb4

Oh I see.  It would be nice to avoid non-backward-compatible changes in
the protocol so we can upgrade more smoothly.

> All remote-workers must update, and I have deployed Cuirass
> 1.1.0-13.1341725 on all hydra workers + guix9p.
>
> I have been trying to deploy that to overdrive1 for two days but Berlin
> offloads the builds to kreuzberg which has some issues because a lot of
> builds are timeouting:

Done now!

--8<---cut here---start->8---
ludo@overdrive1 ~$ guix system describe
Generation 37   Nov 23 2022 15:58:08(current)
  file name: /var/guix/profiles/system-37-link
  canonical file name: /gnu/store/62dr875n7i30l375j87flbqfym78kddg-system
  label: GNU with Linux-Libre 6.0.9
  bootloader: grub-efi
  root device: /dev/sda3
  kernel: /gnu/store/p4impcxw8lba8600acrxs21lgzc06xzq-linux-libre-6.0.9/Image
  channels:
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  commit: 78f03567f44f704dfbc03cb64368aa42a01e78ad
  configuration file: 
/gnu/store/myvzd1kpw2pfzfj3krl4lzpcbqsdn48x-configuration.scm
--8<---cut here---end--->8---

Running the Shepherd 0.9.3 and all, wonderful.

>> (Stuttering is due to the unprotected use of ‘primitive-fork’: a
>> non-local exit in the child leads it to execute the same code as its
>> parent.  We should fix that, but should we really fork in the first
>> place?  :-))

Fixed in Cuirass commit 9fb6f21d29c5398b35f4c1a77cf6c20f207c9ebb.

> Right, this is problematic. I can't remember why I chose to fork.

One concern is that, in the Avahi case, we create at least one thread
before forking, and as we know that doesn’t work (as in: it might work
sometimes).  ZMQ may also create threads behind our back.

The parent doesn’t call ‘waitpid’ on its children, which isn’t great.

To me, ideally this would be either multi-threaded or Fiberized.  The
latter would be more fruitful but what might be difficult is
guile-simple-zmq integration with Fibers (but maybe not: zmq_getsockopt
+ ZMQ_FD lets us get the file descriptor of a socket).

Something to consider…

Thanks,
Ludo’.

bug#59515: nginx: Fails to start on boot while upstream service is not yet running

[Jonathan Brielmaier]

When I start my personal server with a radicale service behind a nginx
reverse proxy, nginx fails to start.

The relevant part in the log:
Nov 23 16:02:56 localhost shepherd[1]: Service networking has been started.
Nov 23 16:02:56 localhost shepherd[1]: Service radicale has been started.
Nov 23 16:02:56 localhost shepherd[1]: Service ssh-daemon has been started.
Nov 23 16:02:56 localhost shepherd[1]: [nginx] nginx: [emerg] host not
found in upstream "localhost:5232" in
/gnu/store/y29zl57pprwxbcxfx593s16456kxk99y-nginx.conf:15
Nov 23 16:02:56 localhost shepherd[1]: Failed to start nginx in the
background.

The config can be found here:
https://gitlab.com/jonsger/jonsger-guix/-/blob/master/config/baebia.scm#L116
```
(upstream-blocks (list
  (nginx-upstream-configuration
(name "radicale")
(servers (list "localhost:5232")
```

I wonder whats going wrong here. Is there a way to define that nginx
service should wait until radicale service is started?

~Jonathan

bug#46782:

[bbb ee]

There is a similar issue that is solved: https://issues.guix.gnu.org/59425

bug#59425: guix shell --container fails to mount host filesystem

[bbb ee]

Nice! That runs. Thank you. I will upgrade my guix.

Le mer. 23 nov. 2022 à 15:03, Ludovic Courtès  a écrit :

> Hi,
>
> bbb ee  skribis:
>
> > dev_1@dev_1 /mnt/recoverData$ guix shell --container coreutils -- echo
> Elmo
> > guix shell: error: mount: mount "/mnt/recoverData" on
> > "/tmp/guix-directory.ut68VE//mnt/recoverData": Invalid argument
> > ```
> >
> > ## environment
> > ```
> > $ uname -a
> > Linux dev_1 5.18.18 #1 SMP PREEMPT_DYNAMIC 1 x86_64 GNU/Linux
> > $ guix describe
> > Generation 9 Oct 22 2022 16:05:50 (current)
> >   guix 85aff4d
> > repository URL: https://git.savannah.gnu.org/git/guix.git
> > branch: master
> > commit: 85aff4de30686359ffb50845eb0930c0a18dc8ba
>
>
> I believe this was fixed in commit
> c585b4bc68813a351d6a87d19b9adf4041506355, see
> .
>
> Could you check something like:
>
>   guix time-machine --commit=c585b4bc68813a351d6a87d19b9adf4041506355 -- \
> shell -C coreutils
>
> ?
>
> Thanks in advance,
> Ludo’.
>

bug#59425: guix shell --container fails to mount host filesystem

[Ludovic Courtès]

Hi,

bbb ee  skribis:

> dev_1@dev_1 /mnt/recoverData$ guix shell --container coreutils -- echo Elmo
> guix shell: error: mount: mount "/mnt/recoverData" on
> "/tmp/guix-directory.ut68VE//mnt/recoverData": Invalid argument
> ```
>
> ## environment
> ```
> $ uname -a
> Linux dev_1 5.18.18 #1 SMP PREEMPT_DYNAMIC 1 x86_64 GNU/Linux
> $ guix describe
> Generation 9 Oct 22 2022 16:05:50 (current)
>   guix 85aff4d
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 85aff4de30686359ffb50845eb0930c0a18dc8ba


I believe this was fixed in commit
c585b4bc68813a351d6a87d19b9adf4041506355, see
.

Could you check something like:

  guix time-machine --commit=c585b4bc68813a351d6a87d19b9adf4041506355 -- \
shell -C coreutils

?

Thanks in advance,
Ludo’.

bug#59510: cuirass-remote-server: put-char encoding failed

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

> On Cuirass 1.1.0-13.1341725, the fetch workers are experimenting the
> following issue:

Is this a regression?

> 2022-11-22 00:28:15 In cuirass/scripts/remote-server.scm:
> 2022-11-22 00:28:15415:12  3 (_)
> 2022-11-22 00:28:15 387:7  2 (run-fetch _)
> 2022-11-22 00:28:15 2022-11-22T00:28:15 build succeeded: 
> '/gnu/store/wbnmp70x7hcwr9h5iw0v3w7waclw277x-rust-openssl-sys-0.9.75.drv'
> 2022-11-22 00:28:15 In unknown file:
> 2022-11-22 00:28:151 (display "2022-11-22T00:28:15 fetching 
> '/gnu/store/hl2dkk1ayavfxpydm5r12kjz201idk1g-rust-num-0.3.0.drv' from 
> http://141.80.167.165:5558\n; #)
> 2022-11-22 00:28:15 2022-11-22T00:28:15 build succeeded: 
> '/gnu/store/12dyhjzl0cy984jif7pp9w9hsrdgkcdf-rust-trust-dns-openssl-0.18.1.drv'
> 2022-11-22 00:28:15 2022-11-22T00:28:15 build succeeded: 
> '/gnu/store/j44ia9xffsggflgwg29q1l89vbga2y25-rust-trust-dns-https-0.18.1.drv'
> 2022-11-22 00:28:15 In ice-9/boot-9.scm:
> 2022-11-22 00:28:15 2022-11-22T00:28:15 build succeeded: 
> '/gnu/store/g9xa21wmxyk1sfra84pq3mx8hvlx10hh-rust-actix-server-config-0.1.2.drv'
> 2022-11-22 00:28:15   1685:16  0 (raise-exception _ #:continuable? _)
> 2022-11-22 00:28:15 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> 2022-11-22 00:28:15 Throw to key `encoding-error' with args `("put-char" 
> "conversion to port encoding failed" 84 # #\2)'.

The string passed to ‘display’ above is pure ASCII so I wonder how we
can get that exception, apart from having ‘current-error-port’ using a
non-ASCII-compatible encoding such as UTF-32.

Ludo’.

bug#59514: Stuck builds in Cuirass

[Mathieu Othacehe]

Hello Marius,

> Cuirass has a tendency to not notice when a build is finished, leaving
> it in a "running" state.
>
> The phenomenon can be observed by going to
>  and look at builds that are running for
> a suspiciously long time.

I suspect this is caused by https://issues.guix.gnu.org/59510 which
causes the worker threads to bail out.

We can probably merge those two issues. The
/var/log/cuirass-remote-server.log file on Berlin also indicates when
the build-succeeded or build-failed message is received by the server,
and how long the fetch from the worker took.

Thanks,

Mathieu

bug#59514: Stuck builds in Cuirass

[Marius Bakke]

Hi,

Cuirass has a tendency to not notice when a build is finished, leaving
it in a "running" state.

The phenomenon can be observed by going to
 and look at builds that are running for
a suspiciously long time.

Typically the build log will indicate that it has finished, yet Cuirass
is patiently waiting...and not scheduling further builds.

Restarting the builds typically get things going again.

I wrote a nasty script to automatically restart builds that are running
for >1 hour, but it's not a sustainable solution:

#!/usr/bin/env python3

# Restart stuck builds   TODO fix cuirass properly.

import requests
from bs4 import BeautifulSoup
import re

builds_page = "https://ci.guix.gnu.org/status;
builds_html = requests.get(builds_page).text

soup = BeautifulSoup(builds_html, "html5lib")
main = soup.find('main', {'id': 'content'})
table = main.find('table')

result = {}

for row in table.find_all('tr'):
data = row.find_all('td')
if len(data) > 0:
build_id = row.find('a').contents[0]
name = data[0].contents[0]
age = data[1].contents[0]
system = data[2].contents[0]
log = data[3]

result[build_id] = {'name': name, 'age': age, 'system': system}

age_re = re.compile("(\d+) (\w+) ago")
restart = []

for id in result.keys():
age = result[id]['age']
match = age_re.match(result[id]['age'])
if match is not None:  # "seconds ago"
digits = match.group(1)
time_unit = match.group(2)
if time_unit == "hours":
restart.append(id)
elif time_unit == "minutes" and int(digits) > 60:
restart.append(id)

certificate_file = "/home/marius/tmp/mbakke.cert.pem"
certificate_key = "/home/marius/tmp/mbakke.key.pem"

import time

print(f"Found {len(restart)} stuck builds..!")

for id in restart:
print(f"Going to restart {result[id]['name']} ({id}, running since 
{result[id]['age']})...")
requests.get(f"https://ci.guix.gnu.org/admin/build/{id}/restart;,
 cert=(certificate_file, certificate_key))
time.sleep(3)


signature.asc
Description: PGP signature

bug#59510: cuirass-remote-server: put-char encoding failed

[Mathieu Othacehe]

Hello,

On Cuirass 1.1.0-13.1341725, the fetch workers are experimenting the
following issue:

--8<---cut here---start->8---
2022-11-22 00:28:15 In cuirass/scripts/remote-server.scm:
2022-11-22 00:28:15415:12  3 (_)
2022-11-22 00:28:15 387:7  2 (run-fetch _)
2022-11-22 00:28:15 2022-11-22T00:28:15 build succeeded: 
'/gnu/store/wbnmp70x7hcwr9h5iw0v3w7waclw277x-rust-openssl-sys-0.9.75.drv'
2022-11-22 00:28:15 In unknown file:
2022-11-22 00:28:151 (display "2022-11-22T00:28:15 fetching 
'/gnu/store/hl2dkk1ayavfxpydm5r12kjz201idk1g-rust-num-0.3.0.drv' from 
http://141.80.167.165:5558\n; #)
2022-11-22 00:28:15 2022-11-22T00:28:15 build succeeded: 
'/gnu/store/12dyhjzl0cy984jif7pp9w9hsrdgkcdf-rust-trust-dns-openssl-0.18.1.drv'
2022-11-22 00:28:15 2022-11-22T00:28:15 build succeeded: 
'/gnu/store/j44ia9xffsggflgwg29q1l89vbga2y25-rust-trust-dns-https-0.18.1.drv'
2022-11-22 00:28:15 In ice-9/boot-9.scm:
2022-11-22 00:28:15 2022-11-22T00:28:15 build succeeded: 
'/gnu/store/g9xa21wmxyk1sfra84pq3mx8hvlx10hh-rust-actix-server-config-0.1.2.drv'
2022-11-22 00:28:15   1685:16  0 (raise-exception _ #:continuable? _)
2022-11-22 00:28:15 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
2022-11-22 00:28:15 Throw to key `encoding-error' with args `("put-char" 
"conversion to port encoding failed" 84 # #\2)'.
--8<---cut here---end--->8---

Thanks,

Mathieu

bug#55336: Graphical installer: Selecting a partition scheme always takes me back to the start

[Mathieu Othacehe]

Hello Simon,

> I just ran into this same problem with an old machine.

Interesting, thanks for the report.

> Disk image is: axygxkgkgcgbk2gjd6q521h85shp7hwf-image.iso from
> https://ci.guix.gnu.org/build/125952/details. 
>
> Please find attached some logs too: 

It looks like you experimented a crash (segfault or so), and the
backtrace is not really helpful here sadly.

What would be interesting is to share the core dump, either by copying
the /tmp/installer-core-dump file after the crash, or by using the dump
upload mechanism and reporting the crash id.

Thanks for your help,

Mathieu

bug#59493: cuirass-remote-worker crash

[Mathieu Othacehe]

Hello Ludo,

Thanks for gathering those information.

> 2022-11-21 14:27:24   1685:16  0 (raise-exception _ #:continuable? _)
> 2022-11-21 14:27:24
> 2022-11-21 14:27:24 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> 2022-11-21 14:27:24 Throw to key `match-error' with args `("match" "no 
> matching pattern" (#vu8()))'.

Yes this is because a new remote-server is running on Berlin and it
sends an empty sequence at every connection:
https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/commit/?id=fc1641381d2a8a0472a71ef5ad2b64361fb4

All remote-workers must update, and I have deployed Cuirass
1.1.0-13.1341725 on all hydra workers + guix9p.

I have been trying to deploy that to overdrive1 for two days but Berlin
offloads the builds to kreuzberg which has some issues because a lot of
builds are timeouting:

--8<---cut here---start->8---
\building of 
`/gnu/store/9jg75a8rvdz3qxcbbm95312rlc4hyi98-mrustc-0.10-2.597593a-checkout.drv'
 timed out after 3600 seconds of silence
build of 
/gnu/store/9jg75a8rvdz3qxcbbm95312rlc4hyi98-mrustc-0.10-2.597593a-checkout.drv 
failed
View build log at 
'/var/log/guix/drvs/9j/g75a8rvdz3qxcbbm95312rlc4hyi98-mrustc-0.10-2.597593a-checkout.drv.gz'.
cannot build derivation 
`/gnu/store/wavx7rl6h93fpmc46nggnhkyxm75lqa4-mrustc-0.10-2.597593a-checkout.drv':
 1 dependencies couldn't be built
--8<---cut here---end--->8---

> (Stuttering is due to the unprotected use of ‘primitive-fork’: a
> non-local exit in the child leads it to execute the same code as its
> parent.  We should fix that, but should we really fork in the first
> place?  :-))

Right, this is problematic. I can't remember why I chose to fork.

In the meantime, this should be fixed by updating to 1.1.0-13.1341725 so
we can close this one I guess.

Mathieu