Comments (15)
I'll have a look. It shouldn't be a problem unless some of the required pip modules are not available for that arch.
from starlink-grpc-tools.
It shouldn't be a problem unless some of the required pip modules are not available for that arch.
I don't think it should be a problem, as meanwhile I installed it directly (ie outside of any container) in the same machine (following your instructions on README.md) and it's working. More specifically the pip install [...] requirements.txt
command ran with a single warning, nominally that I already had paho-mqtt
installed.
I'll have a look.
Thanks! I've already started using it, but would much prefer having it run inside a container.
from starlink-grpc-tools.
I build ARM64 for a separate project (https://github.com/sponsianus/dishy_grafana). It's a little behind the main project but might work for your use case.
https://hub.docker.com/repository/docker/sponsianus/starlink-grpc-tools
from starlink-grpc-tools.
The GitHub action for publishing a multi-arch docker image looks pretty straightforward, so I will test that out in a branch.
I did test a linux/arm64 image build locally, and it built OK, but it took a couple hours because the Dockerfile has all the pip packages pinned to specific versions, some of which did not have arm64 binary wheels on pypi. It looks like later versions of those packages do, though, so I'm going to update to current versions for all of them. I probably should have been doing that periodically, anyway.
from starlink-grpc-tools.
OK, it has published and is tagged with the branch name, so you should be able to access it with:
docker pull ghcr.io/sparky8512/starlink-grpc-tools:docker-arm64
I have only sanity tested it, and only with emulation for the ARM64 image. I will test it more thoroughly in a bit, given that I updated all the pip-installed package versions, but if someone could give the linux/arm64 image a try on an actual ARM64 device, I'd appreciate it.
from starlink-grpc-tools.
Note that some Raspberry Pis (mine is a 4B rev 1.1) aren't going to run an arm64 OS. Mine is armv7l
(which looking at setup-qemu-action would be linux/arm/v7
).
I also have to add the pypng
package to the Dockerfile when I build it.
from starlink-grpc-tools.
Note that some Raspberry Pis (mine is a 4B rev 1.1) aren't going to run an arm64 OS. Mine is
armv7l
(which looking at setup-qemu-action would belinux/arm/v7
).
I can add a linux/arm/v7
image easily enough, but was only planning to do so if someone requested it. The images are kinda big to be leaving around if nobody is going to use them. I take it you would use them if they were being published?
On a related topic: Is the >1GB image size going to be a problem for RPi users? Nothing in starlink-grpc-tools
needs the full Debian base image, so the Dockerfile could be changed to use the slim version, which comes out to about 200MB. However, every time I look into doing so, I am reminded that using the full base image could actually use less storage overall if it shared with other images due to not having to add missing packages back into those other images. I don't actually use Docker much, other than testing for this project, so I don't really have an opinion on this myself.
I also have to add the
pypng
package to the Dockerfile when I build it.
Oops, thanks for pointing that out. I guess I missed that when I added the obstruction map script. I will correct it.
from starlink-grpc-tools.
I can add a
linux/arm/v7
image easily enough,
So... it turns out this was only half true. I can add building of that image easily enough, but when I test doing so locally, all the scripts fail trying to load the grpc module due to a shared library issue. googling around leads me to believe this has been a persistent problem with the armv7l
binary wheel for the grpcio package posted on PyPI.
The most commonly recommended solution is to pass an option to pip to build that package's wheel from source. I tested that and it takes a long time (running via qemu) to build a Docker image, but it does result in a working image. I would want to conditionalize that so it only does that for linux/arm/v7
. Before I do that, though, I really would like to see if anyone would actually use it.
from starlink-grpc-tools.
Yep, it's this issue: https://groups.google.com/g/grpc-io/c/vjbL3IdZ2Vk/m/EcKSeD4eAgAJ
I had to install it with the --no-binary option:
pip3 install grpcio==1.44.0 grpcio-reflection==1.44.0 --no-binary=":all:"
I did not try with version 1.50.0
, but it is working for me now.
from starlink-grpc-tools.
OK, I finally got around to actually generating the image in the main branch. I had to update my procedure for updating the "latest" tag after testing, too, but as of now, the "latest" tag points to an image that supports both linux/amd64 and linux/arm64.
If anyone wants a 32-bit ARM image to be included, please file a separate issue. Otherwise, I will look into changing the Dockerfile to add the appropriate pip flag so it works if someone makes their own image, but may or may not add it to the images posted to the repository here.
from starlink-grpc-tools.
Note that some Raspberry Pis (mine is a 4B rev 1.1) aren't going to run an arm64 OS. Mine is
armv7l
(which looking at setup-qemu-action would belinux/arm/v7
).
This, of course, depends on the specific OS. In my case, I run Devuan Chimaera 4.0 (systemd-less Debian Bullseye) and it's arm64 alright:
uname -a
Linux REDACteD 5.15.74 #1 SMP PREEMPT Mon Oct 31 13:02:05 EDT 2022 aarch64 GNU/Linux
from starlink-grpc-tools.
OK, it has published and is tagged with the branch name, so you should be able to access it with:
docker pull ghcr.io/sparky8512/starlink-grpc-tools:docker-arm64
The above command is showing me the following error:
Error response from daemon: manifest unknown
from starlink-grpc-tools.
Before I do that, though, I really would like to see if anyone would actually use it.
Yep, I'm really going to use it (and BTW, sorry for the delay in coming back to this).
I just would like to note that my architecture is arm64/aarch64 as mentioned in the issue's title.
from starlink-grpc-tools.
The above command is showing me the following error:
Error response from daemon: manifest unknown
Yes, I deleted that image in order to avoid people thinking they need to use that one for ARM support. The regular one (the "latest" tag) should now be usable using the standard command from the README.
Before I do that, though, I really would like to see if anyone would actually use it.
Yep, I'm really going to use it (and BTW, sorry for the delay in coming back to this).
I just would like to note that my architecture is arm64/aarch64 as mentioned in the issue's title.
No problem. The 64-bit ARM image is already there now, and I was asking about the 32-bit one in that comment.
from starlink-grpc-tools.
The 64-bit ARM image is already there now, and I was asking about the 32-bit one in that comment.
Thanks for the clarification.
In fact, I just docker pull
ed it as per the README and it seems to be working perfectly.
I will keep testing it as I integrate it into my telemetry environment, and if I detect any problems I will open a more specific issue.
Closing this one now, and thanks again,
from starlink-grpc-tools.
Related Issues (20)
- TypedDicts have type Any in IDE HOT 5
- no attribute 'wedge_abs_fraction_obstructed' HOT 5
- Make robust against field removal in grpc protocol HOT 2
- Error in "Running with SystemD" instructions HOT 2
- Need to wrap Environment variables within /etc/systemd/system/starlink-influx2.service with " " HOT 6
- Docker image missing generated gRPC protocol modules HOT 3
- Did Starlink disable the gRPC/web interface? HOT 2
- Remote API HOT 6
- Zabbix Template for Starlink Dishy HOT 3
- wifi_util.proto missing HOT 1
- Unknown Alert code 384 HOT 2
- MessageFactory class is deprecated HOT 3
- Is it possible to poll RSSI values? HOT 2
- is it possible to query satellite coordinates from the gRPC interface? HOT 1
- How does the Bandwidth usage works ? HOT 12
- Obstruction map - which way is "up" ? HOT 2
- Get sleep mode status? HOT 6
- Docker image: Failed writing to InfluxDB HOT 2
- Check for and trigger software updates HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from starlink-grpc-tools.