Unable to install from bootstrap script (package list fails to download from entware) #324
Comments
|
Hi @IvoryTinplate! Thanks for your report. This unrelated to your issue, but please note that Toltec support for version 2.6 is not yet complete (see #322). In the output you posted, $ /usr/bin/wget https://example.comThe command above will test the system wget, which is only used as a bootstrap to fetch another wget that is actually used for the rest of the install. (This is because the default wget lacks TLS support.) Could you also check that Toltec’s wget works? You can try the following commands to verify that: $ /usr/bin/wget https://toltec-dev.org/thirdparty/bin/wget-v1.21.1
$ echo "8798fcdabbe560722a02f95b30385926e4452e2c98c15c2c217583eaa0db30fc wget-v1.21.1" | sha256sum -c
$ chmod u+x wget-v1.21.1
$ ./wget-v1.21.1 https://example.comThanks! |
|
Hi @matteodelabre thanks for all your hard work on this. Appears that I'm getting the same error as @IvoryTinplate. Please see below for the output when I tried your commands... |
|
Hi @briankaemingk. Based on the output you provided, I think you’re seeing a separate issue. It appears that you’re using the testing branch, whose directory layout has recently been changed (see #310). To fix your issue, you have two choices:
All of this does not apply to @IvoryTinplate since their logs show that they’re using the stable branch. |
|
Thanks, I reverted back to the stable branch, and all is well.
A little background here...I was using draft launcher and rm2fb to launch a
number of apps, but I haven't been able to get anything to render on my rm2
after the reMarkable 2.6 update. I realize 2.6 isn't supported yet, but I
was hoping to try the test version to try to help the process along and get
in on the bleeding edge, hence switching to the test repository. However,
it seems like it's still a blank screen for me when I try to launch any
apps even on the testing branch.
Not sure how I can help, a little out of my element here, but happy to try
to contribute if needed. Thanks again!
…On Mon, Apr 5, 2021 at 9:51 AM Mattéo Delabre ***@***.***> wrote:
Hi @briankaemingk <https://github.com/briankaemingk>. Based on the output
you provided, I think you’re seeing a separate issue. It appears that
you’re using the testing branch, whose directory layout has recently been
changed (see #310 <#310>). To
fix your issue, you have two choices:
-
Revert back to the stable branch, which still has the old repository
layout. When we move the new layout to the stable branch, it will have an
automatic transition mechanism in place so you won’t have to edit your
configuration again. In general, the testing branch is only intended for
devs to test packages and features more thoroughly before they land in
stable. So if you wish to avoid similar issues in the future, I would
advise moving back to the stable branch (at the cost of having slightly
older packages). To do this change, you need to edit /opt/etc/opkg.conf
on your device, replace each occurrence of testing with stable, then
run opkg update && opkg upgrade.
-
Update your configuration for the new repository layout in testing. To
do this, you need to download the updated bootstrap script
<https://raw.githubusercontent.com/toltec-dev/toltec/testing/scripts/bootstrap/bootstrap>
(*not the one hosted at https://toltec-dev.org/bootstrap
<https://toltec-dev.org/bootstrap>*) and run it on your device with bash
bootstrap. The script will detect your existing install and
automatically update its configuration.
All of this does not apply to @IvoryTinplate
<https://github.com/IvoryTinplate> since their logs show that they’re
using the stable branch.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#324 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACXK2ZGY4DVNE5TIDDPGUA3THHTCDANCNFSM42IDWLKQ>
.
|
|
We’re still working on 2.6 support—you can track its status in #322. Currently, most apps using the Qt framework (e.g., draft) will not work on 2.6 unless recompiled using the 2.x version of our toolchain. But on the flip side, apps compiled with this version of the toolchain will not work on older system versions such as 2.5, so it’s not simply a matter of updating all of our the packages to use the new toolchain, since that would break support for users who have not received the update yet. |
|
Got it, thanks! I would love to try to cross compile draft with the latest
Docker toolchain and learn more, but, as I mentioned, I'm a little out of
my element. I just downloaded the docker qt toolchain with a `docker pull
ghcr.io/toltec-dev/qt:v2.0.1`... Is there a good next step or somewhere I
can read instructions or learn about how to proceed? I'll try to do my own
research as well..
…On Mon, Apr 5, 2021 at 11:33 AM Mattéo Delabre ***@***.***> wrote:
We’re still working on 2.6 support—you can track its status in #322
<#322>. Currently, most apps
using the Qt framework (e.g., draft) will not work on 2.6 unless recompiled
using the 2.x version of our toolchain
<https://github.com/toltec-dev/toolchain#version-matrix>. But on the flip
side, apps compiled with this version of the toolchain will not work on
older system versions such as 2.5, so it’s not simply a matter of updating
all of our the packages to use the new toolchain, since that would break
support for users who have not received the update yet.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#324 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACXK2ZAVSXQPN2JNRCBH2V3THH7A3ANCNFSM42IDWLKQ>
.
|
|
Here are some instructions to compile draft with toolchain v2.0.1. Make sure to install on your computer all the required dependencies listed here first.
|
|
Thank you! And forgive me for taking over this thread, but this is really helpful, hoping I can help pay it forward and contribute in the future.. Here's what I'm getting after verifying I've installed all the dependencies (docker, bsdtar, python, and the requirements.txt python files)... |
|
No problem. So this looks like an error with our Bash parser. Can you please share your Bash version and Python version? |
|
|
Unfortunately I can’t reproduce this using the same versions as you, but I’m not on macOS so that might be why. Could you please insert a |
|
Happy to, please see below.. I was also able to successfully run your make instructions on ubuntu, so I have a working copy of draft on my rm2, thanks again! Let me know what else I can do to help debug the parser issue.. |
|
Thanks for sharing more details. Your output says |
|
Very strange indeed... a |
|
This may be because our script launches Bash subprocesses with empty environments (in particular with empty env: Dict[str, str] = {}to import os
env: Dict[str, str] = {"PATH": os.environ["PATH"]} |
|
Indeed, that did the trick, thank you!
…On Wed, Apr 7, 2021 at 12:38 PM Mattéo Delabre ***@***.***> wrote:
This may be because our script launches Bash subprocesses with empty
environments (in particular with empty PATHs). So if you have customized
your PATH to point to a non-default location, the Toltec script may end up
launching a different Bash version. To try preserving the PATH value, can
you try changing line 97 of scripts/toltec/bash.py
<https://github.com/toltec-dev/toltec/blob/83dfeade32c7b8d0cf197ee3ac3bc3c64534ba1b/scripts/toltec/bash.py#L97>
from
env: Dict[str, str] = {}
to
import os
env: Dict[str, str] = {"PATH": os.environ["PATH"]}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#324 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACXK2ZFZ45VWAJ6WRPNMKCTTHSYBXANCNFSM42IDWLKQ>
.
|
Our current Python code spawns a Bash process as part of the recipe parsing process. To make sure the calling environment does not influence how the recipe is parsed, the subprocess is created with a clean environment. Unfortunately, this means the PATH variable is cleared and therefore that the subprocess may use a Bash binary different from the one in the user’s PATH. This PR changes that behavior and forwards the PATH value to the subprocess. See the following comment and its follow-ups for more context: <#324 (comment)> Test plan: Added a dummy `bash` binary (a file containing only `#!/usr/bin/env false`) to my PATH and checked that the recipe parsing fails (indicating that it invokes the dummy Bash and not the system one). Without the current PR, the parsing succeeds even if the parent PATH points to the dummy Bash.
|
@briankaemingk Thanks for helping me troubleshoot this! I opened the PR mentioned above to fix this in our codebase. @IvoryTinplate Sorry that we used your thread to diagnose a different issue. If your issue still persists, could you please provide more details as per my comment above (#324 (comment))? |
Our current Python code spawns a Bash process as part of the recipe parsing process. To make sure the calling environment does not influence how the recipe is parsed, the subprocess is created with a clean environment. Unfortunately, this means the PATH variable is cleared and therefore that the subprocess may use a Bash binary different from the one in the user’s PATH. This PR changes that behavior and forwards the PATH value to the subprocess. See the following comment and its follow-ups for more context: <#324 (comment)> Test plan: Added a dummy `bash` binary (a file containing only `#!/usr/bin/env false`) to my PATH and checked that the recipe parsing fails (indicating that it invokes the dummy Bash and not the system one). Without the current PR, the parsing succeeds even if the parent PATH points to the dummy Bash.
Our current Python code spawns a Bash process as part of the recipe parsing process. To make sure the calling environment does not influence how the recipe is parsed, the subprocess is created with a clean environment. Unfortunately, this means the PATH variable is cleared and therefore that the subprocess may use a Bash binary different from the one in the user’s PATH. This PR changes that behavior and forwards the PATH value to the subprocess. See the following comment and its follow-ups for more context: <toltec-dev#324 (comment)> Test plan: Added a dummy `bash` binary (a file containing only `#!/usr/bin/env false`) to my PATH and checked that the recipe parsing fails (indicating that it invokes the dummy Bash and not the system one). Without the current PR, the parsing succeeds even if the parent PATH points to the dummy Bash.
Our current Python code spawns a Bash process as part of the recipe parsing process. To make sure the calling environment does not influence how the recipe is parsed, the subprocess is created with a clean environment. Unfortunately, this means the PATH variable is cleared and therefore that the subprocess may use a Bash binary different from the one in the user’s PATH. This PR changes that behavior and forwards the PATH value to the subprocess. See the following comment and its follow-ups for more context: <#324 (comment)> Test plan: Added a dummy `bash` binary (a file containing only `#!/usr/bin/env false`) to my PATH and checked that the recipe parsing fails (indicating that it invokes the dummy Bash and not the system one). Without the current PR, the parsing succeeds even if the parent PATH points to the dummy Bash.
|
@IvoryTinplate Any update? |
|
I’m closing this issue for now. Please feel free to re-open it if the same issue happens again. |
Our current Python code spawns a Bash process as part of the recipe parsing process. To make sure the calling environment does not influence how the recipe is parsed, the subprocess is created with a clean environment. Unfortunately, this means the PATH variable is cleared and therefore that the subprocess may use a Bash binary different from the one in the user’s PATH. This PR changes that behavior and forwards the PATH value to the subprocess. See the following comment and its follow-ups for more context: <toltec-dev/toltec#324 (comment)> Test plan: Added a dummy `bash` binary (a file containing only `#!/usr/bin/env false`) to my PATH and checked that the recipe parsing fails (indicating that it invokes the dummy Bash and not the system one). Without the current PR, the parsing succeeds even if the parent PATH points to the dummy Bash.
Hello lovely people-
Many apologies if this has already been posted, but I couldn't find it.
I'm trying to install on my RM2 for the first time, using the bootstrap script, RM version 2.6.2.75. Here's the output:
Internet access from the remarkable seems fine, and I can download the entware package list from other devices on my LAN.
The text was updated successfully, but these errors were encountered: