Re: Reverting -current by date.
On Wed, Nov 20, 2019 at 02:52:22PM -0800, Mark Millard wrote: > > Unfortunately for Bob P., no suggestion can meet his full criteria. So > he has several suggestions to potentially pick from or to use in > combination. > This is a most gracious way of saying my expectations are unreasonable. Sad but not surprising. At least now I know. Thanks to everyone for enlightening me, bob prohaska > >> > >> . . . > > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Reverting -current by date.
On 11/20/19 12:02 PM, bob prohaska wrote: On Wed, Nov 20, 2019 at 11:18:41AM -0700, Warner Losh wrote: On Wed, Nov 20, 2019 at 10:39 AM bob prohaska wrote: From time to time it would be handy to revert freebsd-current to an older, well-behaved revision. Is there a mechanism for identifying revision numbers that will at least compile and boot, by date? Almost all of them will compile. Almost all of those will boot. While some build breakage sneaks through, the default assumption is that it's good. That's certainly been my experience randomly updating to -current. There's some that are more or less performant, mind you, and some that are more or less stable, it is true. But the overwhelming vast majority will compile and boot, at least for amd64. I have issues less than 1% of the time when updating to whatever is current at the moment I fancy an update. Are commits that depend on one another somehow grouped in a single revision? Unlike in the old CVS days, yes, our commit rules require any single commit to not break the build or system, which, as a corollary means that people should commit all changes required to do so in a single commit. There's some hardware that gets broken from time to time, but we don't track that specifically. And non-amd64 architectures takes more care and planning as any build breakage for those platforms lasts longer, in direct proportion to how popular the platform is Point taken. I'm interested in aarch64, which puts me somewhat in the weeds. It's all in the commit logs. If you run -current you need to read them. They will also tell you almost always if you pick revision X if there was a subsequent fix that made things compile you should go with. I take it the strategy would be go back in the log to a rough date, then browse forward in time looking for signs of major trouble. When the commits turn minor/benign, select a revision from that timeframe. basically yes. I usually do a (more or less) binary search, informed by examination of the sources and commit history. Study the commit logs? I know I'm harping on that, but when things go wrong, that's what I do. I hoped for a more mechanical approach. For example, snapshots are generated from time to time. Presumably, they're vetted in some way and knowing what revisions made it to the snapshot stage might be a starting point. The snapshot server does not appear to contain that information for earlier offerings. yes there are snapshots but they are more likely to be vetted for compiling than for running successfully on your hardware. Also -DNO_CLEAN builds help a lot if you're worried about it not even building, though from time to time you run into issues with a NO_CLEAN build due to a recent commit that wasn't appreciated at the time of the commit, but was later and fixed. Does -DNO_CLEAN behave sanely (and usefully) when going backwards in time? I commonly use it for small forward steps, but time reversal is tricky 8-) Good question.. that would depend on whether the source control program you use updates the timestamps of the files to be the time of commit or time of update.. I am pretty sure svn just uses the time that you ran the command. However SOMETIMES there are changes that are made to support forward migration that may not work well with backwards migration.. I tend to do several NO_CLEAN builds but every now and then I'll do a full build if I've gone too far or if things seem a bit odd. Thanks for replying! bob prohaska ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Reverting -current by date.
On 2019-Nov-20, at 14:28, Julian Elischer wrote: > On 11/20/19 1:51 PM, Mark Millard wrote: >> Bob P. wrote for an aarch64 context: >> >>> From time to time it would be handy to revert freebsd-current to >>> an older, well-behaved revision. >>> >>> Is there a mechanism for identifying revision numbers that >>> will at least compile and boot, by date? >>> >>> In my case buildworld seems to be markedly slower than, say, >>> six months ago. Maybe it's hardware, maybe something else. Is >>> there a way to pick a revision number to revert to, that's >>> better than merely guessing? >> You can explore the history of installable world/kernel materials >> at places matching the pattern: >> >> https://artifact.ci.freebsd.org/snapshot/head/r*/arm64/aarch64/* > > I find that https://svnweb.freebsd.org/base/ is good enough to allow > exploration of revisions. If you add a revision in the given field you will > only see revs show up that are older than that. > The difference is my suggestion shows examples of builds that completed and produced world and kernel materials. (But looking around is messier. At least https://artifact.ci.freebsd.org/snapshot/head/ shows dates too.) Plus, he might at times be able to avoid building by using the *.txz files to advantage. I use https://svnweb.freebsd.org/base/ as well, but not to directly find examples that built or materials that avoid my needing to build. It can help decide what to explore under https://artifact.ci.freebsd.org/snapshot/head/ when such material are relevant. Unfortunately for Bob P., no suggestion can meet his full criteria. So he has several suggestions to potentially pick from or to use in combination. >> >> . . . > === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Reverting -current by date.
On 11/20/19 1:51 PM, Mark Millard wrote: Bob P. wrote for an aarch64 context: From time to time it would be handy to revert freebsd-current to an older, well-behaved revision. Is there a mechanism for identifying revision numbers that will at least compile and boot, by date? In my case buildworld seems to be markedly slower than, say, six months ago. Maybe it's hardware, maybe something else. Is there a way to pick a revision number to revert to, that's better than merely guessing? You can explore the history of installable world/kernel materials at places matching the pattern: https://artifact.ci.freebsd.org/snapshot/head/r*/arm64/aarch64/* I find that https://svnweb.freebsd.org/base/ is good enough to allow exploration of revisions. If you add a revision in the given field you will only see revs show up that are older than that. Some r* will exist without having arm64/aarch64 material but having mateirals for other platforms. The * matches a svn revision number. These are from ci.freebsd.org builds, not the announced/released snaphots. These go back a long ways. ci.freebsd.org does not try to build every svn revision. (It does not build that fast relative to svn updating.) I sometimes use these for approximate bisection without building. The https://artifact.ci.freebsd.org/snapshot/head/r*/arm64/aarch64/* materials are compressed tar archives (*.txz) and a MANIFEST file. bsdinstall uses these files, although I've at times done basic testing activities based on just manually expanding the tars. (The materials do not span u-boot or other such and need to have file system(s) to expand into.) (From a different message:) I hoped for a more mechanical approach. For example, snapshots are generated from time to time. Presumably, they're vetted in some way and knowing what revisions made it to the snapshot stage might be a starting point. The snapshot server does not appear to contain that information for earlier offerings. Snapshots are not vetted as far as I know --and sometimes do not boot in contexts that I've tried. This applies both to artifact.ci.freebsd.org materials and the announced snapshots put under https://download.freebsd.org/ftp/snapshots/ . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Reverting -current by date.
Bob P. wrote for an aarch64 context: > From time to time it would be handy to revert freebsd-current to > an older, well-behaved revision. > > Is there a mechanism for identifying revision numbers that > will at least compile and boot, by date? > > In my case buildworld seems to be markedly slower than, say, > six months ago. Maybe it's hardware, maybe something else. Is > there a way to pick a revision number to revert to, that's > better than merely guessing? You can explore the history of installable world/kernel materials at places matching the pattern: https://artifact.ci.freebsd.org/snapshot/head/r*/arm64/aarch64/* Some r* will exist without having arm64/aarch64 material but having mateirals for other platforms. The * matches a svn revision number. These are from ci.freebsd.org builds, not the announced/released snaphots. These go back a long ways. ci.freebsd.org does not try to build every svn revision. (It does not build that fast relative to svn updating.) I sometimes use these for approximate bisection without building. The https://artifact.ci.freebsd.org/snapshot/head/r*/arm64/aarch64/* materials are compressed tar archives (*.txz) and a MANIFEST file. bsdinstall uses these files, although I've at times done basic testing activities based on just manually expanding the tars. (The materials do not span u-boot or other such and need to have file system(s) to expand into.) (From a different message:) > I hoped for a more mechanical approach. For example, snapshots are > generated from time to time. Presumably, they're vetted in some way > and knowing what revisions made it to the snapshot stage might be a > starting point. The snapshot server does not appear to contain that > information for earlier offerings. Snapshots are not vetted as far as I know --and sometimes do not boot in contexts that I've tried. This applies both to artifact.ci.freebsd.org materials and the announced snapshots put under https://download.freebsd.org/ftp/snapshots/ . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Reverting -current by date.
On Wed, Nov 20, 2019 at 11:18:41AM -0700, Warner Losh wrote: > On Wed, Nov 20, 2019 at 10:39 AM bob prohaska wrote: > > > From time to time it would be handy to revert freebsd-current to > > an older, well-behaved revision. > > > > Is there a mechanism for identifying revision numbers that > > will at least compile and boot, by date? > > > > Almost all of them will compile. Almost all of those will boot. While some > build breakage sneaks through, the default assumption is that it's good. > That's certainly been my experience randomly updating to -current. There's > some that are more or less performant, mind you, and some that are more or > less stable, it is true. But the overwhelming vast majority will compile > and boot, at least for amd64. I have issues less than 1% of the time when > updating to whatever is current at the moment I fancy an update. > Are commits that depend on one another somehow grouped in a single revision? > There's some hardware that gets broken from time to time, but we don't > track that specifically. And non-amd64 architectures takes more care and > planning as any build breakage for those platforms lasts longer, in direct > proportion to how popular the platform is > Point taken. I'm interested in aarch64, which puts me somewhat in the weeds. > It's all in the commit logs. If you run -current you need to read them. > They will also tell you almost always if you pick revision X if there was a > subsequent fix that made things compile you should go with. > I take it the strategy would be go back in the log to a rough date, then browse forward in time looking for signs of major trouble. When the commits turn minor/benign, select a revision from that timeframe. > > Study the commit logs? I know I'm harping on that, but when things go > wrong, that's what I do. > I hoped for a more mechanical approach. For example, snapshots are generated from time to time. Presumably, they're vetted in some way and knowing what revisions made it to the snapshot stage might be a starting point. The snapshot server does not appear to contain that information for earlier offerings. > Also -DNO_CLEAN builds help a lot if you're worried about it not even > building, though from time to time you run into issues with a NO_CLEAN > build due to a recent commit that wasn't appreciated at the time of the > commit, but was later and fixed. > Does -DNO_CLEAN behave sanely (and usefully) when going backwards in time? I commonly use it for small forward steps, but time reversal is tricky 8-) Thanks for replying! bob prohaska ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Reverting -current by date.
On Wed, Nov 20, 2019 at 10:39 AM bob prohaska wrote: > From time to time it would be handy to revert freebsd-current to > an older, well-behaved revision. > > Is there a mechanism for identifying revision numbers that > will at least compile and boot, by date? > Almost all of them will compile. Almost all of those will boot. While some build breakage sneaks through, the default assumption is that it's good. That's certainly been my experience randomly updating to -current. There's some that are more or less performant, mind you, and some that are more or less stable, it is true. But the overwhelming vast majority will compile and boot, at least for amd64. I have issues less than 1% of the time when updating to whatever is current at the moment I fancy an update. There's some hardware that gets broken from time to time, but we don't track that specifically. And non-amd64 architectures takes more care and planning as any build breakage for those platforms lasts longer, in direct proportion to how popular the platform is It's all in the commit logs. If you run -current you need to read them. They will also tell you almost always if you pick revision X if there was a subsequent fix that made things compile you should go with. > In my case buildworld seems to be markedly slower than, say, > six months ago. Maybe it's hardware, maybe something else. Is > there a way to pick a revision number to revert to, that's > better than merely guessing? > Study the commit logs? I know I'm harping on that, but when things go wrong, that's what I do. Also -DNO_CLEAN builds help a lot if you're worried about it not even building, though from time to time you run into issues with a NO_CLEAN build due to a recent commit that wasn't appreciated at the time of the commit, but was later and fixed. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Reverting -current by date.
On Wed, 2019-11-20 at 09:38 -0800, bob prohaska wrote:
> From time to time it would be handy to revert freebsd-current to
> an older, well-behaved revision.
>
> Is there a mechanism for identifying revision numbers that
> will at least compile and boot, by date?
>
> In my case buildworld seems to be markedly slower than, say,
> six months ago. Maybe it's hardware, maybe something else. Is
> there a way to pick a revision number to revert to, that's
> better than merely guessing?
>
> Thanks for reading,
>
> bob prohaska
>
svn update -r "{date}"
The curly braces indicate you're specifying a date, which can be in a
large variety of typical formats, details here:
http://svnbook.red-bean.com/en/1.7/svn.tour.revs.specifiers.html
Curly braces are significant in some shells, so the quotes may be
required.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Reverting -current by date.
On Wed, Nov 20, 2019 at 09:38:53AM -0800, bob prohaska wrote: > >From time to time it would be handy to revert freebsd-current to > an older, well-behaved revision. > > Is there a mechanism for identifying revision numbers that > will at least compile and boot, by date? > > In my case buildworld seems to be markedly slower than, say, > six months ago. Maybe it's hardware, maybe something else. Is > there a way to pick a revision number to revert to, that's > better than merely guessing? > > Thanks for reading, > This is not anything "official," but for whatever it may be worth, I have been in the habit of tracking head and recent stable branches on a couple of machines on a daily basis, and part of that process for the last few years has been to update some files that may be found at http://www.catwhisker.org/~david/FreeBSD/history/ In particular, http://www.catwhisker.org/~david/FreeBSD/history/laptop_uname_amd64.13.txt shows the revisions that worked for me on my laptop; http://www.catwhisker.org/~david/FreeBSD/history/freebeast_uname_amd64.13.txt shows the same for a headless "build machine." Peace, david -- David H. Wolfskill da...@catwhisker.org Why is Trump trying to keep salient information from House investigators? See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Reverting -current by date.
On Thu, Nov 21, 2019 at 1:39 AM bob prohaska wrote: > > From time to time it would be handy to revert freebsd-current to > an older, well-behaved revision. > > Is there a mechanism for identifying revision numbers that > will at least compile and boot, by date? > > In my case buildworld seems to be markedly slower than, say, > six months ago. Maybe it's hardware, maybe something else. Is > there a way to pick a revision number to revert to, that's > better than merely guessing? > > Thanks for reading, I suggest checking the build history in our CI system, for example, head-amd64: https://ci.freebsd.org/job/FreeBSD-head-amd64-build/ Li-Wen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Reverting -current by date.
>From time to time it would be handy to revert freebsd-current to an older, well-behaved revision. Is there a mechanism for identifying revision numbers that will at least compile and boot, by date? In my case buildworld seems to be markedly slower than, say, six months ago. Maybe it's hardware, maybe something else. Is there a way to pick a revision number to revert to, that's better than merely guessing? Thanks for reading, bob prohaska ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
