home-syncthing-service-type wants /root paths, yet syncthing can work

[Sébastien Lerique]

Hi Guix! And dear helpers and devs,

I'm running into a weird failure of home-syncthing-service-type.

Running syncthing manually from the terminal works fine (here's an 
example log: ).


So I Ctrl-C syncthing, then add home-syncthing-service-type to my 
home-configuration 
 
(bottom lines).


After restarting, home-syncthing-service-type fails synchronizing 
because it bases all user folders inside /root, to which it doesn't have 
writing rights. This happens whether all syncthing configurations in 
`.local/state/syncthing` had been removed in the meantime or not. Here's 
a log: 


Could this be a bug? A mistake in the configuration files? In case it's 
useful, the system config is 
, and 
the versions:


sl@beoga ~> guix describe
Generation 3Jan 03 2024 23:08:17(current)
  guix 7b0863f
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 7b0863f07a113caef26fea13909bd97d250b629e
  guix-science 4e7057c
repository URL: https://github.com/guix-science/guix-science.git
branch: master
commit: 4e7057ceafba901f619bac068c74c6df158fd4ec
  nonguix 8956906
repository URL: https://gitlab.com/nonguix/nonguix
branch: master
commit: 8956906f6bed6709e71f0c26ed6a3620f40dc487

Best to all, and thanks for any answer!
Sébastien

Re: Emacs on a reMarkable

[Sébastien Lerique]

Hi,

On 21 Sep 2023 at 09:14, Simon Tournier  wrote:

> Other said, it seems something about “hash guix“ as probably recommended
> by the message ending “guix pull”. :-)
>

> Well, my guess is that the command “guix” points to the same executable
> (/usr/bin/guix) before and after “guix pull”.  Something like:
>
> # apt install guix
> # type -P guix
> /usr/bin/guix
>
> # guix pull
> # type -P guix
> /usr/bin/guix
>
> # hash guix
> # type -P guix
> ~/.config/guix/current/bin/guix
>

Aha indeed that makes perfect sense! I just re-checked and the two
"hints", including setting PATH after the first guix pull, are exactly
to the point:

root@vm-remarkable2:~# type -P guix
/usr/bin/guix
root@vm-remarkable2:~# GUIX_PROFILE="/root/.config/guix/current"
root@vm-remarkable2:~# . "$GUIX_PROFILE/etc/profile"
root@vm-remarkable2:~# type -P guix
/root/.config/guix/current/bin/guix
root@vm-remarkable2:~# hash guix  # only makes sense after updating PATH
root@vm-remarkable2:~# type -P guix
/root/.config/guix/current/bin/guix

>>> root@arm-vm:~# /usr/bin/guix pack -R -S /emacsbin=bin emacs-no-x
>>> /gnu/store/wpxqqdcslxxx9g9l9j847ifgh0xdlsfl-emacs-no-x-tarball-pack.tar.gz
>>>
>>> root@arm-vm:~# guix time-machine 
>>> --commit=65dcfb3f3865d08467da747041263fd22460d393 \
>>>-- pack -R -S /emacsbin=bin emacs-no-x
>>> /gnu/store/pszvzh7917kkf1cisxd46bx8vlac25zh-emacs-no-x-tarball-pack.tar.gz
>
> In these two commands, the Guix revision used for producing the tarball
> is explicitly set.  Commit 65dcfb3 is just a recent one – pick the one
> you prefer :-) – the point was to verify you get a different tarball for
> another revision than the “old” one and thus check if the issue is about
> an incorrect configured “guix” command.  Does it make sense?
>

Yes, thanks!

I like the way this reminds me of another aspect of the philosophy where
data and code are not separated. One is (or can be) the other, and which
"guix" binary (or script) is used matters.

Thanks again, and best,
Sébastien

Re: Emacs on a reMarkable

[Sébastien Lerique]

Hi!

On 18 Sep 2023 at 10:50, Simon Tournier  wrote:

> Re-reading, I am missing one point…
>
> [...]
>
> This wpxqqdcslxxx9g9l9j847ifgh0xdlsfl-emacs-no-x-tarball-pack.tar.gz is
> what you get before “guix pull”.  It means, it used the Guix revision
> packaged by Debian (Guix v1.4 I guess).
>
> Then after “guix pull”, I read
> pszvzh7917kkf1cisxd46bx8vlac25zh-emacs-no-x-tarball-pack.tar.gz which
> seems different.  This had been produced using Guix revision 65dcfb3.
>

Yes, but there's been a mix of `-R` and `-RR` in the summary I might
have made.

So I tried out from scratch to be sure, and I'm still surprised: On a
clean ARM VM made following
https://www.willhaley.com/blog/debian-arm-qemu/ here is my full setup
(apologies for the details):

1) Get Debian all up to date

--8<---cut here---start->8---
root@vm-remarkable2:~# nano /etc/sources.list
root@vm-remarkable2:~# cat /etc/sources.list
deb http://deb.debian.org/debian bookworm main
deb-src http://deb.debian.org/debian bookworm main

deb http://deb.debian.org/debian-security/ bookworm-security main
deb-src http://deb.debian.org/debian-security/ bookworm-security main

deb http://deb.debian.org/debian bookworm-updates main
deb-src http://deb.debian.org/debian bookworm-updates main

