-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to locate package zeek-nightly" and "Package 'zeek' has no installation candidate" #5
Comments
Digging a bit with @bbannier - he suspects that maybe the action could use a tag? The job output output from the link are showing the
Lines 15 to 21 in ada9cf7
|
Okay, I think I've understood now. It's not quite caching, rather than that an out-dated version of the action was used. The The action templates in the zeek/package-template repo use From the action docs, it reads like the
Moving the |
Yeah, I simply forgot to reflect the action update in the template. My sense was that one generally has to stay on top of version updates in the actions one uses. For example, I recently noticed that I was using an outdated version of Are you suggesting moving the v1 tag because it should align with v1.2? That wasn't my intended use, but perhaps it should have been v1.0 then to make that clear. |
I think an issue here is partially that the Zeek repo doesn't provide stable versions, i.e., if one stays on a fixed minor version of the action eventually the action might break like it did for @awelzel here (that is: unless a complete image is build once and cached, but then a version like I think having the action provide |
Ah, I think I understand — much of this is about versioning of the Github action vs the Zeek version this pulls in, right? I fully agree that it shouldn't be required to bump the action version just to keep the Zeek install functional, and I disliked that I had to do that. Fwiw, I don't think the action should still use the binary packages. I only did this because our Docker images weren't yet available. If we move this to using those images, we also automatically gain the freedom to pick a specific version, |
Yes, I think that would work much better. |
Yes, so moving the tag instead of changing individual consumers was my thought. Given how v1 can't be used, v1.2 is semantically still v1 (very hand-wavy due to underlying Zeek versions changing) and with the official docs suggesting that too:
The nice thing about the zeek/zeek-lts is that as a package author you don't need to do anything to test against newer versions. If you explicitly provide the Zeek version, I would not be surprised to see stale repos over time that don't maintain this (which is also why I'm thorny around the v1.2 bump being on package authors). Using the container images for a simpler/direct supply, yes, please. Then call this |
We publish images for |
Fully agreed that having
+1: I think the ability to provide specific versions in addition would be nice. This way package maintainers could easily verify compatibility for packages that should support multiple Zeek versions (e.g., zeek-community-id). |
I've attempted to use the
github-ci
package feature from zeek/package-template for the AF_Packet plugin.The zeek-nightly and zeek-feature builds fail during setup with the messages from the subject. Link to job:
https://github.com/J-Gras/zeek-af_packet-plugin/runs/8244777211
I haven't looked closely, but it seems the implementation of this action is using the binary images from OBS installed into a Debian container. Could that maybe use the
zeekurity/zeek
images directly instead? Minimally it's a more direct supply chain with at least one third-party service removed :-)The text was updated successfully, but these errors were encountered: