Re: Emacs on a reMarkable
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
Hi, On Wed, 20 Sep 2023 at 20:25, Sébastien Lerique wrote: > 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 Here, you are using the “old” Guix revision packaged by Debian and installed as /usr/bin/guix. Well, “which guix“ or “type -P guix” should confirm or infirm this assumption… > 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. …and this output is a first clue that confirms the assumption above. > 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 Now, the “new” Guix revision is around. The question is… > root@vm-remarkable2:~# guix pack -RR -S /emacsbin=bin emacs-no-x > /gnu/store/wpxqqdcslxxx9g9l9j847ifgh0xdlsfl-emacs-no-x-tarball-pack.tar.gz …what the Guix revision that this “guix pack” refers to? What is the output of “which guix” or “type -P guix”? I guess it is /usr/bin/guix, isn’t it? Other said, it seems something about “hash guix“ as probably recommended by the message ending “guix pull”. :-) >> 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? > So no, the tarball after guix pull is the same as the one from before, > unless I reboot the VM. I think that’s because the Guix revision when typing “guix“ had not been refreshed after “guix pull”. IIRC, it needs to be after the first “guix pull”. > After rebooting the VM, running the same guix > pack gives a different tarball (the actual one under guix 6bd17a0 I > guess): Well, I guess reboot acts as “hash guix” here. :-) > Could this just be due to a need for reboot after the first `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 If not, also check that PATH is correctly configured, before and after pull. Cheers, simon
Re: Emacs on a reMarkable
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
Hi, Re-reading, I am missing one point… On Thu, 07 Sep 2023 at 11:52, Sébastien Lerique wrote: > 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--- [...] > 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? 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. Well, I am on x86_64, here what I get: --8<---cut here---start->8--- $ guix time-machine --commit=v1.4.0 -- pack -R -S /emacsbin=bin emacs-no-x /gnu/store/pndklr1v6h3lm2x2pks43hb0ra8fp8fb-emacs-no-x-tarball-pack.tar.gz $ guix time-machine --commit=65dcfb3f3865d08467da747041263fd22460d393 -- pack -R -S /emacsbin=bin emacs-no-x /gnu/store/kha2n6qzvyc178jkymf5ddapxr225yvj-emacs-no-x-tarball-pack.tar.gz --8<---cut here---end--->8--- And I guess your scenario reads, --8<---cut here---start->8--- root@arm-vm:~# apt install guix root@arm-vm:~# guix pack -R -S /emacsbin=bin emacs-no-x /gnu/store/wpxqqdcslxxx9g9l9j847ifgh0xdlsfl-emacs-no-x-tarball-pack.tar.gz root@arm-vm:~# guix pull root@arm-vm:~# guix pack -R -S /emacsbin=bin emacs-no-x /gnu/store/pszvzh7917kkf1cisxd46bx8vlac25zh-emacs-no-x-tarball-pack.tar.gz --8<---cut here---end--->8--- Is it not the case? Well, I guess you get: --8<---cut here---start->8--- 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 --8<---cut here---end--->8--- No? Do you see something different? Cheers, simon
Re: Emacs on a reMarkable
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
Hi, On Thu, 07 Sep 2023 at 11:52, Sébastien Lerique wrote: > Let me know if anybody is interested in more details! Cool if it worked! > 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”? Cheers, simon
Re: Emacs on a reMarkable
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
Re: Emacs on a reMarkable
Hi Sébastien, On Fri, 11 Aug 2023 at 22:26, Sébastien Lerique wrote: > I'm trying out ways to get emacs running on a reMarkable 2 Cool! 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”. > 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. \o/ > 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--- Sorry, I am missing from where it runs just above? > Are there any ideas to figure out what could lead to this bug? 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? Cheers, simon