root@vm-remarkable2:~# apt update && apt upgrade
[...]
--8<---cut here---end--->8---

Copy the new vmlinuz and initrd.gz to the host's folder (as they're in
the launch code described in
https://www.willhaley.com/blog/debian-arm-qemu/ , so just in case), then
power off the VM and boot it again. Then:

  root@vm-remarkable2:~# apt install guix

Then reboot once more as the terminal would not give new lines. Then
build and check the file name before and after updating guix:

--8<---cut here---start->8---
root@vm-remarkable2:~# guix pull -l
guix pull: error: profile '/var/guix/profiles/per-user/root/current-guix' does 
not exist

root@vm-remarkable2:~# guix pack -RR -S /emacsbin=bin emacs-no-x
[... substitutes, grafts, builds ...]
/gnu/store/wpxqqdcslxxx9g9l9j847ifgh0xdlsfl-emacs-no-x-tarball-pack.tar.gz

root@vm-remarkable2:~# guix pull -l
guix pull: error: profile '/var/guix/profiles/per-user/root/current-guix' does 
not exist

root@vm-remarkable2:~# guix describe
guix describe: error: failed to determine origin
hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version
string is 1.4.0.

root@vm-remarkable2:~# guix pull
[... substitutes and builds ...]

root@vm-remarkable2:~# guix pull -l
Generation 1 Sep 20 2023 13:50:04 (current)
  guix 6bd17a0
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 6bd17a0806ad32d1493ac51a7443276f719c4224

root@vm-remarkable2:~# guix pack -RR -S /emacsbin=bin emacs-no-x
/gnu/store/wpxqqdcslxxx9g9l9j847ifgh0xdlsfl-emacs-no-x-tarball-pack.tar.gz
--8<---cut here---end--->8---

> Is it not the case?  Well, I guess you get:
>
> root@arm-vm:~# /usr/bin/guix pack -R -S /emacsbin=bin emacs-no-x
> /gnu/store/wpxqqdcslxxx9g9l9j847ifgh0xdlsfl-emacs-no-x-tarball-pack.tar.gz
>
> root@arm-vm:~# guix time-machine 
> --commit=65dcfb3f3865d08467da747041263fd22460d393 \
>-- pack -R -S /emacsbin=bin emacs-no-x
> /gnu/store/pszvzh7917kkf1cisxd46bx8vlac25zh-emacs-no-x-tarball-pack.tar.gz
>
> No?  Do you see something different?
>

So no, the tarball after guix pull is the same as the one from before,
unless I reboot the VM. After rebooting the VM, running the same guix
pack gives a different tarball (the actual one under guix 6bd17a0 I
guess):

--8<---cut here---start->8---
root@vm-remarkable2:~# guix pack -RR -S /emacsbin=bin emacs-no-x
/gnu/store/0cam5691zqp1r8wlv741c8im2rmhk2v1-emacs-no-x-tarball-pack.tar.gz
--8<---cut here---end--->8---

(Sorry for not having reused 65dcfb3, but the problem is independent of
that version.)


Could this just be due to a need for reboot after the first `guix pull`?


Cheers!
Sébastien

Re: Emacs on a reMarkable

[Sébastien Lerique]

Hi,

Apologies for the delay!

On 11 Sep 2023 at 18:26, Simon Tournier  wrote:

>> Now I have a final side question: after "guix pull" in the ARM VM, the
>> output of
>>
>>   guix pack -RR -S /emacsbin=bin emacs-no-x
>>
>> is still
>> "wpxqqdcslxxx9g9l9j847ifgh0xdlsfl-emacs-no-x-tarball-pack.tar.gz", i.e.
>> the same as before "guix pull". Is that normal?
>
> Hum, I do not know if it is normal.
>
> Could you share the output of “guix pull -l”?
>

--8<---cut here---start->8---
root@vm-remarkable2:~# guix pull -l
Generation 1 Sep 06 2023 17:05:27 (current)
  guix 65dcfb3
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 65dcfb3f3865d08467da747041263fd22460d393
--8<---cut here---end--->8---

Best,
Sébastien

Re: Emacs on a reMarkable

[Sébastien Lerique]

Hi Simon!

Thank you for the answer!

On 05 Sep 2023 at 16:18, Simon Tournier  wrote:

> Please consider I know nothing about reMarkable. :-)
>
>>   apt install guix
>>   guix pack -RR -S /emacsbin=bin emacs-no-x
>
> Here you are using emacs-no-x as it was with the release of Guix
> packaged by Debian.  Maybe you could run “guix pull” before running
> “guix pack”.
>

Aha, `guix pull` makes it work indeed! `emacs` or `emacs-no-x` made with
`-R` or `-RR` all work now.

> Just to be sure, could you share which revision (guix describe) of Guix
> you are using.  I mean, you are running emacs-no-x from which Guix
> revision?
>

After `guix pull` I'm at:

--8<---cut here---start->8---
root@arm-vm:~# guix describe
Generation 1Sep 06 2023 17:05:27(current)
  guix 65dcfb3
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 65dcfb3f3865d08467da747041263fd22460d393
--8<---cut here---end--->8---


In short, the setup now is:

1) Build and package Emacs in an ARM VM:

