all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Emacs on a reMarkable
@ 2023-08-11 13:26 Sébastien Lerique
  2023-09-05 14:18 ` Simon Tournier
  0 siblings, 1 reply; 9+ messages in thread
From: Sébastien Lerique @ 2023-08-11 13:26 UTC (permalink / raw)
  To: help-guix

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
<https://github.com/timower/rM2-stuff/tree/master/apps/yaft> and ReTerm
<https://github.com/i-am-shodan/ReTerm/> (which may be ending soon as
yaft is making good progress). There are ongoing conversations with a
Discord community <https://discord.gg/qEnCVcd>, 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
<https://www.willhaley.com/blog/debian-arm-qemu/>), 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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Emacs on a reMarkable
  2023-08-11 13:26 Emacs on a reMarkable Sébastien Lerique
@ 2023-09-05 14:18 ` Simon Tournier
  2023-09-07  9:52   ` Sébastien Lerique
  0 siblings, 1 reply; 9+ messages in thread
From: Simon Tournier @ 2023-09-05 14:18 UTC (permalink / raw)
  To: Sébastien Lerique, help-guix

Hi Sébastien,

On Fri, 11 Aug 2023 at 22:26, Sébastien Lerique <sl@eauchat.org> 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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Emacs on a reMarkable
  2023-09-05 14:18 ` Simon Tournier
@ 2023-09-07  9:52   ` Sébastien Lerique
  2023-09-11 16:26     ` Simon Tournier
  2023-09-18  8:50     ` Simon Tournier
  0 siblings, 2 replies; 9+ messages in thread
From: Sébastien Lerique @ 2023-09-07  9:52 UTC (permalink / raw)
  To: Simon Tournier; +Cc: help-guix

Hi Simon!

Thank you for the answer!

On 05 Sep 2023 at 16:18, Simon Tournier <zimon.toutoune@gmail.com> 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 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---


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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Emacs on a reMarkable
  2023-09-07  9:52   ` Sébastien Lerique
@ 2023-09-11 16:26     ` Simon Tournier
  2023-09-15 20:56       ` Sébastien Lerique
  2023-09-18  8:50     ` Simon Tournier
  1 sibling, 1 reply; 9+ messages in thread
From: Simon Tournier @ 2023-09-11 16:26 UTC (permalink / raw)
  To: Sébastien Lerique; +Cc: help-guix

Hi,

On Thu, 07 Sep 2023 at 11:52, Sébastien Lerique <sl@eauchat.org> 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

    


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Emacs on a reMarkable
  2023-09-11 16:26     ` Simon Tournier
@ 2023-09-15 20:56       ` Sébastien Lerique
  0 siblings, 0 replies; 9+ messages in thread
From: Sébastien Lerique @ 2023-09-15 20:56 UTC (permalink / raw)
  To: Simon Tournier; +Cc: help-guix

Hi,

Apologies for the delay!

On 11 Sep 2023 at 18:26, Simon Tournier <zimon.toutoune@gmail.com> 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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Emacs on a reMarkable
  2023-09-07  9:52   ` Sébastien Lerique
  2023-09-11 16:26     ` Simon Tournier
@ 2023-09-18  8:50     ` Simon Tournier
  2023-09-20 18:25       ` Sébastien Lerique
  1 sibling, 1 reply; 9+ messages in thread
From: Simon Tournier @ 2023-09-18  8:50 UTC (permalink / raw)
  To: Sébastien Lerique; +Cc: help-guix

Hi,

Re-reading, I am missing one point…

On Thu, 07 Sep 2023 at 11:52, Sébastien Lerique <sl@eauchat.org> 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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Emacs on a reMarkable
  2023-09-18  8:50     ` Simon Tournier
@ 2023-09-20 18:25       ` Sébastien Lerique
  2023-09-21  7:14         ` Simon Tournier
  0 siblings, 1 reply; 9+ messages in thread
From: Sébastien Lerique @ 2023-09-20 18:25 UTC (permalink / raw)
  To: Simon Tournier; +Cc: help-guix

Hi!

On 18 Sep 2023 at 10:50, Simon Tournier <zimon.toutoune@gmail.com> 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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Emacs on a reMarkable
  2023-09-20 18:25       ` Sébastien Lerique
@ 2023-09-21  7:14         ` Simon Tournier
  2023-09-22  7:14           ` Sébastien Lerique
  0 siblings, 1 reply; 9+ messages in thread
From: Simon Tournier @ 2023-09-21  7:14 UTC (permalink / raw)
  To: Sébastien Lerique; +Cc: help-guix

Hi,

On Wed, 20 Sep 2023 at 20:25, Sébastien Lerique <sl@eauchat.org> 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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Emacs on a reMarkable
  2023-09-21  7:14         ` Simon Tournier
@ 2023-09-22  7:14           ` Sébastien Lerique
  0 siblings, 0 replies; 9+ messages in thread
From: Sébastien Lerique @ 2023-09-22  7:14 UTC (permalink / raw)
  To: Simon Tournier; +Cc: help-guix

Hi,

On 21 Sep 2023 at 09:14, Simon Tournier <zimon.toutoune@gmail.com> 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


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2023-09-22  7:15 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-11 13:26 Emacs on a reMarkable Sébastien Lerique
2023-09-05 14:18 ` Simon Tournier
2023-09-07  9:52   ` Sébastien Lerique
2023-09-11 16:26     ` Simon Tournier
2023-09-15 20:56       ` Sébastien Lerique
2023-09-18  8:50     ` Simon Tournier
2023-09-20 18:25       ` Sébastien Lerique
2023-09-21  7:14         ` Simon Tournier
2023-09-22  7:14           ` Sébastien Lerique

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.