Repository navigation
Debian BMv2 repository seems broken #5723
Description
Activity
If the mirror updates aren't atomic -- as the error message itself suggests -- then that might have actually been the problem. There was a "package refresh" today that does an in-place rebuild of the existing packages. https://github.com/chreekat/p4lang-packages/actions/runs/30680178416.
Let's keep this open -- I'd like to avoid the problem in the future.
In the meanwhile, you can just rerun the job and it should work.
Hm looks like it happened at a different time, too, so maybe it isn't transitory. I'll have to look at it on Monday.
... Or maybe it was just a long window. I reran the failure I saw, and sure enough, it worked.
... Or maybe it was just a long window. I reran the failure I saw, and sure enough, it worked.
Fingers crossed! Was broken for quite some time. Let's hope its resolved
This kind of thing should only happen when a PR on the https://github.com/p4lang/behaviorial-model repository is merged, true? Or is there some other trigger that we know of that causes this apparently-corrupted image to be written?
In April, I set up a Package Refresh job. All it does is trigger a rebuild of the existing packages on OBS. This was purely a backstop to prevent expired signatures (the original problem I set out to fix).
The Package Refresh runs quarterly, and the last one was on August 1. So there is a possible trigger for new packages.
That doesn't explain why the set of deployed packages would be inconsistent.
I have a hunch, but it's probably wrong. I'll do some analysis.
@fruffy I double checked the PR you mentioned, #5720, and it seems like it passed all its CI. Plus, I don't see any more failures in the repo. I also checked the files on the mirror -- now they match the expected digest sums.
I think this truly was caused by a non-atomic mirror update.
The root cause is probably that the OBS repository system wasn't designed for in-place updates. (I'd suggest they should still update atomically, though...)
I'm just about done pushing new packages (complete with new versions) on every tagged release of bmv2 p4c, pi, etc. I may simply retire the "Package Refresh" workflow at that point.
If one of these packages goes ~4 years without a single change, the deb signatures will still expire. But I think we should just cross that bridge when we get to it.
I double checked the PR you mentioned, #5720, and it seems like it passed all its CI
I reran CI three times, in intervals. The fourth attempt succeeded. We should monitor this and check whether it happens again on the next refresh. This time the packages were out of sync for ~2 days
I found this issue that indicates suse repos may be out of sync for very long stretches of time indeed: systemd/mkosi#4365
I do wonder if that limits the long-term viability of OBS.
I found this issue that indicates suse repos may be out of sync for very long stretches of time indeed: systemd/mkosi#4365
I do wonder if that limits the long-term viability of OBS.
Thanks for investigating this! Not sure what the takeaway from that thread is. Maybe we can pile on?
I don't think so -- I suspect they're tightly resource constrained and doing the best they can.
If it becomes a constant problem for us, we'll just have to build and host the debs somewhere else. Like.. GitHub.
Seeing this message, strange error.