https://github.com/sglyon/PlotlyBase.jl/issues/40
Would anyone have some insight into this problem? It appears to be happening on Linux and Windows. Can you confirm?
1 Like
I answered in the bug report. For the record, the executable program kaleido/bin/kaleido.exe doesn’t have execution permission (permissions are 444).
What is the correct procedure for fixing these binary resources? Is that the responsibility of the package writer?
I guess so. The content of the tarballs listed in Artifacts.toml must be fixed (executable files must be executable)
I’m seeing this error about Kaleido on one Windows 10 PC but not on another, with all the same versions of Julia and the packages, as far as I can tell. I don’t know what the critical difference is. One is a work PC under domain control and the other is personally owned. It’s possible the corporate one has some more restrictive settings.
Could you check whether or not you are able to execute the kaleido program manually?
I changed the permissions and it gets me past the error. I didn’t try to execute it directly. What seems weird is why my other computer is fine.
I also have a GR_jll error only on the one machine.
That was my point: see what the differences in the permissions on the kaleido executable are. Do you still remember? Also: Can you check the package status on both systems?
The “Read & execute” permission was unchecked, and I checked it (based on something I read in the issue you linked above). Just now I unchecked it again, and the error comes back. On my other machine kaleido.exe has Read & execute permissions set.
Both systems on PlotlyBase v0.5.0 and both on the beta of 1.6. Before finding this thread I tried 1.5.3 and I rolled PlotlyBase back to v0.4.1 and those had no effect. I also deleted .julia and let the packages reinstall from a blank page to no avail.
I was wondering if this was a result of Carbon Black defense software on the one machine, but I found where to check and it’s not telling me that it blocked any “threats”.
Many thanks for your help. It is a bit puzzling, why on one system the installation produces correct permissions, while the other does not. But perhaps the order in which the artifact was installed matters? If installing first for 1.5.3 uses a different artifact than installing from scratch for 1.6…
I suspect there is something like that happening. The fact is: the original tarball has definitely files with wrong permissions that must be fixed.
1 Like
Yes, I suggested how the artifact-installation script can be improved in the issue.
Operating on similar lines, I seem to have remedied the GR_jll failure by executing
icacls *.exe /grant Everyone:(RX)
and
icacls *.dll /grant Everyone:(RX)
in the \bin\ directory for that artifact (found by error messages from using GR_jll.
2 Likes
The proper approach would be to fix it at the source, I think. This manual tweaking may fix the problem once, but it is not a good solution. Better to file an issue.
I’m not aware of any issue with the libraries/executables of GR_jll: as far as I can see in this tarball, all of them have permissions set to 755
I don’t have an explanation. When the long discussion on Zulip occurred about GR_jll problems I saw that I was getting an error from it as well but it wasn’t impeding my ability to work and I didn’t think I had anything to add to the conversation. When I ran into the permissions issue on Kaleido (which was stopping me hard), the GR_jll thing was still there and I wasn’t sure if they might be related in some way. I do not have a root cause explanation for why either the GR_jll or Kaleido executables ended up with different permission on my two machines.
Same problem on both my PC and Laptop