bug#48538: D-Bus services do not work on foreign distributions/non-user profiles

[Maxim Cournoyer]

Hi Leo & Simon,

Leo Prikler  writes:

> Am Donnerstag, den 27.05.2021, 21:59 +0200 schrieb zimoun:
>> Hi Leo,
>> 
>> On Thu, 27 May 2021 at 15:20, Leo Famulari  wrote:
>> > On Thu, May 27, 2021 at 08:54:49PM +0200, zimoun wrote:
>> > > ALSA lib conf.c:3725:(snd_config_hooks_call) Cannot open shared
>> > > library libasound_module_conf_pulse.so
>> > > (/gnu/store/z1iyvbvnkd7zkjxsx157n6qx2iwzxq7p-alsa-lib-
>> > > 1.2.4/lib/alsa-lib/libasound_module_conf_pulse.so: cannot open
>> > > shared object file: No such file or directory)
>> > [...]
>> > > Well, it means I have some misconfigured about ALSA, right?
>> > 
>> > Did you install alsa-plugins and alsa-plugins:pulseaudio ?
>> 
>> Do you mean
>> 
>>  guix environment --pure --ad-hoc jami-gnome dbus glib \
>>   alsa-plugins alsa-plugins:pulseaudio \
>>   -- dbus-run-session jami-gnome

We're drifting off topic for this issue (which is supposed to be about
D-Bus rather than Jami on foreign distributions :-)), but for the sake
of completion, the following works (tested on a Debian 10 i386 VM):

$ guix environment --ad-hoc jami-gnome dbus glib gtk+ openssl nss-certs \
  -- dbus-run-session jami-gnome

