Gemini 2.5 Pro is great for many things, but seems to have an abysmal performance while following procedural instructions. No matter what I try, I can't convince it to handle diff line numbers correctly. Every other model attempted could follow the instructions fine. This is so foundational for coding interactions that it deserves being looked into.
Yeah, that makes no sense indeed.
So... OpenCV imports libavformat, which imports libssh, which does static initialization and calls into gcry_control at dlopen time, which does setuid(x), at load time. Before a single line of the app or library has had a chance to run, libssh, inside OpenCV, does setuid. What a world.
Awful workaround: clobber the gcry_control symbol from gcrypt.
Honorable mention: thanks eBPF.
A single reference to OpenCV's VideoCapture class links in 109 additional ELF libraries to an app that was already using OpenCV, and breaks the application even if no OpenCV code is ever called explicitly. Will be fun to find out which static initialization code is broken.
"Venn diagram with 3 circles"
Finally, the perfect offline review tool: paper! (okay, more likely a tablet)
Spent a few hours on a GitHub PR => PDF tool to be able to take a batch of pull requests and move them to a convenient and peaceful format for analysis. Besides being an offline format which can be annotated easily with a pen, this also reshapes the data for clarity. Of course, reviews aren't sent out on PDFs, so providing feedback to people is a separate step. This is rather an inspection tool.
There are other projects in a similar situation, notably go-yaml, which definitely needs attention. A round of updates is due for over a year now. Besides being impolite, that pending item keeps starring at me from my agenda with a clear look of disapproval, until I manage to reserve the number of days required for the job. For go-yaml specifically, my hope is to eventually find space to move the project inside Canonical under a proper team. We'll see.
The GitHub project for gopkg.in has also been cleaned. There were general conversations hanging in issues for years. I've generally attempted to not close down conversations until there was some proper closure, but once Canonical demanded more of my time and the allocation for such projects started to run out, this became a bad practice, since as an attempt to not be impolite in conversations, I ended up being impolite regardless for pretending that I'd have time for them sooner than realistic.
So now the logic will detect such timeouts and evict the cache. We'll have to wait to see if that fixes the issue, but either way this is unsettling. Such caching logic should be smarter about not persisting bad connections forever. If that's indeed happening, this will surely bite again in a completely different place at some point.
Did some updates on gopkg.in today, with the kind help of Canonical's IS team, to attempt to workaround a longstanding hiccup from the service. Every once in a while an arbitrary node in the quorum, after some unrelated connectivity hiccup, just stops responding to requests properly due to GitHub timeouts. The only reasonable explanation is that conenctions in the cache are broken, and remain broken. This is not a _reasonable_ explanation though, given how simple the code is.
