RE: FreeBSD CURRENT stabilization cycle
Gleb Smirnoff wrote on Date: Sat, 24 Feb 2024 04:32:52 UTC : > More seriously speaking, I > actually hope that in some future snapshots.FreeBSD.org will start using these > points for snapshot generation. How about also the likes of: https://pkg.freebsd.org/FreeBSD:15:aarch64/stabweek/ for pkgbase (various "aarch64" replacements too)? === Mark Millard marklmi at yahoo.com
February 2024 stabilization week
Hi FreeBSD/main users, the February 2024 stabilization week started with 03cc3489a02d that was tagged as main-stabweek-2024-Feb. At the moment of the tag creation we already knew about several regression caused by libc/libsys split. In the stabilization branch stabweek-2024-Feb we accumulated following cherry-picks from FreeBSD/main: 1) closefrom() syscall was failing unless you have COMPAT_FREEBSD12 in kernel 99ea67573164637d633e8051eb0a5d52f1f9488e eb90239d08863bcff3cf82a556ad9d89776cdf3f 2) nextboot -k broken on ZFS 3aefe6759669bbadeb1a24a8956bf222ce279c68 0c3ade2cf13df1ed5cd9db4081137ec90fcd19d0 3) libsys links to libc baa7d0741b9a2117410d558c6715906980723eed 4) sleep(3) no longer being a pthread cancellation point 7d233b2220cd3d23c028bdac7eb3b6b7b2025125 We are aware of two regressions still unresolved: 1) libsys/rtld breaks bind 9.18 / mysql / java / ... https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277222 Konstantin, can you please check me? Is this the same issue fixed by baa7d0741b9a2117410d558c6715906980723eed or a different one? 2) panic: ... - wait_fw_init - mlx5_load_one https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277211 Hopefully they would be fixed before March stabweek. We closed the stabilization period on Thursday. If you want to reap the fruits of the stabweek and you are very conservative and want to use only changes that passed certain level of testing, you can use the stabweek-2024-Feb branch. The branch is published at https://github.com/glebius/FreeBSD/tree/stabweek-2024-Feb. Otherwise I would recommend to use 7d233b2220cd3d23c028bdac7eb3b6b7b2025125 of FreeBSD/main as a good point to update. We did not observe any large or risky changes in main during the week. -- Gleb Smirnoff signature.asc Description: PGP signature
FreeBSD CURRENT stabilization cycle
Hi FreeBSD CURRENT users, back in November I came up with a proposal of providing some stabilization cadence to development of the main branch, also known as FreeBSD CURRENT. Here is a video with the initial proposal and following discussion at VendorBSD Conference (18 minutes): https://www.youtube.com/live/k-AzShVdAHo?si=hPAhCd_-RuoTRqcW=2511 And here goes an up to date version of the plan! In the last decade quality of FreeBSD CURRENT improved so much, that not only brave developers run it on their laptops, but also large companies use it. Time to bring it to a new level. Every individual or a business that use CURRENT has their own protocol of how to stay up date and avoid disasters. An individual will first update their desktop and only after that will update server(s). A company would run their internal regression test suite or some other validation protocol. Right now we all do that independently from each other having little coordination and providing little help each other. We also do not broadcast to the world that FreeBSD CURRENT is usable. I've seen a lot of people who stay away from CURRENT based on their 20-year old experience with it. Here is how we are going to improve: * Last week of a month is declared a stabilization week Src committers are encouraged to avoid pushing risky changes to FreeBSD/main during this week. This is an advice, not a policy! If a committer breaks something during the week they got 3x public shame, but no administrative penalties or fines. Committers are encouraged to push bug fixes, improve unit tests, clean up comments and improve documentation. It is a also a good time to do merging of past work to stable branches. Developers of course will continue their work on bigger projects in their private branches. Sidenote: there is no agreement in the world what is "the last week of a month". For our purposes we will use the week that contains the last Friday of the month. Because we want the monthly snapshot to be called by the name of the month (not next month) and thus we want the last day of the stabilization cycle always to be in that month. * Monday of the stabweek is the day to update your CURRENT and test it Monday 8:00 GMT a tag is created and published. Right now it is published at my personal https://github.com/glebius/FreeBSD/tags. Note that the tag points at a hash in the official repo, so there is no trust involved here. At Netflix I will be working on merging the tagged revision into our tree and I will hand off the resulting branch to our excellent testing team (dhw@ + olivier@) usually by the end of Monday (PST time). Other companies and parties are encouraged to start testing the tagged revision. Peter Holm may switch his stress2 to run that revision. You are encouraged to update your desktop or laptop that of course runs FreeBSD CURRENT. * A short lived stabilization branch may be created In case we discover regressions compared to the previous month stabweek, bug fixes to them will be committed to a short lived branch. This branch may contain direct cherry-picks from main, as well as work-in-progress bugfixes that had not yet been committed to main, reverts of commits and even stop gaps that disable certain functionality for the sake of stability. This branch may be rebased and force pushed if a temporary bugfix appears different to a final one in main. The branch may observe commits immediately Monday morning in case we already know about a certain regression. The branch will not observe commits to a long standing bugs that were fixed in main during the stabweek, unless somebody explicitly asks to include one. And finally, the branch may not even be created in case testing confirms everything is alright with the Monday tag. The branch will be published at https://github.com/glebius/FreeBSD. There is certain level of trust required to use it. That may change to a more official publishing point in the future. * The stabweek quiet period ends no later than Friday 18:00 GMT No matter if we were able to identify and fix any or all bugs the quiet period ends. The public shame level for src committers breaking FreeBSD CURRENT goes back to normal level. In a case we were not able to address all issues by end of Friday the stabweek branch will be active past the end of the stabweek, as we want to collect all regression fixes in the branch. But this is the worst case scenario! A more appreciated scenario is that the stabilization period ends earlier in the week. If all testing parties report their satisfaction with state of main as is or of the stabweek branch and if I don't see any fresh bug reports in bugzilla or submissions via other channels, there is no reason to withheld committers with pushing their stuff. At the end of the stabilization period be it Friday or earlier I will write email to current@ reporting the results: - were there any regression identified with the Monday tag - what has been accumulated
Re: WITHOUT_CASPER ghost?
On Fri, Feb 23, 2024 at 10:21:12AM -0800, Michael Dexter wrote: > On 2/23/24 9:13 AM, Brooks Davis wrote: > > Things are in a somewhat messy state. CASPER and CAPSICUM were moved to > > a new __REQUIRED_OPTIONS list, but the various bits still exist and > > there's even one use of MK_CASPER=no in Makefile.inc1. The commit > > message (c24c117b9644) suggests that the intent was to finish removal > > after 14 branched and it just hasn't happened yet. > > Understood. > > > I do wonder if the tool would also benefit from learning about > > __REQUIRED_OPTIONS. > > By required do you mean WITHOUT_AUTO_OBJ, WITHOUT_UNIFIED_OBJDIR, > WITHOUT_INSTALLLIB which I manually skip/mask my build option testing? >From bsd.mkopt.mk: # For each option FOO in __REQUIRED_OPTIONS, MK_FOO is set to "yes". If you set MK_FOO=no in a way that make can't override them (e.g., on the make command line) then the functionality is still there during the transition. It's probably a bug that we don't whine about this case like we do with WITHOUT_FOO. > If so, what syntax would use __REQUIRED_OPTIONS and what branches support it? __REQUIRED_OPTIONS isn't really a user accessible bit of machinery, but the survey should probably be aware of it. It looks like __REQUIRED_OPTIONS is in 14, but not 13. -- Brooks
Re: WITHOUT_CASPER ghost?
On 2/23/24 9:13 AM, Brooks Davis wrote: Things are in a somewhat messy state. CASPER and CAPSICUM were moved to a new __REQUIRED_OPTIONS list, but the various bits still exist and there's even one use of MK_CASPER=no in Makefile.inc1. The commit message (c24c117b9644) suggests that the intent was to finish removal after 14 branched and it just hasn't happened yet. Understood. I do wonder if the tool would also benefit from learning about __REQUIRED_OPTIONS. By required do you mean WITHOUT_AUTO_OBJ, WITHOUT_UNIFIED_OBJDIR, WITHOUT_INSTALLLIB which I manually skip/mask my build option testing? If so, what syntax would use __REQUIRED_OPTIONS and what branches support it? Michael
Re: libc/libsys split coming soon
On 05-02-24 17:02, Brooks Davis wrote:
Could you do a quick test with an exe linked to libsys but not libc running
under Valgrind memcheck, please?
Could you suggest a more concrete example?
This little example seems to be OK
void _start(void)
{
_exit(0);
}
However I do see quite a few new testcase failures. Some are libsys
related and fairly unimportant. There are also a few more serious issues
that I'm still investigating, not necessarily anything to do with libsys.
A+
Paul
Re: WITHOUT_CASPER ghost?
On Thu, Feb 22, 2024 at 07:49:08PM -0800, Michael Dexter wrote: > All, > > The WITHOUT_CASPER build option was deprecated in main and 14-stable branches > but is still showing up and will trip up the build option survey: > > sh src/tools/tools/build_option_survey/listallopts.sh | grep CASPER > WITHOUT_CASPER Things are in a somewhat messy state. CASPER and CAPSICUM were moved to a new __REQUIRED_OPTIONS list, but the various bits still exist and there's even one use of MK_CASPER=no in Makefile.inc1. The commit message (c24c117b9644) suggests that the intent was to finish removal after 14 branched and it just hasn't happened yet. I do wonder if the tool would also benefit from learning about __REQUIRED_OPTIONS. -- Brooks