Apparently the FileChooser schema is provided by gtk+.  I also found out
that OpenSSL from Guix wants the SSL_* environment variable sets, so I
added the nss-certs and openssl packages to the mix (otherwise you
wouldn't have been able to search for contacts).

I think for gtk+/glib this can be improved by adding the
glib-or-gtk-build-system phases to the jami-gnome package definition.

HTH!

Maxim

bug#48682: recursive import between (gnu packages chez) and (gnu packages racket)

[raingloom]

On Thu, 27 May 2021 00:26:56 -0400
Philip McGrath  wrote:

> Hi, I've been working on Racket packaging. I haven't looked into this 
> much yet---hopefully I can tomorrow---but here are a few quick
> thoughts.
> 
> On 5/26/21 2:54 PM, raingloom wrote:
>  > I also haven't found any other mention of chez-scheme in racket.scm
>  > other than the line that imports it, which is weird, given that
>  > Racket  
> 
> This was my doing. When I added `(gnu packages racket)` in [1], I 
> adapted the patch from a racket.scm I'd been using to experiment
> ([2], also some branches of [3]): the changes that actually use (gnu
> packages chez) aren't ready to go yet, but apparently I left the
> import line in.
> 
> 
> On 5/26/21 2:54 PM, raingloom wrote:
>  > other than the line that imports it, which is weird, given that
>  > Racket is now built on Chez, so I'd expect it to use it as an
>  > input. I guess it's a bundled version? In any case I don't think I
>  > should just remove the import, because it will be needed
>  > eventually, so this issue needs to be fixed by then.  
> 
> Racket uses a fork of Chez Scheme: I described the situation in [4]. 
> Racket won't have upstream Chez as an input in the foreseeable, but, 
> from a packaging perspective, building Racket's Chez fork uses many
> of the same pieces as building upstream Chez. I think it may make
> sense to refactor out some of the common infrastructure, so both
> `(gnu packages racket)` and `(gnu packages chez)` could depend on
> some low-level module, but I'm not sure what the Guix-preferred way
> to organize things would be. (I'm mostly a Racketeer using Racket
> packaging to learn more about Guix.)
> 
> Here are some ways `(gnu packages chez)` and `(gnu packages racket)`
> are intertwined, in no particular order:
> 
>- `racket-minimal` should use the `nanopass` and `stex` origins
>   as `chez-scheme` does. (But it would be easiest to do this
>   once I've changed `racket-minimal` to build from the Git source,
>   rather than the bootstrapped tarball: I hope that will be soon.)
>   Some more of my not-quite-current thoughts on that at [5].
> 
>- The `chez-scheme` phases `unpack-nanopass+stex`, `configure`,
>  `prepare-stex`, and `install-doc` should be shared with Racket.
>  I think it would be better to put them in a build-side module and
>  actually share them, rather than to do tricky things to extract
>  their s-expression representation from
>  `(package-arguments chez-scheme)`. On the other hand, I think a
>  build system would be overkill: it would only build vanilla Chez
>  and Racket-flavored Chez.
> 
>- Racket-flavored Chez has added some backends that vanilla Chez
>  doesn't support (and can't be readily ported, unless upstream
> Chez eventually adopts Racket's changes to generating backends).
>  In particular, Racket-flavored Chez adds support for threading on
>  ARMv6 and support for aarch64 (which vanilla Chez doesn't
> support at all). I haven't thought at all deeply about this, but it
> might make sense for the default `chez-scheme` package on those
> architectures to be Racket-flavored Chez.
> 
>- We may in fact want to use Racket to bootstrap vanilla Chez.
> 
>  Chez has the usual problem with self-hosting compilers that you
>  need the old version to compile the new version. Specifically,
> you need "bootfiles", which encapsulate the Scheme-implemented portion
>  of Chez, compiled to machine code. Thus, (a) they are platform-
>  specific and (b) they need to agree precisely with the
> C-implemented part of Chez on the layout of datatypes and such.
> 
>  The vanilla Chez Git repository [6] has bootfiles for i686,
> x86_64, and (non-threaded) ARMv6. Once you've done a native build for
> one of those platforms, you can use it to cross-compile for any
> platform Chez supports (ppc32, various BSDs, etc.). But these are
> binary blobs. From a "trusting trust" perspective, it's especially
> striking if you consider that Chez Scheme was non-free software from
> 1984 to 2016, and the first libre release likewise needed the
> bootfiles of its ancestors. (However, building bootfiles is
> reproducible: Chez in fact builds them twice and errors if they aren't
>  byte-for-byte identical.)
> 
>  But Racket is able to simulate enough of Chez to (slowly)
>  compile the Chez compiler and generate bootfiles, providing a
> path to Chez from just a C compiler. Racket does its whole
> bootstrapping process regularly in CI, and I'm working on getting the
> Guix package to do likewise.
> 
>  Unfortunately, the Racket fork has diverged enough from vanilla
> Chez that the current Racket "cs-bootstrap" package [7] can't build
>  vanilla Chez, but I hope that the solution is just a matter of
>  walking through the Git history to find the right older version
> of the bootstrapping package, before the Racket fork's `#!base-rtd`
>  gained a vector of 

bug#48538: D-Bus services do not work on foreign distributions/non-user profiles

[Maxim Cournoyer]

Hi!

Leo Prikler  writes:

> PPS: Just adding gsettings-desktop-schemas didn't work.  "jami-gnome
> glib gnome" obviously works, but that's a little overkill (also it
> appears that you'll have to get credentials into this thing, which I
> haven't bothered worrying about).

No credentials are needed; it asked to register your username by
default, but pressing the 'skip' button will, well, skip that step and
go straight to creating your account (which is just a private key on
your device, basically).

Maxim

bug#48538: D-Bus services do not work on foreign distributions/non-user profiles

[Leo Prikler]

Am Donnerstag, den 27.05.2021, 21:59 +0200 schrieb zimoun:
> Hi Leo,
> 
> On Thu, 27 May 2021 at 15:20, Leo Famulari  wrote:
> > On Thu, May 27, 2021 at 08:54:49PM +0200, zimoun wrote:
> > > ALSA lib conf.c:3725:(snd_config_hooks_call) Cannot open shared
> > > library libasound_module_conf_pulse.so
> > > (/gnu/store/z1iyvbvnkd7zkjxsx157n6qx2iwzxq7p-alsa-lib-
> > > 1.2.4/lib/alsa-lib/libasound_module_conf_pulse.so: cannot open
> > > shared object file: No such file or directory)
> > [...]
> > > Well, it means I have some misconfigured about ALSA, right?
> > 
> > Did you install alsa-plugins and alsa-plugins:pulseaudio ?
> 
> Do you mean
> 
>  guix environment --pure --ad-hoc jami-gnome dbus glib \
>   alsa-plugins alsa-plugins:pulseaudio \
>   -- dbus-run-session jami-gnome
> 
> ?  If yes, there is still errors:
> 
> --8<---cut here---start->8---
> ** Message: 21:45:49.955: Jami GNOME client version: development
> ** Message: 21:45:49.956: git ref: unknown
> dbus-daemon[12101]: [session uid=1001 pid=12101] Activating service
> name='cx.ring.Ring' requested by ':1.1' (uid=1001 pid=12102
> comm="jami-gnome ")
> Jami Daemon 9.10.0, by Savoir-faire Linux 2004-2019
> https://jami.net/
> [Video support enabled]
> [Plugins support enabled]
> 
> dbus-daemon[12101]: [session uid=1001 pid=12101] Successfully
> activated service 'cx.ring.Ring'
> 21:45:50.388 os_core_unix.c !pjlib 2.10 for POSIX initialized
> No accounts to migrate
> 
> (jami-gnome:12102): libnotify-WARNING **: 21:45:50.693: Failed to
> connect to proxy
> QDBusMarshaller: type `VectorString' attempts to redefine basic D-BUS 
> type 'as' (QStringList) (Did you forget to call beginStructure() ?)
> QDBusMarshaller: type `MapStringVectorString' produces invalid D-BUS
> signature `a{s}' (Did you forget to call beginStructure() ?)
> QDBusMarshaller: type `QMap' produces
> invalid D-BUS signature `a{s}' (Did you forget to call
> beginStructure() ?)
> 
> (jami-gnome:12102): GLib-GIO-ERROR **: 21:45:50.807: Settings schema
> 'org.gtk.Settings.FileChooser' is not installed
> --8<---cut here---end--->8---
> 
> the ’--pure’ is not the issue.  It is probably different but it rings
> a
> bell with bug#47106.
> 
> 
It is different.  The cause of your issue is probably, that you're
lacking gsettings-desktop-schemas or something similar to it inside
your environment.  Perhaps we could try forming a "gnome-base"
metapackage, that propagates all of dbus, glib, gsettings-schemas etc.
for such purposes (maybe on wip-gnome first)?

Regards,
Leo

PS: Command just ran through

--8<---cut here---start->8---
** Message: 00:57:50.154: Jami GNOME client version: development
** Message: 00:57:50.154: git ref: unknown
No protocol specified

** (jami-gnome:27881): ERROR **: 00:57:50.217: Could not init clutter :
0
--8<---cut here---end--->8---

I'm sure you know about -E XAUTHORITY by now, but imo we should have a
switch similar to --networking for container operations.  

PPS: Just adding gsettings-desktop-schemas didn't work.  "jami-gnome
glib gnome" obviously works, but that's a little overkill (also it
appears that you'll have to get credentials into this thing, which I
haven't bothered worrying about).

bug#48213: offlineimap build fails

[zimoun]

Hi,

On Tue, 04 May 2021 at 16:39, Mark H Weaver  wrote:

>From the command line, you can simply do this:
>
>   guix build offlineimap --without-tests=python2-rfc6555
>
> Within an OS configuration, or within a profile "manifest" file (if you
> use "guix package --manifest", which is highly recommended), you can use
> the following Scheme expression in place of 'offlineimap':
>
>   (let ((transform (options->transformation
> '((without-tests . "python2-rfc6555")
> (transform offlineimap))

The package offlineimap will go sooner or later since Python 2 is EOL.
The migration from Py2 to Py3 is not clear [1] and the README [2] says:

  > As one of the maintainer of OfflineIMAP, I'd like to put my efforts into
  > [imapfw](http://github.com/OfflineIMAP/imapfw). **imapfw** is software in
  > development that I intend to replace OfflineIMAP with in the long term.
  >
  > That's why I'm not going to continue OfflineIMAP development. I'll continue
  > to maintain OfflineIMAP (fixing small bugs, reviewing patches and merging,
  > and rolling out new releases), but that's all.
  >
  > While I keep tracking issues for OfflineIMAP, you should not expect future 
support.
  >
  > You won't be left at the side. OfflineIMAP's community is large enough so 
that
  > you'll find people for most of your issues.
  >
  > Get news from the [blog][blog].
  >
  >  Nicolas Sebrecht. ,-)

IMHO, the transformation is the easiest to still have the package and
let the time to switch (to Offlinemap or something else).  For instance,



Note the package should always be available via inferiors.

All the best,
simon

1: 
2: 

bug#48564: ‘channel-with-substitutes-available’ makes assumptions about job names

[zimoun]

Hi,

On Wed, 26 May 2021 at 16:17, Mathieu Othacehe  wrote:

> (channels-with-substitutes-available
>  (list %default-guix-channel
>(channel
> (name 'guix-hpc)
> (url "https://gitlab.inria.fr/guix-hpc/guix-hpc.git;)))
>  (list "https://ci.guix.gnu.org;
>"https://guix.bordeaux.inria.fr;)
>  (specs "master" "guix-hpc"))

FWIW, I do not know if ’channels-with-substitutes-available’ should take
a list of channels, but it should take a list of substitute servers.
For instance, the user should be allowed to provide (list
"https://ci.guix.gnu.org; "https://bayfront.guix.gnu.org;) for the
channel %default-guix-channel.  And the default should be:

(channels-with-substitutes-available
  %default-guix-channel
  %default-substitute-urls)

Then, for multi-channels, the substitute servers should be a list of
list, IMHO.  Although, in practise, currently, there is less substitute
servers than channels. ;-)


Cheers,
simon

bug#48538: D-Bus services do not work on foreign distributions/non-user profiles

[Leo Famulari]

On Thu, May 27, 2021 at 09:59:19PM +0200, zimoun wrote:
> Do you mean
> 
>  guix environment --pure --ad-hoc jami-gnome dbus glib \
>   alsa-plugins alsa-plugins:pulseaudio \
>   -- dbus-run-session jami-gnome

Yes

> 
> ?  If yes, there is still errors:

Okay, but not from ALSA :) So, at least you have eliminated ALSA
problems from your test.

bug#48538: D-Bus services do not work on foreign distributions/non-user profiles

[zimoun]

Hi Leo,

On Thu, 27 May 2021 at 15:20, Leo Famulari  wrote:
> On Thu, May 27, 2021 at 08:54:49PM +0200, zimoun wrote:
>> ALSA lib conf.c:3725:(snd_config_hooks_call) Cannot open shared library 
>> libasound_module_conf_pulse.so 
>> (/gnu/store/z1iyvbvnkd7zkjxsx157n6qx2iwzxq7p-alsa-lib-1.2.4/lib/alsa-lib/libasound_module_conf_pulse.so:
>>  cannot open shared object file: No such file or directory)
> [...]
>>
>> Well, it means I have some misconfigured about ALSA, right?
>
> Did you install alsa-plugins and alsa-plugins:pulseaudio ?

Do you mean

 guix environment --pure --ad-hoc jami-gnome dbus glib \
  alsa-plugins alsa-plugins:pulseaudio \
  -- dbus-run-session jami-gnome

?  If yes, there is still errors:

--8<---cut here---start->8---
** Message: 21:45:49.955: Jami GNOME client version: development
** Message: 21:45:49.956: git ref: unknown
dbus-daemon[12101]: [session uid=1001 pid=12101] Activating service 
name='cx.ring.Ring' requested by ':1.1' (uid=1001 pid=12102 comm="jami-gnome ")
Jami Daemon 9.10.0, by Savoir-faire Linux 2004-2019
https://jami.net/
[Video support enabled]
[Plugins support enabled]

dbus-daemon[12101]: [session uid=1001 pid=12101] Successfully activated service 
'cx.ring.Ring'
21:45:50.388 os_core_unix.c !pjlib 2.10 for POSIX initialized
No accounts to migrate

(jami-gnome:12102): libnotify-WARNING **: 21:45:50.693: Failed to connect to 
proxy
QDBusMarshaller: type `VectorString' attempts to redefine basic D-BUS type 'as' 
(QStringList) (Did you forget to call beginStructure() ?)
QDBusMarshaller: type `MapStringVectorString' produces invalid D-BUS signature 
`a{s}' (Did you forget to call beginStructure() ?)
QDBusMarshaller: type `QMap' produces invalid 
D-BUS signature `a{s}' (Did you forget to call beginStructure() ?)

(jami-gnome:12102): GLib-GIO-ERROR **: 21:45:50.807: Settings schema 
'org.gtk.Settings.FileChooser' is not installed
--8<---cut here---end--->8---

the ’--pure’ is not the issue.  It is probably different but it rings a
bell with bug#47106.




Cheers,
simon

bug#48700: guix import fails with unexpected token

[zimoun]

Hi,

On Thu, 27 May 2021 at 15:08, "Philip Munksgaard"  wrote:
> Trying to to import futhark from hackage fails, when using the -r
> flag.

Thanks for the report.  I think it is the same as:




All the best,
simon.

bug#48538: D-Bus services do not work on foreign distributions/non-user profiles

[Leo Famulari]

On Thu, May 27, 2021 at 08:54:49PM +0200, zimoun wrote:
> ALSA lib conf.c:3725:(snd_config_hooks_call) Cannot open shared library 
> libasound_module_conf_pulse.so 
> (/gnu/store/z1iyvbvnkd7zkjxsx157n6qx2iwzxq7p-alsa-lib-1.2.4/lib/alsa-lib/libasound_module_conf_pulse.so:
>  cannot open shared object file: No such file or directory)
[...]
>
> Well, it means I have some misconfigured about ALSA, right?

Did you install alsa-plugins and alsa-plugins:pulseaudio ?

If you do that, then it should "just work" on other distros.

bug#48538: D-Bus services do not work on foreign distributions/non-user profiles

[zimoun]

Hi Maxim,


On Thu, 20 May 2021 at 13:18, Maxim Cournoyer  wrote:

> For this particular instance, a workaround is to run jami via the
> dbus-run-session utility, which launches the client in an ad-hoc d-bus
> session which knows about the dring D-Bus service (through the
> XDG_DATA_DIRS variable set by glib's search path).
>
> $ guix environment --pure --ad-hoc jami-gnome dbus glib \
>  -- dbus-run-session jami-gnome
>
> The glib package is added for its XDG_DATA_DIRS search path.  It works
> because the client doesn't really care about being able to talk to
> anything else but its daemon over D-Bus.

On Debian, using 014421e, I get:

--8<---cut here---start->8---
$ guix environment --pure --ad-hoc jami-gnome dbus glib \
   -- dbus-run-session jami-gnome
** Message: 20:50:31.130: Jami GNOME client version: development
** Message: 20:50:31.130: git ref: unknown
dbus-daemon[24024]: [session uid=1001 pid=24024] Activating service 
name='cx.ring.Ring' requested by ':1.1' (uid=1001 pid=24025 comm="jami-gnome ")
Jami Daemon 9.10.0, by Savoir-faire Linux 2004-2019
https://jami.net/
[Video support enabled]
[Plugins support enabled]

dbus-daemon[24024]: [session uid=1001 pid=24024] Successfully activated service 
'cx.ring.Ring'
20:50:31.556 os_core_unix.c !pjlib 2.10 for POSIX initialized
ALSA lib conf.c:3725:(snd_config_hooks_call) Cannot open shared library 
libasound_module_conf_pulse.so 
(/gnu/store/z1iyvbvnkd7zkjxsx157n6qx2iwzxq7p-alsa-lib-1.2.4/lib/alsa-lib/libasound_module_conf_pulse.so:
 cannot open shared object file: No such file or directory)
ALSA lib control.c:1471:(snd_ctl_open_noupdate) Invalid CTL hw:0
No accounts to migrate

(jami-gnome:24025): libnotify-WARNING **: 20:50:31.600: Failed to connect to 
proxy
QDBusMarshaller: type `VectorString' attempts to redefine basic D-BUS type 'as' 
(QStringList) (Did you forget to call beginStructure() ?)
QDBusMarshaller: type `MapStringVectorString' produces invalid D-BUS signature 
`a{s}' (Did you forget to call beginStructure() ?)
QDBusMarshaller: type `QMap' produces invalid 
D-BUS signature `a{s}' (Did you forget to call beginStructure() ?)

(jami-gnome:24025): GLib-GIO-ERROR **: 20:50:31.711: Settings schema 
'org.gtk.Settings.FileChooser' is not installed
--8<---cut here---end--->8---

Well, it means I have some misconfigured about ALSA, right?


Cheers,
simon

bug#47985: CentOS : SELinux is preventing /usr/lib/systemd/systemd from read access on the lnk_file current-guix

[josephenry]

Hi Ludo,

Thanks for your answer and sorry for the late response!

Actually I did :

```
sudo semodule -i 
/gnu/store/6rn4l3h0p9x0m615pp1ynlv9v0743kl3-guix-1.2.0/share/selinux/guix-daemon.cil
```

and then tried to use restorecon as stated in the doc :

```
sudo restorecon /gnu
```

but restarting guix didn't work, I am probably not doing it the right way...

What does that mean in the documentation :

Then relabel the file system with restorecon or by a different mechanism 
provided by your system.

Can someone provide some explanation about this?

Thanks

bug#48604: Linux-libre 5.12.5 freezes

[Leo Famulari]

On Thu, May 27, 2021 at 01:17:37PM -0400, Mark H Weaver wrote:
> FYI, linux-libre 5.12.4 also locked up on my Thinkpad X200, within a
> minute of launching an Xorg session, and within a couple of minutes of
> booting.  I only tried booting into that kernel once, and I didn't try
> any other 5.12.x series kernel.
> 
> For now, I've switched to the 5.10.x series.  5.10.39 and 5.10.40 have
> been working well for me.

I've started a meta-discussion that is related to this issue:

https://lists.gnu.org/archive/html/guix-devel/2021-05/msg00414.html

Mark, it would be great to hear your opinion on it.

bug#41625: [PATCH v2] offload: Handle a possible EOF response from read-repl-response.

[Maxim Cournoyer]

Hello again,

My previous strace output didn't follow the 'clone' syscall; the one
attached does.  It's compressed with lzip.



sshd-strace.out.lz
Description: Binary data

Thanks!

Maxim

bug#48604: Linux-libre 5.12.5 freezes

[Mark H Weaver]

Hi,

Yusuf Talha via Bug reports for GNU Guix  writes:
> hello.  i am using a librebooted thinkpad x200 laptop with gnu guix. 
> if i use the latest kernel on my system, my computer suddenly freezes
> without a reason after a while of usage.  it is probably a kernel
> panic.  older kernels don't have that problem.  i'd be glad if you fix
> this.  thank you for your attention.

FYI, linux-libre 5.12.4 also locked up on my Thinkpad X200, within a
minute of launching an Xorg session, and within a couple of minutes of
booting.  I only tried booting into that kernel once, and I didn't try
any other 5.12.x series kernel.

For now, I've switched to the 5.10.x series.  5.10.39 and 5.10.40 have
been working well for me.

Thanks for the report.

  Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#48414: phodav-2.5.drv' failed with exit code 1

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Solene wrote:
I was able to reproduce the build issue, it get fixed with these 
changes


Thank you, Solene!  Indeed it did.

I
- added a commit message matching our conventions[0],
- moved g-s-d to native-inputs
- pushed your patch as commit 
 847af45d0eba726418482b1b146a5ece2dbbb2c2.


With that, I'm closing this bug,

T G-R

[0]: 
 
which links to 
, 
but note that we've evolved our own style within the genre over 
the years.  I recommend simply reading the commit log to 
internalise it.


signature.asc
Description: PGP signature

bug#48414:

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

I'm a newcomer, what should I do now?

bug#41625: [PATCH v3] offload: Handle a possible EOF response from read-repl-response.

[Maxim Cournoyer]

Hi Ludo,

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'):

--8<---cut here---start->8---
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
close(6)= 0
pselect6(87, [3 4], NULL, NULL, NULL, NULL) = ? ERESTARTNOHAND (To be restarted 
if no handler)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=644, si_uid=0, 
si_status=255, si_utime=1, si_stime=0} ---
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 255}], WNOHANG, NULL) = 644
wait4(-1, 0xfa4d90e4, WNOHANG, NULL) = 0
rt_sigreturn({mask=[]}) = -1 EINTR (Interrupted system call)
pselect6(87, [3 4], NULL, NULL, NULL, NULL 
--8<---cut here---end--->8---

With the attached v3 patch, the corresponding output (still problematic)
was:

--8<---cut here---start->8---
$ ./pre-inst-env guix offload test /etc/guix/machines.scm overdrive1
guix offload: Testing 1 build machines defined in '/etc/guix/machines.scm'...
guix offload: got premature EOF from machine 'overdrive1.guix.gnu.org' from 
inferior '#' on port '#'; retrying connection
Backtrace:
In ice-9/boot-9.scm:
  1752:10 10 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In unknown file:
   9 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2  8 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  7 (_ #(#(#)))
In guix/ui.scm:
  2161:12  6 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10  5 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
  1747:15  4 (with-exception-handler # _ # _ # …)
In ice-9/threads.scm:
   288:21  3 (loop _)
In guix/scripts/offload.scm:
   719:29  2 (_ _)
   719:29  1 (_ _)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Wrong type to apply: 2
--8<---cut here---end--->8---

I haven't tried analyzing the strace output yet.

Maxim

>From c7b2ec1c58adf8c795df0a6aaf075dbc331f41e8 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer 
Date: Thu, 27 May 2021 08:44:44 -0400
Subject: [PATCH 1/2] offload: Parallelize machine check in offload test.

* guix/scripts/offload.scm (check-machine-availability): Refactor so that it
takes a single machine object.  Ensure the cleanup code is always run.
(check-machines-availability): New procedure.  Call
CHECK-MACHINES-AVAILABILITY in parallel, which improves performance (about
twice as fast with 4 build machines, from ~30 s to ~15 s).
---
 guix/scripts/offload.scm | 39 +--
 1 file changed, 25 insertions(+), 14 deletions(-)

diff --git a/guix/scripts/offload.scm b/guix/scripts/offload.scm
index 835078cb97..b0fd20e158 100644
--- a/guix/scripts/offload.scm
+++ b/guix/scripts/offload.scm
@@ -1,7 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2014, 2015, 2016, 2017, 2018, 2019, 2020 Ludovic Courtès 
 ;;; Copyright © 2017 Ricardo Wurmus 
-;;; Copyright © 2020 Maxim Cournoyer 
+;;; Copyright © 2020, 2021 Maxim Cournoyer 
 ;;; Copyright © 2020 Julien Lepiller 
 ;;;
 ;;; This file is part of GNU Guix.
@@ -53,6 +53,7 @@
   #:use-module (ice-9 regex)
   #:use-module (ice-9 format)
   #:use-module (ice-9 binary-ports)
+  #:use-module (ice-9 threads)
   #:export (build-machine
 build-machine?
 build-machine-name
@@ -684,7 +685,7 @@ daemon is not running."
   (leave (G_ "failed to import '~a' from '~a'~%")
  item name)
 
-(define (check-machine-availability machine-file pred)
+(define (check-machines-availability machine-file pred)
   "Check that each 

bug#48414:

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

Thank you very much for your effort
After 'guix pull' and 'guix package -u' not yet fixed.

bug#48649: Guix doesn't boot with LUKS root partition

[Juraj Hlista]

There has been some progress. I added this line:

(initrd-modules (cons* "i915" %base-initrd-modules))

to the config and it solved the issue with freezing the laptop.

Not sure how the i915 module is related to LUKS though.

Best Regards,
J

‐‐‐ Original Message ‐‐‐
On Tuesday, May 25, 2021 7:19 PM, Juraj Hlista  wrote:

> I tried to install Guix on unencrypted partition as well and it works.
>
> So to sum up my issue:
>
> /dev/nvme0n1p1 - 1.8TB, Linux (83)
>
> cryptsetup luksFormat /dev/nvme0n1p1
> cryptsetup open /dev/nvme0n1p1 luks
> mkfs.ext4 -L system /dev/mapper/luks
>
> mount LABEL=system /mnt
> mkdir /mnt/etc
>
> herd start cow-store /mnt
>
> (bootloader
> (bootloader-configuration
> (bootloader grub-bootloader)
> (target "/dev/nvme0n1")))
> (mapped-devices
> (list (mapped-device
> (source (uuid "..."))
> (target "luks")
> (type luks-device-mapping
> (file-systems
> (cons* (file-system
> (mount-point "/")
> (device "/dev/mapper/luks")
> (type "ext4")
> (dependencies mapped-devices))
> %base-file-systems)))
>
> guix system init /mnt/etc/config.scm /mnt
> reboot
>
> After inserting password to decrypt, I hit enter in boot menu, laptop freezes.
>
> Attached are pictures from GRUB.
>
> Best Regards,
> J
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, May 25, 2021 2:12 PM, Juraj Hlista ju...@juraj.me wrote:
>
> > I installed Guix again, there is just single 2TB encrypted partition with 
> > ext4 on top.
> > When booting, there is a prompt asking for a password to decrypt the 
> > partition, then there is the boot menu. When hitting enter the laptop gets 
> > stuck again just like before.
> > Seems like an issue with grub?
> > ‐‐‐ Original Message ‐‐‐
> > On Tuesday, May 25, 2021 1:19 PM, Tobias Geerinckx-Rice m...@tobias.gr 
> > wrote:
> >
> > > Juraj,
> > > Juraj Hlista 写道：
> > >
> > > > mount LABEL=system-root /mnt
> > > > mkdir /mnt/etc /mnt/boot
> > > > mount LABEL=system-boot /mnt/boot
> > >
> > > Guix System doesn't support a separate /boot partition. 
> > > Seehttp://issues.guix.gnu.org/48172.
> > > I'll leave this bug unmerged with that one until we're sure that's your 
> > > only issue:
> > >
> > > > I also tried to use unencrypted root partition (basically the > same as 
> > > > above, but without LUKS) and it works.
> > >
> > > Also with separate /boot? If so, maybe GRUB happens to look in the wrong 
> > > right place (/ instead of /boot), or something else is going on.
> > > Kind regards,
> > > T G-R

bug#47985: (No Subject)

[josephenry via Bug reports for GNU Guix]

Hi Ludo,

Thanks for your answer and sorry for the late response!

Actually I did :

``` sudo semodule -i 
/gnu/store/6rn4l3h0p9x0m615pp1ynlv9v0743kl3-guix-1.2.0/share/selinux/guix-daemon.cil
 ```

and then tried to use restorecon as stated in the doc :

``` sudo restorecon /gnu ```

but restarting guix didn't work, I am probably not doing it the right way...

What does that mean in the documentation :

Then relabel the file system with restorecon or by a different mechanism 
provided by your system. Can someone provide some explanation about this?

Thanks

bug#48414: [PATCH] gnu: phodav: add a missing input.

[Solene Rapenne via Bug reports for GNU Guix]

I was able to reproduce the build issue, it get fixed with these changes

---
 gnu/packages/gnome.scm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 7e0ee6d314..e15fa6df82 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -59,6 +59,7 @@
 ;;; Copyright © 2020, 2021 Andy Tai 
 ;;; Copyright © 2020, 2021 Sébastien Lerique 
 ;;; Copyright © 2021 Trevor Hass 
+;;; Copyright © 2021 Solene Rapenne 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -1180,6 +1181,7 @@ Library reference documentation.")
   ("pkg-config" ,pkg-config)))
(inputs
 `(("avahi" ,avahi)
+  ("gsettings-desktop-schemas" ,gsettings-desktop-schemas)
   ("libgudev" ,libgudev)
   ("libsoup" ,libsoup)))
(synopsis "WebDav server implementation using libsoup")
-- 
2.31.1

bug#41625: [PATCH v2] offload: Handle a possible EOF response from read-repl-response.

[Maxim Cournoyer]

Hi Marius,

Marius Bakke  writes:

> Maxim Cournoyer  skriver:
>
>>> Is running ‘guix offload test /etc/guix/machines.scm overdrive1’ on
>>> berlin enough to reproduce the issue?  If so, we could monitor/strace
>>> sshd on overdrive1 to get a better understanding of what’s going on.
>>
>> It's actually difficult to trigger it; it seems to happen mostly on the
>> first try after a long time without connecting to the machine; on the
>> 2nd and later tries, everything is smooth.  Waiting a few minutes is not
>> enough to re-trigger the problem.
>>
>> I've managed to see the problem a few lucky times with:
>>
>> --8<---cut here---start->8---
>> while true; do guix offload test /etc/guix/machines.scm overdrive1; done
>> --8<---cut here---end--->8---
>
> I used to be able to reproduce it by inducing a high load on the target
> machine and just let Guix keep trying to connect.  But now I did that,
> and set overload threshold to 0.0 for good measure, and Guix has been
> waiting patiently for two hours without failure.
>
> So AFAICT this bug has been fixed.  Perhaps Berlin or the Overdrive
> simply needs to be updated?

Ah!  Do you have root access to overdrive1?  It'd be interesting to
reconfigure it to update the guix-daemon and see if the problem
vanishes.

Thanks for the information!

Maxim

bug#41625: [PATCH v2] offload: Handle a possible EOF response from read-repl-response.

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

[...]

> I see.  So I’d say it’s a prerequisite (a patch that must come before)
> but not entirely the same thing.  I’m nitpicking!

Eh, it's okay :-).  Splitting changes into the right unit is a problem
that is akin to naming things; it's hard!  I welcome your suggestion.

> We should make sure it doesn’t trigger thread-safety issues in libssh or
> anything like that (running it repeatedly on a large machines.scm should
> give us some confidence).

It seems fine so far, but I've only tested in a loop with 4 build
machines.  When it nears completion I'll give it a shot on berlin.

[...]

> Yes, but note that this is just for ‘guix offload test’.  The actual
> code run while offloading will still fail badly.

Ah, thanks for pointing that; I somehow thought that this machine status
checking code was a prelude to every offloaded build.

[...]

>> I don't have a password set for my user on overdrive1, so can't attach
>> strace to sshd, but yeah, we could try to capture it and see if we can
>> understand what's going on.
>
> OK.

I'd be happy to try strace when your are available.  You can ping me on
the chat.  It's been more than 8 hours since I tried, so I should be
able to trigger the problem :-).