--8<---cut here---start->8---
root@arm-vm:~# apt install guix
root@arm-vm:~# guix pull
root@arm-vm:~# guix pack -R -S /emacsbin=bin emacs-no-x
--8<---cut here---end--->8---

2) Copy and un-tar it on the reMarkable, bind-mount /gnu, and run emacs either
through ssh or directly in Yaft:

--8<---cut here---start->8---
reMarkable: ~/ tar xf 
pszvzh7917kkf1cisxd46bx8vlac25zh-emacs-no-x-tarball-pack.tar.gz
reMarkable: ~/ mount -o bind /home/root/gnu /gnu
reMarkable: ~/ emacsbin/emacs
--8<---cut here---end--->8---


The challenge is that reMarkable doesn't provide a standard display, so
the terminal (Yaft) is still being developed (not by the company). Which
is why running some of the command lines can still be a challenge.

Let me know if anybody is interested in more details!


Now I have a final side question: after "guix pull" in the ARM VM, the
output of

  guix pack -RR -S /emacsbin=bin emacs-no-x

is still
"wpxqqdcslxxx9g9l9j847ifgh0xdlsfl-emacs-no-x-tarball-pack.tar.gz", i.e.
the same as before "guix pull". Is that normal?


Very best,
Sébastien

Emacs on a reMarkable

[Sébastien Lerique]

Dear Guix,

I hope this finds you all well!

I'm trying out ways to get emacs running on a reMarkable 2, as there are
now at least two shells that can run aside from the main binary: yaft
 and ReTerm
 (which may be ending soon as
yaft is making good progress). There are ongoing conversations with a
Discord community , channel called "rm2".

As Rust can't yet be cross-compiled (as far as I know), I set up an ARM
VM with Debian (following
), then

  apt install guix
  guix pack -RR -S /emacsbin=bin emacs-no-x

I copy and extract the package in reMarkable. Then, as / and /home are
different partitions on reMarkable, and / is too small, I follow the way
Entware packages are installed (see https://toltec-dev.org/ for
details), so:

  mount -o bind /home/root/gnu /gnu

At this point emacs-no-x runs perfectly when connecting through ssh and
running it there.

But when run from yaft (and from ReTerm), the following error appears,
and emacs (as well as the minimal bash) fails to run:

--8<---cut here---start->8---
/gnu/store/97xwzdsw9p6019dbml5mzf781c7avfkq-bash-minimal-5.1.8/bin/bash: error 
while loading shared libraries: libQt5Core.so.5: cannot open shared object 
file: No such file or directory
--8<---cut here---end--->8---

I can't find libQt5Core* in the tar.gz file, in /gnu/store, and not even
in the /gnu/store on my laptop where I use the guix packaging in
ubuntu/debian to use emacs. Am I maybe not searching properly with the
following?

  find /gnu/store -name "*libQt5*"

I also don't find *libQt5* when I package emacs instead of emacs-no-x. i
tried making the `env` outputs of the ssh shell and the yaft shell match
each other a little more, with no success (I can send them if it makes
sense).

Are there any ideas to figure out what could lead to this bug?

Thanks for everything you are and do!
Sébastien

Rock64 devicetree ovelay

[Sébastien Lerique]

Hi Guix!

I'm starting a small embedded project using a Rock64, successfully
running Guix on it (and keeping track of config at
https://gitlab.com/wehlutyk/matrixbox/).

It seems that the rock64 has a few design mistakes (as always I guess,
but in my case they matter), such that I would need to use a tiny
devicetree overlay to get access to the board's SPI device.

The pine64 forum has a couple threads on this:
- https://forum.pine64.org/showthread.php?tid=6282=40056#pid40056
- https://forum.pine64.org/showthread.php?tid=5522

Trying to use the kernel's configfs to set up an overlay (as in the
first thread above) doesn't seem possible, as the device-tree seems to
be only made available on board-maintained versions of the kernel:
https://stackoverflow.com/questions/50877808/configfs-do-not-mount-device-tree-overlays

My question: is there a standard way to change a devicetree using Guix's
bootloader+kernel tooling?

U-Boot's docs [0] mention either manually loading an overlay, or putting it
in a Flat Image Tree, but I haven't figured out how to do that with
Guix's tooling. I'm also not understanding whether I would need to do
this for both u-boot and the kernel, or if the first would be enough.

Do guixers have experience that could help here? Any hints or help would
be very welcome!

Happy hacking,
Sébastien


[0] 
https://u-boot.readthedocs.io/en/stable/usage/fdt_overlays.html#ways-to-utilize-overlays-in-u-boot


PS: in case anybody is interested, the project is to implement a Marble
Answering Machine  on top of Matrix, with
added message-sending buttons, to enable young children (and grown-ups)
to message friends and relatives while still avoiding screen exposure.

Re: Cross-compiling libfido2

[Sébastien Lerique]

On 26 Mar 2022 at 14:38, Pierre Langlois  wrote:

> Doing some grepping in Guix and a quick test, I think what you need to
> do is set PKG_CONFIG_EXECUTABLE to (pkg-config-for-target) when
> cross-compiling.  I can see that the libgit2 package does this for example

[...]

> Doing the same thing for libfido2 seems to fix it for me!
>

Thanks! That indeed works :). I just submitted a patch following this:
https://issues.guix.gnu.org/54595.

Thank again for the help, and happy hacking!
Sébastien

Cross-compiling libfido2

[Sébastien Lerique]

Hello Guix!

I'm trying to build a raw image for a rock64 board, from my x86_64
laptop (using Guix on PopOS), and bumping into some
packages seemingly not ready for cross-compilation.

I am adding `(service openssh-service-type ...)` to the base
gnu/system/images/rock64.scm (building the original rock64.scm config
works fine), and my build fails at libfido2.

My config is
https://gitlab.com/wehlutyk/matrixbox/-/blob/eacc326b8a7d41f3113e3768302c59687402a536/config.scm
and building libfido2 fails at the configure phase with

```
(...)

-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
-- Checking for one of the modules 'libcbor'
-- Checking for one of the modules 'libcrypto'
-- Checking for one of the modules 'zlib'
CMake Error at CMakeLists.txt:206 (message):
  could not find zlib

(...)
```

but no amount of moving pkg-config or zlib across inputs and
native-inputs changes anything.

In /tmp/guix-build-libfido2-1.9.0.drv-0/environment-variables, the only
pkg-config included in PATH is
pkg-config-aarch64-linux-gnu-0.29.2/bin/pkg-config, which makes me
suspect that the host pkg-config is needed in this case, and not found.

(Indeed, building manually from the left-over /tmp folder, using my normal
environment, and sourcing environment-variables, finds
/usr/bin/pkg-config, and cmake successfully configures the build; why do
report this and not a manual attempt on a clean environment? I couldn't
manage to ``guix shell`` into a container with cmake-minimal-cross as
cmake.)

Just in case, I played around with pkg-config-for-build which also
doesn't seem to be the solution.

Other packages relying on cmake and pkg-config, and prepared for
cross-compilation, don't seem to do anything different than libfido2
(e.g. cppzmq), so I'm out of things to try :)

Does anybody have an idea of what's going on? I could try to build
libfido2 without pkg-config, but maybe there is something simpler to try
out?

Thank you and happy hacking!
Sébastien

Introducing Guix to HPC at my institution

[Sébastien Lerique]

Dear all,

(I am reposting a question I asked on the guix-science list -- 
with a broader audience here I hope someone has an answer :) )


I am interested in introducing Guix to the HPC cluster at my 
institution, and it turns out they have user namespaces activated 
\o/. So I'm looking into getting things running as an unpriviliged 
user, to show other people how useful Guix can be (before 
approaching higher levels in the administration). Is it possible 
to install guix without being root?


I tried a few things, based on the following notes:

https://hpc.guix.info/blog/2017/09/reproducibility-and-root-privileges/
https://hpc.guix.info/blog/2017/10/using-guix-without-being-root/
http://issues.guix.gnu.org/34494

I am now following Guix's binary installation inside a user 
namespace. After decompressing the binary distribution of guix 
inside `~/local-guix`, my naïve next step was `unshare -mrf chroot 
~/local-guix 
gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16/bin/bash`. 
Then after setting $GUIX_PROFILE and sourcing 
`/root/.config/guix/current`, running `guix` warns with:


GC Warning: pthread_getattr_np or pthread_attr_getstack failed 
for main thread

GC Warning: Couldn't read /proc/stat

So my very limited knowledge of linux namespaces is hindering my 
next steps :). A few questions:


1. Should I do anything about the first warning? About the second 
warning: should I be binding `/proc` somehow?


2. Is it possible to create build users inside the user-namespaced 
chroot?


3. Last but not least: if I can create build users inside the 
chroot (question 2.), I suppose I can then run guix-daemon 
properly. How would I go about sharing this setup with other users 
on the cluster? Ideally I would like to have a non-priviliged 
build daemon that other users can call on. (Is there such a thing 
as kernel group namespaces?)


Is this the right way to go for running guix without being root, 
or is there a better way?


Thanks for any guidance you might provide!
Best,
Sébastien

Re: DBus with SDDM, Sway, and optionally fish

[Sébastien Lerique]

Hi Joshua,

Great that you have the same setup :)


With the two changes above (setting DBUS_SESSION_BUS_ADDRESS in
.profile, and patching wayland-session), apps can connect to 
dbus
inside Sway. But this seems extremely hacky. Is there maybe a 
better
way to make sure SDDM+Sway(+fish) is set up properly as a 
desktop

enviroment? Is it time to make a `sway-desktop-service-type`?



I'm all game for the above.  ^  I've been working on that for a 
while

now.  I've work coding on said problem on my video channel here:

https://video.hardlimit.com/my-library/video-playlists/06baf279-76ea-406a-a24d-2fcfefecbf35

I'll tag the below code.  It's the basic define-record-type* 
that people

may find useful in generating the sway config file.

I'm taking a break from writing the sway service, because I 
couldn't
figure out how to get the darn service to start.  So now I'm 
working on

