Ok, added this to the Dockerfile and now it works! Thanks for the tip!
Good to hear that it is working now.
To explain; in the first case you run the command directly on the Pi, but in the second case it is executed in a container where it cannot access the Python installation of the host. The modified RUN
command installs Python in the container before executing the npm install
command.
Now it builds, but i get this error:
Generating repository.json
Error: No such container:path: roon-extension-manager:/home/node/.rem/repos
At this point the image is created and the build script tries to include it in the local repository of the Extension Manager installation, but the manager hasnât been installed yet.
Please use the setup script to install the Extension Manager on the Pi, see description in the first post. After that you make the modification to the repository.json
file I described earlier. Then that file should be copied into the container:
docker cp <path/to/>repository.json roon-extension-manager:/home/node/.rem/repos
If that succeeds you should be able to install your extension from the Test category of the manager.
Thank you so much Jan for your patience!
The extension manager (1.0.0-beta2) was already installed and running. I modified the repository.json file and used the docker cp command.
Then i run build.sh again and get this:
Generating repository.json
Error response from daemon: extraction point is not a directory
Also i donât see a test category in the extension manager settings.
Ah, I think the directory doesnât exist yet, it can be created with:
docker exec roon-extension-manager mkdir .rem/repos
Running the script again will revert the changes you made . After manually copying the file into the container there is no need to run the build script again.
A restart of the Extension Manager is needed before the new entry will show up.
I will fix these issues in the next version of the build script.
The build script does
âdocker cp out/$NAME/.reg/etc/repository.json roon-extension-manager:/home/node/.rem/repos/$NAME.jsonâ
, i.e. it copies and tries to rename the json file. But It seems that only a directory is allowed as the target of the docker cp command. So this is why it fails.
I renamed the json file locally and copied it using
âdocker cp $NAME.json roon-extension-manager:/home/node/.rem/reposâ
which worked.
Unfortunately, i still donât see the Test category and cannot start from the extension manager. The local docker file using the generated script runs though.
It would be good to have a look in the container to see what enden up there. Get in with:
docker exec -it roon-extension-manager sh
Then you list the repos directory to see what is in:
ls -l .rem/repos
End check the content:
cat .rem/repos/roon-spacenav.json
And get out with:
exit
Does this all look OK?
Argh, yes, repos was file, not a directory. Deleted the file, created a directory and copied the repository.json file to the container. Now it works - i see the Test category and the extension.
Thanks Jan!
Now i have the problem that it cannot find the USB device. I entered /dev/bus/usb/ as device path when installing, but it does not work. Works for roon-extension-powermate though.
We are getting closer and closer
I think you also have to supply the bus and device ID in the path. If you enter the lsusb
command you should look for the two numbers for your space mouse and append them to the path, e.g. if bus is 001 and device is 004 then the path becomes:
/dev/bus/usb/001/004
No, this does not work. I probably have to look into libusb vs rawhid as in roon-extension-powermate. I can get powermate running only with libusb and /dev/bus/usb/.
I also think it is too difficult for the end-user to cope with device names. Is there no better way when using docker files?
Can we run the docker container in ââprivilegedâ mode to circumvent all these USB device problems and make it easy for the end-user to install such extensions?
I still canât get the USB running inside the container. I tried:
- set device name during installation to /dev/bus/usb/001/003 (which is where the device is connected)
- HID.setDriverType(âlibusbâ); in code and device name /dev/bus/usb during installation (which works with powermate for some reason)
- creating a file /etc/udev/rules.d/95-spacenav.rules with content âSUBSYSTEM==âusbâ, ATTRS{idVendor}==â046Dâ, ATTRS{idProduct}==âC626â, SYMLINK+=âspacenavâ, MODE=â660â, GROUP=âdietpiââ
I wonder if this can be a permission issue. The powermate extension uses the root account in the container while the generated Dockerfile
uses a normal account. You can check if this makes a difference by removing the USER node
line from the Dockerfile
and running build.sh
again.
Yes, that was the problem!
I have HID set to libusb and i use â/dev/bus/usb/â as device path during installation.
Thank you so much for your help! I still wonder if there is better way to pass USB devices to docker without having the user to specify a device path.
Thanks for all your help and patience Jan !
That the bus and device IDs donât have to be specified means that the path is very generic and can be set as the default value. A default value can be specified before the colon in the devices entry:
"options": {
"devices": [
"/dev/bus/usb/:USB Device Path"
]
}
I will add this default value for SpaceNav and Powermate when I handle the merge of your pull request.
Youâre welcome. Thanks for being the first user of the Extension Generator tool!
Two updates resulting from the activities of the last few days:
- Extension Repository version 1.0.4 includes the SpaceNavigator remote control
- Extension Generator version 1.0.1 improves the integration of the generated extension in the locally installed Extension Manager
Great work, Jan! This is a great service to the community.
Extension Manager 1.0 is now also available for the arm64 architecture, so if you are running the 64 bit version of e.g. DietPi on your Pi3 or Pi4 then you can install now!
With the Docker approach for extensions an image has to be created for each processor architecture, this means that the selection of extensions is limited at the moment. I will take care that at least all my extensions become available for arm64.
In this first round the Entrypoints extensions are included, as I had a request for this in the past. I will post updates in this thread when others become available.
I had to reflash Dietpi as a previous upgrade failed.
Just installed Dietpi v7, installed Docker for Linux and ran the install script.
Extension manager is running.
But only System and Entrypoints can be selected.
Are the other extensions not yet available on Extension Manager 1.0?
I canât find Extension Snapshots either.
Only 64 bit arm installations have this limitation, I tried to make that clear in my previous post. The Snapshots and Alarm Clock are on my list to add next. Any specific extension you want to use?