[...]

> Perhaps worth adding an ‘inferior’ and/or ‘port’ field.  That would
> allow the handler to present more information as to which inferior is
> failing.
>
> Maybe ‘premature-eof’ would be more accurate than ‘connection-lost’.

Good suggestions.  I'll implement them.

>> +   (format (current-error-port)
>> +   (G_ "connection to machine '~a' lost; 
>> retrying~%")
>> +   (build-machine-name machine))
>
> You can use ‘info’ instead of ‘format’.

That also.  Thanks!

On another note, I was able to 'exercise' the fix, and the exception is
raised but something fails with the following backtrace instead of being
retried:

--8<---cut here---start->8---
guix offload: Testing 1 build machines defined in '/etc/guix/machines.scm'...
connection to machine 'overdrive1.guix.gnu.org' lost; retrying
Backtrace:
In ice-9/boot-9.scm:
  1752:10 10 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In unknown file:
   9 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2  8 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  7 (_ #(#(#)))
In guix/ui.scm:
  2161:12  6 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10  5 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
  1747:15  4 (with-exception-handler # _ # _ # …)
In srfi/srfi-1.scm:
634:9  3 (for-each # 
(#< name: "overdriv…>))
In ice-9/eval.scm:
   191:35  2 (_ #(#(#(# 3 
#< na…> …) …) …))
Exception thrown while printing backtrace:
In procedure frame-local-ref: Argument 2 out of range: 1

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Wrong type to apply: 2
--8<---cut here---end--->8---

I haven't been able to pinpoint what yet.  Notice that in the above code
I've changed par-for-each by just for-each, doubting it might have
something to do with it, but it appears unrelated.

Thanks,

Maxim

bug#48331: [PATCH] guix: build: emacs-build-system: Make package.el aware of guix packages

[Ivan Sokolov]

> After updating the package-directory-list variable, functions like
> list-packages, describe-package become aware of packages installed by
> guix.

> ---
> This code is getting work done, but I'm not a very experienced elisp
> developer, so please review it thoroughly.

> +
> +(require 'package)
> +
> +;; Set `package-directory-list' to the value without elpa/ suffix
> +;; to match the structure of site-lisp directory of guix's emacs
> +;; build system.
> +;;;###autoload
> +(setq package-directory-list
> +  (list (string-remove-suffix "/elpa" (car package-directory-list
> +
>  (provide 'guix-emacs)

For future reference, this approach is absolutely unacceptable, no
package should modify customizable variables unless explicitly requested
by the user.

bug#48692: busctl call fails on elogind 243.7

[Andrew Tropin]

I try to use busctl to control the brightness of my screen:

$ busctl call org.freedesktop.login1 /org/freedesktop/login1/session/auto 
org.freedesktop.login1.Session SetBrightness "ssu" "backlight" 
"intel_backlight" 24242
Call failed: Connection timed out

It worked once, but at the same reported connection timed out, after
that it doesn't work and report the same connection timed out message.
After restart the situtation repeats.

I tried to build Guix System with elogind 246.10, the issue with busctl
is gone and it works fine without timed out message any number of times.

bug#48564: ‘channel-with-substitutes-available’ makes assumptions about job names

[Ludovic Courtès]

Heya,

Mathieu Othacehe  skribis:

>>> (define* (channel-with-substitutes-available chan url
>>>  #:key
>>>  (specification "master"))
>>
>
> I have fixed the evaluation complete? field issue with
> a2155f41f53eeb5000857e7160c5ad0916dc9bfa.

Good catch!

> Regarding the idea we had, things are I fear a little more complex. If
> we consider what you would like to achieve:
>
> (list (channel-with-substitutes-available
>%default-guix-channel
>"https://ci.guix.gnu.org;
>#:spec "master")
>   (channel-with-substitutes-available
>(channel
> (name 'guix-hpc)
> (url "https://gitlab.inria.fr/guix-hpc/guix-hpc.git;))
>"https://guix.bordeaux.inria.fr;
>#:spec "guix-hpc"))
>
>
> The first channel-with-substitutes-available could use the commit M1
> from the Savannah Guix master branch, while the second
> channel-with-substitutes-available could use the commit H1 from the
> HPC gitlab master branch.
>
> If the commit H1 is evaluated by the Inria Cuirass against an older
> Savannah Guix master commit let say M2, then "guix pull" will rebuild
> the guix-hpc derivation I guess.
>
> Maybe we need something that looks like:
>
> (channels-with-substitutes-available
>  (list %default-guix-channel
>(channel
> (name 'guix-hpc)
> (url "https://gitlab.inria.fr/guix-hpc/guix-hpc.git;)))
>  (list "https://ci.guix.gnu.org;
>"https://guix.bordeaux.inria.fr;)
>  (specs "master" "guix-hpc"))
>
> that would make sure to use a couple of Guix and HPC commits that
> have been evaluated together on the Inria Cuirass server.
>
> This looks more complex though :(

Hmm yeah.  Actually, in this example, it would make sense to take both
commits from guix.bordeaux.inria.fr, since that instance necessarily has
info about the two channels.  But yeah, it remains a bit complex.

Thanks,
Ludo’.