Re: Is fw_update documentation outdated?
Hi Ingo, On 2021/12/26 23:26, Ingo Schwarze wrote: > Hi Alexander, > > Alexander wrote on Sun, Dec 26, 2021 at 08:11:51PM +: > > 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
Re: Is fw_update documentation outdated?
Hi Alexander, Alexander wrote on Sun, Dec 26, 2021 at 08:11:51PM +: > 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.
Re: Is fw_update documentation outdated?
Thank you everyone for the helpful and detailed explanations! 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 or are there other things I should look for before asking here again? Thanks again. Best regards, Alexander
Re: Is fw_update documentation outdated?
Hi Alexander, Alexander wrote on Sat, Dec 25, 2021 at 04:07:07PM +: > I just wanted to check for new firmware versions: > > $ fw_update -n > fw_update: unknown option -- -n > usage: fw_update [-d | -D] [-av] [-p path] [driver | file ...] > > This used to work /usr/sbin/fw_update used to be a symbolic link to /usr/sbin/pkg_add, but recent snapshots appear to contain an uncommitted change by Andrew Fresh that makes /usr/sbin/fw_update a stand- alone shell script such that it will become usable in the installer. For now, you can still run the pkg_add-based version that supports the -n option like this: $ cd $ cp /usr/sbin/pkg_add fw_update $ perl ./fw_update -n But this may or may not become impossible in the near future. Snapshot do sometimes contain patches that are being evaluated before committing them. > and is still documented like this in > > $ man 8 fw_update > [...] > -n Dry run. Do not actually install or update any firmware > and whether it appears to be required by a driver. > [...] > (also https://man.openbsd.org/fw_update) I expect the documentation will be updated when this gets committed, or shortly afterwards. > But /usr/sbin/fw_update does not contain this option anymore and > consequently produces the error above. > This mismatch puzzles me a bit and I'm even more confused when looking > at https://cvsweb.openbsd.org/src/usr.sbin/fw_update/ which has been in > the attic for the last 6 years. > > I'm guessing I'm just uninformed and don't understand CVSweb but I'd > like to learn, so: > Is the documentation for fw_update outdated? > Where do I actually find the version history of the fw_update that is > installed on my system in CVSweb? That history is purely a matter of the future. 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. Yours, Ingo > My system: > $ head -1 /etc/motd > OpenBSD 7.0-current (GENERIC.MP) #200: Fri Dec 24 22:15:01 MST 2021
Re: Is fw_update documentation outdated?
fw_update is being replaced with a new program, and this is being tested in snapshots to ensure we have coverage all all circumstances. The new program is capable of updating firmwares while in the bsd.rd install/upgrade phase. This means some firmwares (specially *drm firmwares) will get updated then, rather than after the reboot. This means noone needs a 2nd reboot to activate those firmwares. Some behaviours of the existing program may not survive, and others may get changes. It isn't finished yet, when it is, then documentation will be updated. Alexander wrote: > Hi all, > > I just wanted to check for new firmware versions: > > $ fw_update -n > fw_update: unknown option -- -n > usage: fw_update [-d | -D] [-av] [-p path] [driver | file ...] > > This used to work and is still documented like this in > > $ man 8 fw_update > [...] > -n Dry run. Do not actually install or update any firmware > and whether it appears to be required by a driver. > [...] > (also https://man.openbsd.org/fw_update) > > But /usr/sbin/fw_update does not contain this option anymore and > consequently produces the error above. > This mismatch puzzles me a bit and I'm even more confused when looking > at https://cvsweb.openbsd.org/src/usr.sbin/fw_update/ which has been in > the attic for the last 6 years. > > I'm guessing I'm just uninformed and don't understand CVSweb but I'd > like to learn, so: > Is the documentation for fw_update outdated? > Where do I actually find the version history of the fw_update that is > installed on my system in CVSweb? > > My system: > $ head -1 /etc/motd > OpenBSD 7.0-current (GENERIC.MP) #200: Fri Dec 24 22:15:01 MST 2021 > > Thanks in advance. > > Best regards, > Alexander >
Re: Is fw_update documentation outdated?
On Sat, Dec 25, 2021 at 04:07:07PM +, Alexander wrote: > at https://cvsweb.openbsd.org/src/usr.sbin/fw_update/ which has been in > the attic for the last 6 years. > Where do I actually find the version history of the fw_update that is > installed on my system in CVSweb? fw_update is a hard link to pkg_add. Try looking in: /usr/src/usr.sbin/pkg_add
Is fw_update documentation outdated?
Hi all, I just wanted to check for new firmware versions: $ fw_update -n fw_update: unknown option -- -n usage: fw_update [-d | -D] [-av] [-p path] [driver | file ...] This used to work and is still documented like this in $ man 8 fw_update [...] -n Dry run. Do not actually install or update any firmware and whether it appears to be required by a driver. [...] (also https://man.openbsd.org/fw_update) But /usr/sbin/fw_update does not contain this option anymore and consequently produces the error above. This mismatch puzzles me a bit and I'm even more confused when looking at https://cvsweb.openbsd.org/src/usr.sbin/fw_update/ which has been in the attic for the last 6 years. I'm guessing I'm just uninformed and don't understand CVSweb but I'd like to learn, so: Is the documentation for fw_update outdated? Where do I actually find the version history of the fw_update that is installed on my system in CVSweb? My system: $ head -1 /etc/motd OpenBSD 7.0-current (GENERIC.MP) #200: Fri Dec 24 22:15:01 MST 2021 Thanks in advance. Best regards, Alexander
