Date: Fri, 31 Dec 2021 18:19:13 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Kyle Evans <kevans@freebsd.org> Cc: Stefan Esser <se@freebsd.org>, Antoine Brodin <antoine@freebsd.org>, src-committers <src-committers@freebsd.org>, "<dev-commits-src-all@freebsd.org>" <dev-commits-src-all@freebsd.org>, dev-commits-src-main@freebsd.org, FreeBSD Ports Management Team <portmgr@freebsd.org> Subject: Re: git: e2650af157bc - main - Make CPU_SET macros compliant with other implementations Message-ID: <Yc8tgfSVhKZelwxg@kib.kiev.ua> In-Reply-To: <CACNAnaEbjRj9yGWtBMByVOET8FFjJQxQEiFuPbrya2CMePf8BQ@mail.gmail.com> References: <202112301154.1BUBsR1q017491@gitrepo.freebsd.org> <CAALwa8m3u3xrO3N0j8um57qGTVnMEQwx1gP2YxJbzE5%2BLhbsWA@mail.gmail.com> <d1553b68-23dd-128e-6ac0-6c3c1f66c7cd@freebsd.org> <CACNAnaEbjRj9yGWtBMByVOET8FFjJQxQEiFuPbrya2CMePf8BQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 31, 2021 at 09:37:16AM -0600, Kyle Evans wrote: > On Fri, Dec 31, 2021 at 4:22 AM Stefan Esser <se@freebsd.org> wrote: > > > > Am 31.12.21 um 09:01 schrieb Antoine Brodin: > > > On Thu, Dec 30, 2021 at 11:54 AM Stefan Eßer <se@freebsd.org> wrote: > > >> > > >> The branch main has been updated by se: > > >> > > >> URL: https://cgit.FreeBSD.org/src/commit/?id=e2650af157bc7489deaf2c9054995f0f88a6e5da > > >> > > >> commit e2650af157bc7489deaf2c9054995f0f88a6e5da > > >> Author: Stefan Eßer <se@FreeBSD.org> > > >> AuthorDate: 2021-12-30 11:20:32 +0000 > > >> Commit: Stefan Eßer <se@FreeBSD.org> > > >> CommitDate: 2021-12-30 11:20:32 +0000 > > >> > > [...] > > >> Ports that have added -D_WITH_CPU_SET_T to build on -CURRENT do > > >> no longer require that option. > > >> > > >> The FreeBSD version has been bumped to 1400046 to reflect this > > >> incompatible change. > > >> > > >> Reviewed by: kib > > >> MFC after: 2 weeks > > >> Relnotes: yes > > >> Differential Revision: https://reviews.freebsd.org/D33451 > > > > > > Hi, > > > > > > This breaks a lot of ports, like lang/python38. > > > Could these kinds of changes on public headers be tested with an > > > exp-run, and reverted in the mean-time? > > > > I'm sorry for the breakage. The commit had the goal to lessen > > port build problems caused by the misled assumptions that the > > port was being built on a GLIBC based system. > > > > Given that we've now iterated on this a couple of times, this likely > should have all been backed out and exp-run'd *way* sooner. Exp-runs are great when there is a path forward from fixing the breakage. In the case where you have some random ports broken, and no ports maintainers responses for explicit queries, it is basically a deadlock. I definitely cannot go over some random but large set of ports fixing them, while maintainers are silent. In fact, with this set of changes, I initially provided some tools in base that were intended to ease the ports life, but still required some (minimal) involvement from the maintainers, like passing -DWITH_CPU_SET_T to C/C++ compiler. I asked more than once if these tools are desirable helper or not, with no avail. So my only route forward was to leave the state in the minimal damaging mode as I see it from bug reports, and wait for maintainers to do _something_. I am very grateful that Stefan took the torch and started massaging the CPU_XXX ugliness into more compatibility with glibc. This again happens in the same silence mode from maintainers, so if we want a progress in this area, it have to go this way. > > > In the case of the Python language ports, one additional macro > > was required and has been added in commit cb65d4432aed11. > > > > Since the official package builders have not been upgraded to > > a -CURRENT with this change, they are not affected. But I'll > > watch the failed build logs on beefy18. Right. > > This is a mindset that we all take, but we really need to work towards > improving. Once we're watching fallout logs on the official builders, > we've already lost. This is the kind of thing that helps promote the > idea that -CURRENT isn't stable enough for production uses: we start > accepting that we can be a little more lenient on identifying > ports-breaking changes because it's -CURRENT and we lose a fraction of > the ports tree because we've only sniped off individual ports as they > come up. > > portmgr@ is able and willing to run exp-runs for changes like this, we > really need to take advantage of that to avoid this kind of follow-up. There, you are blocking src changes by putting unreasonable requirements on src committers to fix ports breakage. I am willing to work together with ports maintainers, but I am not willing to handle things in silence and neglect of other' (my) work. I have similar experience with ino64 FWIW, but I was too naive at that time and indeed tried to fix all ports breakage, including digging into rust/ghc builds. I learned since, I will not do that again. > > > > > > I'm not opposed to a revert and exp-run, but I'm convinced that > > any fall-out from this change is easily fixed, and I'm willing > > to quickly fix any ports or base system components affected. > > > > That's probably not necessary at this point given that we're now N > commits deep into the cpuset.h/sched.h saga, but I really would have > liked to see us be more open to the idea. > > Thanks, > > Kyle Evans
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Yc8tgfSVhKZelwxg>