Hi Ingo, On 2021/12/26 23:26, Ingo Schwarze wrote: > Hi Alexander, > > Alexander wrote on Sun, Dec 26, 2021 at 08:11:51PM +0000: > > On 2021/12/25 18:02, Ingo Schwarze wrote: > > >> The new fw_update shell script is not in CVS yet. > >> > >> This command provides a clue that could lead you to suspect the above: > >> > >> $ grep -m 1 OpenBSD $(which fw_update) > >> # $OpenBSD$ > >> > >> That's a CVS tag which has not been processed by CVS yet. > > > Just to keep the noise on the mailing list down in case I run into > > something like this again at some point: > > Is that tag the usual indicator of such uncommitted code > > No, it is not usual. In most cases of uncommitted patches that > are being tested in snapshots, the patches change *.c files before > compiling. Compiled files in OpenBSD usually do not contain the CVS > IDs of the source files used. Some historical operating systems > (and maybe even a few current systems, i'm not sure about that) > did include SCCS or CVS tags into compiled files, and that's what > the what(1) utility was designed for in the remote past: > > $ what /usr/src/bin/cat/*.c > /usr/src/bin/cat/cat.c: > $OpenBSD: cat.c,v 1.32 2021/10/24 21:24:21 deraadt Exp $ > $ what /bin/cat > /bin/cat: > $ > > On some other or older systems, "what /bin/cat" might also return the > CVS ID(s). But even that wouldn't really help for your purpose. > In most cases, it would only be the ID of the latest commited > revision; the patch being tested would typically change some lines > of code, but it would usually not change the ID. > > You only saw the unexpanded $OpenBSD$ ID in this case because it > was a completely new uncommitted file intended for later commit, > and because it was not a compiled file but a script where the > source code gets installed directly. > > In the rare cases where you do find such an unexpanded CVS ID, it's a > medium strength indicator pointing to a possible uncommitted patch, > but even then it's not 100% certain - there could be other, even more > unusual reasons for seeing such a thing. > > > or are there other things I should look for before asking here again? > > In general, it can be quite hard to identify uncommitted changes, > even for developers. A generally working way to identify them > basically does not exist. (And maintaining an official list would > be a horrendous make-work project.) > > Sometimes, compiling the tool that behaves strangely yourself > from CVS -current sources and comparing behaviour to the same > tool in the snapshot may help - if behaviour differs, that's > a medium strength indicator of a possible uncommitted patch. > Or, of course, you might have miscompiled it... > Your specific example demonstrates that this suggestion does > not always help: nothing to compile there, and you (rightly) > failed to even find any sources... > > For users, i think best practice is as follows: if something does not > work as you think it should, and if reviewing the manual pages, the > FAQ, and searching through recent postings on tech@, bugs@, and misc@ > still leaves you wondering, then ask, providing as much much detail > as you can: which exact OS version or snapshot, what exactly you did, > what you expected, and what happened instead. If the tool misbehaves > in the snapshot but works when you compile it yourself from -current, > say so. In other words, your report was of very reasonable quality. > Nobody will expect that you make a definitive statement like "this is a > regression caused by an uncommitted patch in snapshots" in your report.
Thanks a lot. That's a very helpful explanation and I will keep that in mind. > > If it appears to misbehave, it's worth a report. And if there > is an uncommitted patch in snapshot, than hopefully at least one > developer is watching closely. After all, asking Theo to put a > patch into snapshots for testing but then *not* watch the bugs@ > mailing list for reports that might be related would make very > little sense! > > Yours, > Ingo > > P.S. > Currently, it looks relatively unlikely that the new fw_update(8) > is really going to loose the -n option; or else it might regrow > it shortly after the initial commit. No guarantee though. > Best advice for users is to wait for the dust in this area to settle. I will do that ;) Thank you for making an os that is actually so reliable and well-designed that I'm not worried at all right now. Best regards, Alexander