and endlessh service.  (I actually posted a patch here:
https://lists.gnu.org/archive/html/guix-patches/2021-03/msg00672.html)

Here is my current sway-service.scm code


Thanks for sharing that! It's a bit too far from what I know for 
me to be able to contribute right now, but I'll be sure to come 
back to the thread if one day I have the time.


Sébastien

DBus with SDDM, Sway, and optionally fish

[Sébastien Lerique]

Dear all,

I use SDDM with (display-server "wayland"), and Sway as my main 
window manager.


My current configuration files are here:
- system configuration: 
 https://gitlab.com/wehlutyk/guix-config/-/blob/master/config.scm
- main profile: 
 https://gitlab.com/wehlutyk/guix-config/-/blob/master/sl-manifest.scm

- dot files: https://gitlab.com/wehlutyk/dotfiles

I've been struggling to get the DBUS_SESSION_BUS_ADDRESS variable 
to be set by SDDM, as it does not seem to set it by default. The 
current script that SDDM runs before starting Sway is 
https://github.com/sddm/sddm/blob/master/data/scripts/wayland-session 
, and I haven't found any other setup step which might be a source 
for enviroment variables inside Sway.


(Somehow environment variables set in 
`.config/environment.d/*.conf` also get set, but I don't know how 
or where that happens.)


In the default configuration, DBUS_SESSION_BUS_ADDRESS is 
therefore not set inside Sway, which leads to a number of problems 
(e.g. nautilus can't read the Trash system).


One can set the value of DBUS_SESSION_BUS_ADDRESS produced by 
`dbus-launch --sh-syntax` in `.profile` ( 
https://gitlab.com/wehlutyk/dotfiles/-/blob/master/.profile#L9 ), 
which is then sourced by `wayland-session` if the shell is bash. 
In my case my shell is fish, and the way `wayland-session` calls 
fish doesn't make it export the variables exported by `.profile`. 
For that a small patch to `wayland-session` works, which I ended 
up using: 
https://gitlab.com/wehlutyk/guix-config/-/commit/5105ab1bea7f8233de5dffc053f794ae69822acd


With the two changes above (setting DBUS_SESSION_BUS_ADDRESS in 
.profile, and patching wayland-session), apps can connect to dbus 
inside Sway. But this seems extremely hacky. Is there maybe a 
better way to make sure SDDM+Sway(+fish) is set up properly as a 
desktop enviroment? Is it time to make a 
`sway-desktop-service-type`?


Happy hacking,
Sébastien

Re: Python, poetry, and pandas

[Sébastien Lerique]

Hi Phil and Simon,

Thanks both for the input and advice (not citing it all here).

First the details. Simon wrote:

How did you installed poetry?  Via Guix or something else?
Which python packages do you have in your profile?
Is Guix System or Guix on foreign distro?


I'm using Guix System, and installed poetry via Guix. I have the 
following python packages installed: python, poetry, 
python-jupyterlab (from guix-science), and python-black. And 
guix-jupyter.



(I am aware that python-pandas is packaged for guix, but some
packages I will need down the road might not be; this project 
is
also in collaboration with non guix users, so I am looking for 
a

workflow which will work for them too.)


What are these packages?


I don't know yet, but I suspect the situation might crop up. Phil 
pointed to the PyPi importer, and I haven't used it yet, but it 
does seem to make things simpler if I need to add a package to 
Guix.


Phil wrote:
ImportError: libstdc++.so.6: cannot open shared object file: No 
such

file or directory


If it's only missing a reference to the underlying C++ library 
you could
install this library using Guix, or if you're using a foreign 
distro point to
the non-Guix version under /usr/lib which, at a guess, Poetry 
may have
picked up - but this is going to cause you more trouble down the 
line

than repackaging in Guix in my experience.


Yes, my experience with trying this for some Julia packages 
(GLMakie) convinced me not to try LD_LIBRARY_PATH hacks any more.


Now the broader view. Phil:
Guix offers pretty much everything that virtualenvs offers, but 
it does
things a little differently - you'll need to look at 
environments,
profiles, manifests, and use of a guix.scm to recreate (IMHO) a 
better

experience in the end.


I just set up a simple guix.scm for my current project, which 
indeed does the job, and of course provides all the great 
guarantees of Guix! Given the number of python packages currently, 
and the existence of the PyPi importer, I'm pretty convinced it 
covers my personal needs.


Now my wish is to find ways to collaborate with others on this 
kind of project, who unfortunately often use macOS. I was 
exploring the possibility of Guix on Darwin, but the best way to 
do that looks like running Guix System inside Docker:


http://logs.guix.gnu.org/guix/2021-03-11.log#044004
https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00111.html

So it seems that to collaborate with non-guix and non-GNU/Linux 
users, the options are 1) maintain a second environment management 
configuration (e.g. using poetry) to provide a stop-gap, or 2) 
convince colleagues to run Guix in Docker. The situation for 
Windows might be a bit better using the Linux Subsystem.


Thanks again all,
Sébastien

On 10 Mar 2021 at 19:02, Phil  wrote:


Hi Sébastien,

Sébastien Lerique writes:


Dear all,

(I am aware that python-pandas is packaged for guix, but some 
packages

I will need down the road might not be; this project is also in
collaboration with non guix users, so I am looking for a 
workflow

which will work for them too.)



Under the covers Poetry is just using regular Python virtualenvs 
I think.
These don't work well with Guix for a number of reasons - but in 
my
previous attempts to use them I found that Guix's use of 
PYTHONPATH
meant that virtualenvs where never isolated from packages 
installed by

Guix.

Guix offers pretty much everything that virtualenvs offers, but 
it does
things a little differently - you'll need to look at 
environments,
profiles, manifests, and use of a guix.scm to recreate (IMHO) a 
better

experience in the end.

When I started using Guix I went to some lengths to harmonize
virtualenvs and Guix - and others have made more substantial 
efforts
than I did - but you end up creating as many problems as you 
fix:

https://lists.gnu.org/archive/html/help-guix/2020-11/msg00237.html

If you search the mail archive a couple of other people have 
asked
similar questions to do with poetry, pyenv, pip, etc - they're 
all

interesting reading and easy to grep with those keywords:
https://lists.gnu.org/archive/html/help-guix/

The advice I was given at the time was don't mix package 
managers, and

in hindsight I'm glad repackaged what I needed under Guix.

I've packaged quite a few python libraries now, and most are 
pretty

trivial to do - if they are in PyPi you can just use this:

guix import pypi 

If you need a later version than Guix provides (eg pandas), my 
advice is
to use the ability to "inherit" the current definition in Guix 
and tweak
the version.  For Pandas I did this for a more recent version I 
needed

and all I had to do was disable 2 unit tests (which failed for a
non-Guix reason).

Apologies - not exactly the answer you want (I have a stab at 
that
below), but it's worth considering moving to Guix packaging 
exclusively

to keep your life simple.



 File
"/home/sl/.cache/pypoetry/virtualenvs/poetry-test-vOWX4_Vr-py3.8/lib

Python, poetry, and pandas

[Sébastien Lerique]

Dear all,

In the course of trying out poetry for data science projects on 
guix, I am running into the problem of some poetry-installed 
packages not finding their desired libraries. (See example below 
with pandas.) I suppose this is because poetry will download 
pre-built binary wheels which have pre-coded library paths.


If this is the problem, would there be any clean way to wrap those 
binary wheels, or patch poetry-on-guix to mandatorily rebuild 
binaries? (Would that make sense?)


(I am aware that python-pandas is packaged for guix, but some 
packages I will need down the road might not be; this project is 
also in collaboration with non guix users, so I am looking for a 
workflow which will work for them too.)


(I am also aware of guix-jupyter, but that is another topic I'd 
like to return to later as it needs some more bugsquashing for 
usability.)


Happy hacking!
Sébastien

#+BEGIN_SRC
$ poetry new poetry-test

Created package poetry_test in poetry-test
$ cd poetry-test/
$ poetry add pandas
Creating virtualenv poetry-test-vOWX4_Vr-py3.8 in 
/home/sl/.cache/pypoetry/virtualenvs

Using version ^1.2.3 for pandas

Updating dependencies
Resolving dependencies... (0.2s)

Writing lock file

Package operations: 4 installs, 9 updates, 0 removals

 • Updating pyparsing (2.4.6 
 /home/sl/.guix-profile/lib/python3.8/site-packages -> 2.4.7)
 • Updating six (1.14.0 
 /home/sl/.guix-profile/lib/python3.8/site-packages -> 1.15.0)
 • Updating attrs (19.3.0 
 /home/sl/.guix-profile/lib/python3.8/site-packages -> 20.3.0)
 • Updating more-itertools (8.2.0 
 /home/sl/.guix-profile/lib/python3.8/site-packages -> 8.7.0)
 • Updating numpy (1.17.3 
 /home/sl/.guix-profile/lib/python3.8/site-packages -> 1.20.1)
 • Updating packaging (20.0 
 /home/sl/.guix-profile/lib/python3.8/site-packages -> 20.9)

 • Installing pluggy (0.13.1)
 • Installing py (1.10.0)
 • Updating python-dateutil (2.8.1 
 /home/sl/.guix-profile/lib/python3.8/site-packages -> 2.8.1)
 • Updating pytz (2020.4 
 /home/sl/.guix-profile/lib/python3.8/site-packages -> 2021.1)
 • Updating wcwidth (0.1.8 
 /home/sl/.guix-profile/lib/python3.8/site-packages -> 0.2.5)

 • Installing pandas (1.2.3)
 • Installing pytest (5.4.3)
$ poetry run which python
/home/sl/.cache/pypoetry/virtualenvs/poetry-test-vOWX4_Vr-py3.8/bin/python
$ poetry run python
Python 3.8.2 (default, Jan  1 1970, 00:00:01)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more 
information.

import pandas

Traceback (most recent call last):
 File "", line 1, in 
 File 
 "/home/sl/.cache/pypoetry/virtualenvs/poetry-test-vOWX4_Vr-py3.8/lib/python3.8/site-packages/pandas/__init__.py", 
 line 51, in 

   from pandas.core.api import (
 File 
 "/home/sl/.cache/pypoetry/virtualenvs/poetry-test-vOWX4_Vr-py3.8/lib/python3.8/site-packages/pandas/core/api.py", 
 line 31, in 

   from pandas.core.groupby import Grouper, NamedAgg
 File 
 "/home/sl/.cache/pypoetry/virtualenvs/poetry-test-vOWX4_Vr-py3.8/lib/python3.8/site-packages/pandas/core/groupby/__init__.py", 
 line 1, in 
   from pandas.core.groupby.generic import DataFrameGroupBy, 
   NamedAgg, SeriesGroupBy
 File 
 "/home/sl/.cache/pypoetry/virtualenvs/poetry-test-vOWX4_Vr-py3.8/lib/python3.8/site-packages/pandas/core/groupby/generic.py", 
 line 65, in 

   from pandas.core.frame import DataFrame
 File 
 "/home/sl/.cache/pypoetry/virtualenvs/poetry-test-vOWX4_Vr-py3.8/lib/python3.8/site-packages/pandas/core/frame.py", 
 line 119, in 
   from pandas.core import algorithms, common as com, generic, 
   nanops, ops
 File 
 "/home/sl/.cache/pypoetry/virtualenvs/poetry-test-vOWX4_Vr-py3.8/lib/python3.8/site-packages/pandas/core/generic.py", 
 line 111, in 
   from pandas.core.window import Expanding, 
   ExponentialMovingWindow, Rolling, Window
 File 
 "/home/sl/.cache/pypoetry/virtualenvs/poetry-test-vOWX4_Vr-py3.8/lib/python3.8/site-packages/pandas/core/window/__init__.py", 
 line 1, in 

   from pandas.core.window.ewm import (  # noqa:F401
 File 
 "/home/sl/.cache/pypoetry/virtualenvs/poetry-test-vOWX4_Vr-py3.8/lib/python3.8/site-packages/pandas/core/window/ewm.py", 
 line 9, in 

   import pandas._libs.window.aggregations as window_aggregations
ImportError: libstdc++.so.6: cannot open shared object file: No 
such file or directory



#+END_SRC

Re: Flickering XWayland programs after resume from suspend

[Sébastien Lerique]

Hi!

I've been experiencing the same set of problems (as shown on the 
videos)
lately and I think it might be kernel/video drivers related. It 
started
to manifest when I upgraded linux-libre to one of the latest 
versions
(5.9 -> 5.10 not sure exactly which one was it). I've resolved 
it by

downgrading to linux-libre-5.4.

I have Lenovo Thinkad X240 with this graphics card: 00:02.0 VGA
compatible controller: Intel Corporation Haswell-ULT Integrated 
Graphics

Controller (rev 0b)


Yes, same machine and same graphics card. Makes sense, thank you 
very much for the hint!


Sébastien

Re: Flickering XWayland programs after resume from suspend

[Sébastien Lerique]

I use SDDM and Sway, and since a couple weeks I experience a 
bug where
several programs start flickering after I resume from suspend, 
to a
point that they are unusable. This happens at least on Emacs 
and
Firefox (I admit I haven't tested on IceCat), happens in both 
Sway and
Gnome on Wayland, and does not happen in Gnome on X11. Which 
makes me

think it is related to XWayland.


I'm using sway, and I do not have this issue.  I use Firefox and 
Emacs.
I've been running sway for days at a time.  At night I close the 
laptop

lip, and I keep computing for the next day.


On Emacs, some select letters (often 'o') are not rendered. 
Parts of
the windows are not refreshed when other parts are updated. 
Logging

out (to SDDM) and back in fixes the issue.


I do not have this issue.



Thanks for the report. It turns out this happens also on Gnome on 
X11, and on Waybar sometimes, so it's not an XWayland issue. Here 
are two videos of some of the behaviour (this is after a full 
update of system and profile): 
https://cloud.eauchat.org/s/T82QzNfSYHnbN6F


$ guix describe
Generation 70   Feb 28 2021 22:09:23(current)
 nonguix d28a3d8
   repository URL: https://gitlab.com/nonguix/nonguix
   branch: master
   commit: d28a3d8ae7c2f1bbf5887d8b619fedbf3c40e05c
 guix-science ffbe295
   repository URL: 
   https://github.com/guix-science/guix-science.git

   branch: master
   commit: ffbe29563147570d6bcb55cce756fe9742aa204e
 guix 372b15f
   repository URL: https://git.savannah.gnu.org/git/guix.git
   branch: master
   commit: 372b15f8625e7f20cafdba2677d4bf3f5eccc127

$ guix system describe
Generation 135  Mar 01 2021 07:43:31(current)
 file name: /var/guix/profiles/system-135-link
 canonical file name: 
 /gnu/store/pd0iqgi6mg3lk3pmc4lf5bc0l6a4vs1d-system

 label: GNU with Linux 5.10.18
 bootloader: grub-efi
 root device: /dev/mapper/cryptroot
 kernel: 
 /gnu/store/ff06m580x65x2xhl0sc3aawpf8g9m7b8-linux-5.10.18/bzImage

 channels:
   nonguix:
 repository URL: https://gitlab.com/nonguix/nonguix
 branch: master
 commit: d28a3d8ae7c2f1bbf5887d8b619fedbf3c40e05c
   guix-science:
 repository URL: 
 https://github.com/guix-science/guix-science.git

 branch: master
 commit: ffbe29563147570d6bcb55cce756fe9742aa204e
   guix:
 repository URL: https://git.savannah.gnu.org/git/guix.git
 branch: master
 commit: 372b15f8625e7f20cafdba2677d4bf3f5eccc127
 configuration file: 
 /gnu/store/spymhbc166529z63pdycxl59nnwlp2d4-configuration.scm


And here are my system and profile configs: 
https://gitlab.com/wehlutyk/guix-config (`config.scm` and 
`sl-manifest.scm`).


I thought it was a hardware issue for a moment, but logging out 
and back in fixes it. Any advice for where to start about this is 
much appreciated!


Best,
Sébastien

Flickering XWayland programs after resume from suspend

[Sébastien Lerique]

Dear all,

I use SDDM and Sway, and since a couple weeks I experience a bug 
where several programs start flickering after I resume from 
suspend, to a point that they are unusable. This happens at least 
on Emacs and Firefox (I admit I haven't tested on IceCat), happens 
in both Sway and Gnome on Wayland, and does not happen in Gnome on 
X11. Which makes me think it is related to XWayland.


On Emacs, some select letters (often 'o') are not rendered. Parts 
of the windows are not refreshed when other parts are updated. 
Logging out (to SDDM) and back in fixes the issue.


Has anyone been experiencing this? I'm not sure how to start 
troubleshooting, or what channels to use to explore this. Any help 
will be much appreciated!


Best,
Sébastien

Re: ebook reader recommendations?

[Sébastien Lerique]

On 04 Dec 2020 at 11:56, Edouard Klein  wrote:

Pierre Neidhardt writes:


Hi John,

Thanks for the hint.
I suppose this is the product you were talking about:

  https://remarkable.com/

Can you expand on how "hackable" it is?  Can we replace the 
software?

If not, what kind of access to the OS do we have?  Any link?


You basically can SSH into it. It's running Linux on ARM. As far 
as I know the UI and support
software is closed source, but there is a great community 
building open

source tools for the device.

https://github.com/reHackable/awesome-reMarkable


There's also the Parabola-rM project which replaces the entire 
reMarkable OS with a foss one.


http://www.davisr.me/projects/parabola-rm/

On a side-note, the same Davis also develops RCU 
, which I would love to manage 
to package for Guix, but my first attempts have led into deeper 
waters than I could solve, fixing problems with python-pyside-2. 
If anyone else is interested in this, let me know and we can get 
it done!


Cheers,
S.

Re: Profile's LD_LIBRARY_PATH by default

[Sébastien Lerique]

Hello!

On 29 Oct 2020 at 10:10, david larsson 
 wrote:

On 2020-10-28 13:49, Sébastien Lerique wrote:

[snip]
While running a racket program which uses OpenCV, I realised 
that my

LD_LIBRARY_PATH does not contain my user's profile libs. I have
`libopencv*.so` in `~/.guix-profile/lib/`, but running a racket
program which needs that fails:
```
$ racket capture.rkt
ffi-lib: couldn't open "libopencv_core.so" (libopencv_core.so: 
cannot

open shared object file: No such file or directory)
```
While running
```
env LD_LIBRARY_PATH=/home/sl/.guix-profile/lib/ racket 
capture.rkt

```
works.
(Also, this <http://0x0.st/ik3s.txt> is the output of `env
LD_DEBUG=libs racket capture.rkt`.)
Is this normal behaviour, i.e. that the path to dynamic libs 
installed
in my user profile should be manually configured in my shell 
startup
scripts? Should this not be included in 
`~/.guix-profile/etc/profile`?


I wondered the same, and got answer in the IRC #guix that 
setting
LD_LIBRARY_PATH is highly discouraged (unless you have a 
specific and
good reason to do so in a specific case - never globally). I a 
good explanation

about it here:
https://web.archive.org/web/20060719201954/http://www.visi.com/~barr/ldpath.html

A good example of how it can go wrong:

"In its startup script[a program called WidgetMan], it sets 
LD_LIBRARY_PATH to
point to its copy of Motif so it uses that one when it runs. As 
it happens,
WidgetMan is designed to launch other programs too. 
Unfortunately, when
WidgetMan launches other apps, they inherit the LD_LIBRARY_PATH 
setting and some
Motif based apps now break when run from WidgetMan because 
WidgetMan's Motif is
incompatible with (but the same library version as) the system 
Motif library.

Bummer!"


Yes I see that makes sense. Does this mean that one shouldn't 
install libraries in user profiles?


Or maybe that, if I were to package this racket program, then it 
would depend on `opencv` and set its required lib paths properly 
in its package definition (so work no matter if it's system-wide 
or in a user profile)?


Then, for development, is setting LD_LIBRARY_PATH still the only 
way without installing the lib system-wide?


(that's a lot of questions, apologies!)

Profile's LD_LIBRARY_PATH by default

[Sébastien Lerique]

Dear all,

This question could stem from a simpler example, but I think in 
this case it doesn't change much. So I'll go with my use case:


While running a racket program which uses OpenCV, I realised that 
my LD_LIBRARY_PATH does not contain my user's profile libs. I have 
`libopencv*.so` in `~/.guix-profile/lib/`, but running a racket 
program which needs that fails:


```
$ racket capture.rkt
ffi-lib: couldn't open "libopencv_core.so" (libopencv_core.so: 
cannot open shared object file: No such file or directory)

```

While running

```
env LD_LIBRARY_PATH=/home/sl/.guix-profile/lib/ racket capture.rkt
```

works.

(Also, this  is the output of `env 
LD_DEBUG=libs racket capture.rkt`.)


Is this normal behaviour, i.e. that the path to dynamic libs 
installed in my user profile should be manually configured in my 
shell startup scripts? Should this not be included in 
`~/.guix-profile/etc/profile`?


Thanks all, and best wishes!
Sébastien