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
No comments:
Post a Comment