bug#41625: Sporadic guix-offload crashes due to EOF errors

[Maxim Cournoyer]

Oh, and for completion, here's a reproducer I used here to debug with my
low power offload machine:

--8<---cut here---start->8---
x(use-modules (guix scripts offload)
 (guix inferior)
 ((guix ssh) #:hide (open-ssh-session))

 (ice-9 match)
 (ssh popen))

(define machine (build-machine
 (name "tm")
 (port 22)
 (user "root")
 (systems (list "armhf-linux"))
 ;; ecdsa-sha2-nistp256
 (host-key "ssh-ecdsa-p256 
E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBIx32IqtlUr2VMypLItGSnmKzd0eJkgnzPkVbOZbn4HFQD5KvWB98t4IkT0PESjs+DDQfI/PwRENo3yqd5GjukA=")
 (parallel-builds 2)
 (compression "none")
 (private-key "/home/maxim/.ssh/id_rsa.1")))

(define open-ssh-session (@@ (guix scripts offload) open-ssh-session))

(define session (open-ssh-session machine 15))

(define repl-command '("guix" "repl" "-t" "machine"))

(define pipe (apply open-remote-pipe* session OPEN_BOTH repl-command))

;;; Hangs
;;;(port->inferior pipe)

(define rest (match (read pipe)
   (('repl-version 0 rest ...)
rest)))

(define %inferior-packages (@@ (guix inferior) %inferior-packages))

(define %inferior-package-table (@@ (guix inferior) %inferior-package-table))

(define inferior (@@ (guix inferior) inferior))
(define inferior-socket (@@ (guix inferior) inferior-socket))

(define result (inferior 'pipe pipe close (cons 0 rest)
 (delay (%inferior-packages result))
 (delay (%inferior-package-table result

(define send-inferior-request (@@ (guix inferior) send-inferior-request))

(send-inferior-request '(() repl-version 0 1 1) result)

(inferior-eval '(use-modules (guix)) result)

;;; Hangs!
;;t(inferior-eval '(use-modules (gnu)) result)

(send-inferior-request '(use-modules (gnu)) result)

(define socket (inferior-socket result))

;;Throw to key `match-error' with args `("match" "no matching pattern" #)'
;;(read-repl-response socket result)
;; -> guix using 100% cpu, reading package modules for ~ 1m30s

;;; guile-ssh returns  on timeout? (15 s) -> yes
(read socket)
--8<---cut here---end--->8---

I wish the Guile debugger was more capable; it'd have spared me the
above manual labor :-)

Maxim

bug#41625: Sporadic guix-offload crashes due to EOF errors

[Maxim Cournoyer]

Hello!

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> Now that I have root access to overdrive1, I could strace the sshd
>> process (I just did 'strace -p340', noting the process of sshd displayed
>> with 'herd status sshd'):
>>
>> pselect6(87, [3 4], NULL, NULL, NULL, NULL) = 1 (in [3])
>> accept(3, {sa_family=AF_INET, sin_port=htons(33262), 
>> sin_addr=inet_addr("66.158.152.121")}, [128->16]) = 5
>> fcntl(5, F_GETFL)   = 0x2 (flags O_RDWR)
>> pipe2([6, 7], 0)= 0
>> socketpair(AF_UNIX, SOCK_STREAM, 0, [8, 9]) = 0
>> clone(child_stack=NULL, 
>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
>> child_tidptr=0x8e0ef0e0) = 644
>> close(7)= 0
>> close(9)= 0
>> write(8, "\0\0\1\245\0", 5) = 5
>> write(8, "\0\0\1\234\nPort 22\nPermitRootLogin no\n"..., 420) = 420
>> close(8)= 0
>> close(5)= 0
>> getpid()= 340
>> getpid()= 340
>> getpid()= 340
>> getpid()= 340
>> getpid()= 340
>> getpid()= 340
>> getpid()= 340
>> pselect6(87, [3 4 6], NULL, NULL, NULL, NULL) = 1 (in [6])
>> read(6, "\0", 1)= 1
>> pselect6(87, [3 4 6], NULL, NULL, NULL, NULL) = 1 (in [6])
>> read(6, "", 1)  = 0
>
> OK, so it looks as if the client disconnected right away.  Hard to tell
> exactly what that happened.  :-/  Perhaps turning libssh debugging on on
> the client side could help (by uncommenting “#:log-verbosity 'protocol”
> in (guix ssh)).

I was able to better understand the problem after encountering it on
another low power ARM board.  It's about the guile-ssh/libssh timeout
causing a channel read to return EOF.

I have one example here where it hangs at the (inferior-eval
'(use-modules (gnu)) result)' step; Guix runs for about 1m30s,
apparently loading all the package modules. Perhaps my
GUILE_COMPILED_PATH is not set correctly and things are slower than
expected.  Not sure.

But what happens is that there's no output in the 15 s timeout that we
set for the SSH session elapses, and libssh's ssh_channel_read returns
0, which is the same value it returns when it encounters EOF.  Guile's
peek_byte_or_eof turn that zero into an EOF.  I've shared my analysis on
the guile-ssh bug tracker [0]

So information is lost at libssh's level, which is not so nice.  Knowing
exactly how that EOF come into the picture, we can handle it and produce
better diagnostic though.  I'll try reworking my original patch in that
direction.

Thanks,

Maxim

[0]  https://github.com/artyom-poptsov/guile-ssh/issues/29

bug#48907: Grafts cause discrepancies in debug symbols file names (debug symbols missing in GDB).

[Maxim Cournoyer]

Hi!

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> $ guix build qtdeclarative | xargs -I{} find -L {} -name *libQt5Qml.so.5*
>> substitute: updating substitutes from 'http://127.0.0.1:8080'... 100.0%
>> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
>> The following files will be downloaded:
>>/gnu/store/g1gxfbkyxilnx7s6mjdlj697y5n5wazn-qtdeclarative-5.15.2-debug
>>/gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2
>> substituting 
>> /gnu/store/g1gxfbkyxilnx7s6mjdlj697y5n5wazn-qtdeclarative-5.15.2-debug...
>> downloading from 
>> https://ci.guix.gnu.org/nar/lzip/g1gxfbkyxilnx7s6mjdlj697y5n5wazn-qtdeclarative-5.15.2-debug
>>  ...
>>  qtdeclarative-5.15.2-debug  94.9MiB1.2MiB/s 
>> 01:21 [##] 100.0%
>>
>> The following graft will be made:
>>/gnu/store/djhcai9rixm2j3jlamwdhsgwgidg7w74-qtdeclarative-5.15.2.drv
>> applying 2 grafts for 
>> /gnu/store/djhcai9rixm2j3jlamwdhsgwgidg7w74-qtdeclarative-5.15.2.drv ...
>> grafting 
>> '/gnu/store/g1gxfbkyxilnx7s6mjdlj697y5n5wazn-qtdeclarative-5.15.2-debug' -> 
>> '/gnu/store/l3h4ka7v3j1yhik0f1phwch08a09p0bx-qtdeclarative-5.15.2-debug'...
>> grafting '/gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2' 
>> -> '/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2'...
>> updating '.gnu_debuglink' CRC in 
>> '/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/bin/qml'
>> updating '.gnu_debuglink' CRC in 
>> '/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/bin/q
>> [...]
>> updating '.gnu_debuglink' CRC in 
>> '/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/qt5/qml/QtQuick/Window.2/libwindowplugin.so'
>> updating '.gnu_debuglink' CRC in 
>> '/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/qt5/qml/QtTest/libqmltestplugin.so'
>> successfully built 
>> /gnu/store/djhcai9rixm2j3jlamwdhsgwgidg7w74-qtdeclarative-5.15.2.drv
>> /gnu/store/l3h4ka7v3j1yhik0f1phwch08a09p0bx-qtdeclarative-5.15.2-debug/lib/debug/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/libQt5Qml.so.5.15.2.debug
>> /gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/libQt5Qml.so.5.15.2
>> /gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/libQt5Qml.so.5
>> /gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/libQt5Qml.so.5.15
>>
>>
>> So far so good.  The file hierarchy under the debug output matches the
>> actual shared library file name.  Next, let's verify which qtdeclarative
>> shared libraries jami-qt is dynamically linked against:
>>
>> $ guix build jami-qt | tail -1 | xargs -I{} ldd {}/bin/.jami-qt-real | grep 
>> qtdeclarative
>> libQt5QuickWidgets.so.5 => 
>> /gnu/store/mjl02yma4r5xjark6d8pp5h2j0a2vccs-qtdeclarative-5.15.2/lib/libQt5QuickWidgets.so.5
>>  (0x7fb9e38a8000)
>> libQt5Quick.so.5 => 
>> /gnu/store/mjl02yma4r5xjark6d8pp5h2j0a2vccs-qtdeclarative-5.15.2/lib/libQt5Quick.so.5
>>  (0x7fb9dba47000)
>> libQt5QmlModels.so.5 => 
>> /gnu/store/mjl02yma4r5xjark6d8pp5h2j0a2vccs-qtdeclarative-5.15.2/lib/libQt5QmlModels.so.5
>>  (0x7fb9db9c3000)
>> libQt5Qml.so.5 => 
>> /gnu/store/mjl02yma4r5xjark6d8pp5h2j0a2vccs-qtdeclarative-5.15.2/lib/libQt5Qml.so.5
>>  (0x7fb9dae4e000)
>
> This is due to the fact that, when you run ‘guix build jami-qt’, the
> grafting derivation dismisses the “debug” output of qtdeclarative, since
> jami-qt does not depend on it.  That way it doesn’t have to
> build/download and graft qtdeclarative:debug.
>
> Conversely, when you run ‘guix build qtdeclarative’, it grafts both
> outputs of qtdeclarative.  Thus, this grafting derivation is different
> from the one jami-qt.drv depends on.
>
> This behavior was implemented in commit
> 482fda2729c3e76999892cb8f9a0391a7bd37119.  Not sure what a good solution
> would be.
>
> Thoughts?

Yikes!  This means that debugging with grafts (with the aid of debugging
symbols) is no longer possible, right?

I remember reading about a 2nd option to locate the separate debug
symbol files with GDB in info '(gdb) Separate Debug Files':


   * The executable contains a "build ID", a unique bit string that is
 also present in the corresponding debug info file.  (This is
 supported only on some operating systems, when using the ELF or PE
 file formats for binary files and the GNU Binutils.)  For more
 details about this feature, see the description of the '--build-id'
 command-line option in *note Command Line Options: (ld)Options.
 The debug info file's name is not specified explicitly by the build
 ID, but can be computed from the build ID, see below.

   [...]
   
   * For the "build ID" method, GDB looks in the '.build-id'
 subdirectory of each one of the global debug directories for a file
 named 'NN/.debug', where NN are the first 2 hex characters
 of the build ID bit string, 

bug#31663: dino: segfaults on message delivery since libsignal-protocol-c update

[Sarah Morgensen]

Hello Mark,

Mark H Weaver  writes:

> The update of 'libsignal-protocol-c' to 2.3.2 in commit
> 05ca7a916a54d32ae4603bcd90918fb19e907704 broke dino.  Since that update,
> dino now immediately segfaults whenever a message is sent or received
> using OMEMO.
>
> Note that upstream dino has its own copy of 'libsignal-protocol-c' in a
> submodule.  Our 'dino' package arranges to instead use our system copy
> of 'libsignal-protocol-c', and I'm glad for that.  Unfortunately, it no
> longer works.
>
> I tried updating 'dino' to the latest upstream commit
> (60982bff67809e62b43476b49e30a9bd37491930), but that didn't help.
>
>   Mark

It looks like this since got an upstream issue [0] and was fixed in dino
in 7012023d599 (around v0.1), so I'm closing this old bug.  (I also
verified that our dino version wants v2.3.3 of libsignal-protocol-c,
which is what we have.)  Please reopen if this is still an issue!

[0] https://github.com/dino/dino/issues/485

--
Sarah

bug#31652: Use of ‘keymap’ vs. ‘layout’ in manual

[Sarah Morgensen]

Hello all,

I found this old bug...

Ricardo Wurmus  writes:

> Alex Kost  writes:
>
>> Tobias Geerinckx-Rice (2018-05-30 05:49 +0200) wrote:
>>
>>> Guix,
>>>
>>> Grepping the manual for ‘keyboard layout’ will get you to section
>>> 6.1.4.1 (setting the layout temporarily during installation using
>>> loadkeys), but not 6.2.7.1 where you might learn about using
>>> console-keymap-service to make the change permanent.
>>>
>>> This bug is a reminder to myself to replace at least one occurrence of
>>> ‘keymap’ with the common term.
>>
>> Do you mean ‘layout’ is the common term?  "man loadkeys" mentions
>> "layout" only once, and "keymap" a lot.
>>
>> I think we can just put a reference to that section.  Maybe like this:
>>
>> diff --git a/doc/guix.texi b/doc/guix.texi
>> index 09749b15e..02425e791 100644
>> --- a/doc/guix.texi
>> +++ b/doc/guix.texi
>> @@ -8418,7 +8418,9 @@ loadkeys dvorak
>>  
>>  See the files under @file{/run/current-system/profile/share/keymaps} for
>>  a list of available keyboard layouts.  Run @command{man loadkeys} for
>> -more information.
>> +more information.  After installing GuixSD, you can set your default
>> +keyboard layout with @code{console-keymap-service} (@pxref{Base
>> +Services}).
>>  
>>  @subsubsection Networking
>
> This is fine.  We should also consider adding more @cindex entries to
> cover all terms that people might search for.  The index should guide
> people to the relevant places in the manual.

However, it seems the manual now primarily uses "keyboard layout" with
an entry in the index for "keymap".  This seems to resolve the original
issue, so I'm closing this bug.  Please reopen if this was in error.

Note also that when there is alternate terminology, you can use

  @cindex keymap @seeentry{keyboard layout}

to put a single entry in the index which says

  keymap: see keyboard layout

See (texinfo)Advanced Indexing for more info :)

--
Sarah

bug#50769: [core-updates?] meson-build-system should set introspection=false automatically.

[Maxime Devos]

User: guix
Usertags: meson
User: maximed
Usertags: things-to-clean-up-todo
Tags: easy

Hi guix,

There is currently no method for cross-compiling gobject introspection data
(see  and follow-ups).  As such, it is
at times necessary to explicitely disable gobject-introspection data generation.
For meson-build-system, this can be done by setting introspection=false or
introspection_data=false (possibly using 'disable' instead of 'false'.)  It 
would
be nice to automate this.  By inspecting meson.options it should be possible to
determine when this needs to be done, and whether 'disable' or 'false' should
be used.

I'll look into this myself eventually.

Greetings,
Maxime.



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

bug#50728: Update Pandoc (just on my machine)

[Maxim Cournoyer]

Hello,

vi...@riseup.net writes:

> I know that there is this issue:
>
> http://issues.guix.gnu.org/39798
>
> And it was closed because Guix wants to stay with the LTS version of
> Haskell.
>
> But I need to use some features that come in later versions of pandoc.
>
> A few of my static site generator projects break because I need features
> that come after 2.7.x, which is the version that Guix packages.
>
> Can someone explain to me how to package the latest pandoc just on my
> own computer?
>
> Thanks.

The first step is configuring a development setup as explained in "info
'(guix)Contributing" sections.

Then you'd want to update the version and source fields with the new
version details (guix hash -rx on the checkout or guix download
https://tarball-url) to retrieve the new hash.

Then you'd summarily review the new sources for important changes such
as a change to their licensing.  A Changelog or NEWS file can be helpful
to understand what has changed, if available.

Then you'd start iterating on building the new package with something
like:

$ ./pre-inst-env guix build pandoc

If it's your lucky day it'll build without any change; but if it's a
major update you might have to modify the inputs or even update them in
prior commits.

Good luck!

If you have further questions, please ask on the help-g...@gnu.org
mailing list.  I'll close this bug, as this tracker should remain focus
on actual bugs rather than update/packaging requests.

Thanks,

Maxim

bug#48796: Guix on Debian 11 - Cant run or find applications from Guix

[Maxim Cournoyer]

Hello,

bo0od  writes:

> Hi There,
>
> I have installed Guix package manager over debian bullseye 11 then i
> installed a package using guix (after running guix pull) with two
> ways: (x package i tried is icecat)
>
> guix install x
>
> sudo -i guix install x
>
> both of the commands worked but the x package has no icon nor i can
> run it using terminal.

There are two things that Guix does to help users correctly configure
their system so that Guix installed applications appear on PATH.

1. The guix-install.sh installation script installs a
/etc/profile.d/guix.sh script that configures the PATH when logging in:

--8<---cut here---start->8---
# cat /etc/profile.d/guix.sh 
# _GUIX_PROFILE: `guix pull` profile
_GUIX_PROFILE="$HOME/.config/guix/current"
export PATH="$_GUIX_PROFILE/bin${PATH:+:}$PATH"
# Export INFOPATH so that the updated info pages can be found
# and read by both /usr/bin/info and/or $GUIX_PROFILE/bin/info
# When INFOPATH is unset, add a trailing colon so that Emacs
# searches 'Info-default-directory-list'.
export INFOPATH="$_GUIX_PROFILE/share/info:$INFOPATH"

# GUIX_PROFILE: User's default profile
GUIX_PROFILE="$HOME/.guix-profile"
[ -L $GUIX_PROFILE ] || return
GUIX_LOCPATH="$GUIX_PROFILE/lib/locale"
export GUIX_LOCPATH

[ -f "$GUIX_PROFILE/etc/profile" ] && . "$GUIX_PROFILE/etc/profile"

# set XDG_DATA_DIRS to include Guix installations
export 
XDG_DATA_DIRS="$GUIX_PROFILE/share:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}"
--8<---cut here---end--->8---

It even set XDG_DATA_DIRS, which should allow integration with the GNOME
Shell and other graphical dashboards.

I suspect you didn't install Guix via this script?  If so, could you try
creating the above file, closing relogin in your graphical session and
report if it fixed things for you?

Perhaps we should more strongly recommend using this installation script
and/or augment the manual installation procedure to cover for the above
configuration.

A second thing that Guix does to help users configure their environ Guix
is to hinted at sourcing the profile, if the user ~/.guix-profile/bin
was not already in PATH, like so:


--8<---cut here---start->8---
# env PATH=/usr/local/bin:/bin guix install zile
guix install: warning: Consider running 'guix pull' followed by
'guix package -u' to get up-to-date packages and security updates.

The following package will be installed:
   zile 2.4.15

substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivation will be built:
   /gnu/store/015zpn0xl8fn2ff1l0vf69w127frp76a-profile.drv

0.1 MB will be downloaded
 zile-2.4.15  108KiB 97KiB/s 00:01 
[##] 100.0%
building CA certificate bundle...
building fonts directory...
building directory of Info manuals...
building database for manual pages...
building profile with 6 packages...
hint: Consider setting the necessary environment variables by running:

 GUIX_PROFILE="/root/.guix-profile"
 . "$GUIX_PROFILE/etc/profile"

Alternately, see `guix package --search-paths -p "/root/.guix-profile"'.
--8<---cut here---end--->8---

Didn't you see this on your terminal after installing the Guix
applications?

Thanks,

Maxim

bug#48796: Guix on Debian 11 - Cant run or find applications from Guix

[Maxim Cournoyer]

Hello,

Luke Burgess  writes:

>>If you type "source ~/.guix-profile/etc/profile"
>>from a Bash shell, it loads the needed
>>environment variable settings into that
>>shell instance,and henceforth you
>>should be able to run "icecat"
> Maybe I should have read and understood the GUIX manual better Maybe I
> should not be haphazardly putting together my config.scm files on the
> fly Maybe I shouldn't be using root bash to test modifications I plan
> to make to my config.scm files... Maybe running GUIX on the 6 bear metal
> computers I use it on was a bad idea and I should be using VMs... But this
> explanation just saved me...Some root shells working and others not
> working, boy was I confused???... and this just saved me ... Mark H Weaver,
> Thank you, Thank you Thank you.
> Just one little thing I might still be getting totaly wrong... given I know
> the classical lines:
> #GUIX_PROFILE="/root/.config"
> #. "$GUIX_PROFILE/etc/profile"
> What would this do differently in root, if anything?
> #source /root/.config/etc/profile
^ .config/guix/current/etc/profile ?

In any case, it doesn't matter if the user is root or something else,
it should work the same for any user.

Maxim

bug#46760: guix deploy doesn't seem to be authorizing the machine that is deploying to the remote

[Andrew Tropin]

On 2021-02-24 23:56, pkill9 wrote:

> I'm using the machine-ssh-configuration, I set `(authorize? #t)` which
> the manual states should authorize the deploying machine onto the
> remote host, but I get an error:
> ```
> guix deploy: error: unauthorized public key: (public-key...
> ```
>
> So I add to the OS definition:
>
> ```
>  (guix-configuration
>(authorized-keys (append `(,(local-file
> "/etc/guix/signing-key.pub")) %default-authorized-guix-keys
>
> ```
>
> Which makes the error go away. I'm under the impression however that
> the 'authorize? #t' field should be doing this without me needing to
> add it to the OS configuration.

`(authorize? #t)` seems working, it does `guix archive --authorize <
local-key` on remote machine before reconfiguring, but after
reconfiguration is finished the value of /etc/guix/acl is reset by
guix-service-type and for some reason the error message you mentioned
appears.  Despite the error message the new generation is created and
new configuration is applied.  It seems something like copying auxiliary
file to remote store happens after reconfiguration is finished.  Will
try to investigate that, when will have some free time.

For now I do the same trick with changing the configuration for
guix-service-type:
https://diode.zone/w/fJNN6ExYA35NC19BRiHw2L?start=37m5s


signature.asc
Description: PGP signature