Problem with repository on Ubuntu 20.04 #1466
Comments
|
Hi @dawidol! Thank you for reporting this issue to us! 🙂 Bintray has been discontinued, and we're working to create another Debian repository in ooni/probe-cli#314. I am confident we should complete this task in the next 1-2 days. Thank you for your patience. Cheers! |
|
We solved the technical issues and merged the related pull request (ooni/probe-cli#314). What now remains to do is to update the instructions explaining how to install OONI Probe on Debian. I suppose we should also notify users who have already installed the previous version and are stuck with the previous repository. We should discuss which is the best way to do that. |
|
Hi |
|
So, these are the new instructions (copied from the relevant ooni.org PR: ooni/ooni.org#863)
Would you mind testing them? Thank you! |
|
Hello. N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'http://deb.ooni.org unstable InRelease' doesn't support architecture 'arm64' I guess it is because i am using Ubuntu 20.04 on a Raspberry Pi 4. Since we want to run daily test on several test, we want to do it with cron on a computer available 24/7. Any other suggestion/idea that may work? Thanks again. |
In ooni/probe#1466, a user is asking about arm64 builds for Debian. We already had some code for that in #311. Let us adapt the code to the `./make` script to have arm64 builds.
The previous composition strategy was such that it was difficult to compose functions returning a value. This new composition strategy is better because it allows us to return values, which is definitely going to help us. Part of ooni/probe#1466.
The previous composition strategy was such that it was difficult to compose functions returning a value. This new composition strategy is better because it allows us to return values, which is definitely going to help us. Part of ooni/probe#1466.
The previous fix allowed us to return values directly from implementations of Engine. Here we take advantage of this possibility by immediately refactoring how backticks work. Part of ooni/probe#1466.
The previous fix allowed us to return values directly from implementations of Engine. Here we take advantage of this possibility by immediately refactoring how backticks work. Part of ooni/probe#1466.
Further simplifies working with the environment. Part of ooni/probe#1466.
Further simplifies working with the environment. Part of ooni/probe#1466.
After all the refactoring done so far, we can run checks directly inside of `make`, because we have auto-cleanup, temporary environments and we don't need wrapper scripts anymore. Part of ooni/probe#1466.
After all the refactoring done so far, we can run checks directly inside of `make`, because we have auto-cleanup, temporary environments and we don't need wrapper scripts anymore. Part of ooni/probe#1466.
In ooni/probe#1466, a user is asking about arm64 builds for Debian. We already had some code for that in #311. Let us adapt the code to the `./make` script to have arm64 builds.
In ooni/probe#1466, a user is asking about arm64 builds for Debian. We already had some code for that in #311. Let us adapt the code to the `./make` script to have arm64 builds. While there, also adapt the code for darwin and windows.
Just consistency. There was no clear semantic regarding why sometimes I was using __name and sometimes _name. So prefer _name everywhere. Occurred to me while working on ooni/probe#1466.
|
It should be working now! I've just installed |
We're still working on ooni/probe#1466. The idea here is to teach the GH action for Linux to publish the debian package for arm64. When this is done, we can cleanup legacy build scripts and GH actions, because there is no remaining use case for them: we now build everything using the `./make` tool.
More cleanup after ooni/probe#1466
More cleanup after ooni/probe#1466
|
@dawidol, I am going to close this issue. Please, let us know if you have other issues with using OONI on arm64. Cheers! |
|
As far as project management/self-tracking is concerned: I have also started additional work to package for armv7 and 386, while I was touching this part of the codebase. This effort, though, should continue in #1334. |
|
Hi @bassosimone thanks you for your work and support, everything is working now, testing from latin america, now. Thanks again. |
The previous composition strategy was such that it was difficult to compose functions returning a value. This new composition strategy is better because it allows us to return values, which is definitely going to help us. Part of ooni/probe#1466.
The previous fix allowed us to return values directly from implementations of Engine. Here we take advantage of this possibility by immediately refactoring how backticks work. Part of ooni/probe#1466.
Further simplifies working with the environment. Part of ooni/probe#1466.
After all the refactoring done so far, we can run checks directly inside of `make`, because we have auto-cleanup, temporary environments and we don't need wrapper scripts anymore. Part of ooni/probe#1466.
In ooni/probe#1466, a user is asking about arm64 builds for Debian. We already had some code for that in ooni#311. Let us adapt the code to the `./make` script to have arm64 builds. While there, also adapt the code for darwin and windows.
Just consistency. There was no clear semantic regarding why sometimes I was using __name and sometimes _name. So prefer _name everywhere. Occurred to me while working on ooni/probe#1466.
* doc(make): add not about qemu-user-static While still investigating ooni/probe#1466 * feat(make): sign more generated binaries While there, fix an annoying bug where the context manager was suppressing exceptions that occurred. Work part of ooni/probe#1466.
1. reduce the number of periodic builds 2. just build as part of the release process in most cases 3. shorttests duplicates coverage Preliminary changes as part of ooni/probe#1466
…quently (ooni#333) Like in the previous PR, here we make macos and windows builds only run when we're preparing a release. While there, migrate the code to use the `./make` script. Tested in ooni#331. Reference issue is ooni/probe#1466
…oni#334) While there, flush `print`s in `./make` to have more understandable logging. Also part of ooni/probe#1466
This PR groups misc cleanup and changes from ooni#331. * CLI/linux/build: add documentation * debian/.gitignore: ignore generated files * debian/TODO: unnecessary at this point * debian/ooniprobe-cli.service: remove commented out lines * debian/rules: remove unnecessary actions * make: reindent and fix spelling * smoketest.sh: don't run in verbose mode Part of ooni/probe#1466
Part of ooni/probe#1466. We're building both `arm64` and `amd64`. We are still not publishing `arm64` packages, which is what is asked in the original issue, but we're really close to doing that.
We're still working on ooni/probe#1466. The idea here is to teach the GH action for Linux to publish the debian package for arm64. When this is done, we can cleanup legacy build scripts and GH actions, because there is no remaining use case for them: we now build everything using the `./make` tool.
More cleanup after ooni/probe#1466
Hi OONI Team.
I am trying to install ooni-cli on my Raspberry Pi 4b with Ubuntu 20.04. I am following the official instructions but i got this error:
Do you have any other repository?
Thanks for all your work
The text was updated successfully, but these errors were encountered: