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.
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.
