From nobody Fri Dec 31 16:31:02 2021 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 29D481937278; Fri, 31 Dec 2021 16:31:14 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQVy96MQ1z3CXr; Fri, 31 Dec 2021 16:31:13 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id B7859CC5C; Fri, 31 Dec 2021 16:31:13 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f171.google.com with SMTP id p19so24507251qtw.12; Fri, 31 Dec 2021 08:31:13 -0800 (PST) X-Gm-Message-State: AOAM5308H5MHF2SCwXWLN8XFpn0196wHEFWhOT3Fxy/ykWKwjd5tE2ke rvvZ1K4gQEHdyhbzU53nny1CWKaDQfzSkvsBbwI= X-Google-Smtp-Source: ABdhPJwt0bMuHl3OSyuLe1YUJdzU2Okem6lcd/JbnhrEj+uVpuDZdT0fGaABr2ANRJfhl2PAeeKGyxCLvQetoRTnwFY= X-Received: by 2002:ac8:58ca:: with SMTP id u10mr31166622qta.44.1640968273259; Fri, 31 Dec 2021 08:31:13 -0800 (PST) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 References: <202112301154.1BUBsR1q017491@gitrepo.freebsd.org> In-Reply-To: From: Kyle Evans Date: Fri, 31 Dec 2021 10:31:02 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: git: e2650af157bc - main - Make CPU_SET macros compliant with other implementations To: Konstantin Belousov Cc: Stefan Esser , Antoine Brodin , src-committers , "" , dev-commits-src-main@freebsd.org, FreeBSD Ports Management Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640968273; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kgB7lQKSGdUv+rRqzhgin2T34e1epDXlKyVQoqlbJwc=; b=bf+47G3nTM/eh0wUSHjfW0J+WebTFHl8LyLuC4J/fCaZRC8T//l0zXv3m9GEGoXB8fRl/F 7yrvBeUgunliu9IlkYshF/W0AStFHbxpnwG/PygFAgEXM5E5nEzD3+sk1JN/g/0Rq+LvB/ 5Q66dX5ZfLAERZeA8P5Bj7XW4z1hOLkFycLTyPJOzzAFxFIP0oDm0YC9q6HJE+Kri+ALUe 5/hljafnxMmSFIc+vv2+6/wt6/p85ZQQO6QrqscvQv2RnYWpswm83aXO/a9MSMavjPDfFo qxxi9vAo7eUOa7IIw2XBZoTqBcbPRZDCLn5p1QcMOFcxUnJgHFuw1MxdJkWZnQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640968273; a=rsa-sha256; cv=none; b=aiftov14pOVW7E27dBiNosBb1qP+3bwwN0KXFOZOh/1I3RNK2DHIR2duAfRUF/FgcwfN+i gETKjJ1xteWgJaPptslytodpvBNVjEBDoIKuqbAZN0DNvArVW0mP19g6WGbqItIngM077o DP6DwbzwZLMGpr7BJV2oSj0oDRXTIvE8tFPUFO5h/+6B7JonfMXXctZWVF/Gd0NRYw5M0m 1aXm7PiDaer8McDLoRjVWxVrf2/tFz3BQP9P0niA705Ev0mKpA/8k4hjjgYykj/klB7Gxl 0fGI2XVYJ2wVRwiSGUUBTn3IPSSQA5sYR94+lZlvH2VNABQjbx8UxWpkqH9ZFQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Fri, Dec 31, 2021 at 10:19 AM Konstantin Belousov wrote: > > On Fri, Dec 31, 2021 at 09:37:16AM -0600, Kyle Evans wrote: > > On Fri, Dec 31, 2021 at 4:22 AM Stefan Esser wrote: > > > > > > Am 31.12.21 um 09:01 schrieb Antoine Brodin: > > > > On Thu, Dec 30, 2021 at 11:54 AM Stefan E=C3=9Fer = wrote: > > > >> > > > >> The branch main has been updated by se: > > > >> > > > >> URL: https://cgit.FreeBSD.org/src/commit/?id=3De2650af157bc7489dea= f2c9054995f0f88a6e5da > > > >> > > > >> commit e2650af157bc7489deaf2c9054995f0f88a6e5da > > > >> Author: Stefan E=C3=9Fer > > > >> AuthorDate: 2021-12-30 11:20:32 +0000 > > > >> Commit: Stefan E=C3=9Fer > > > >> CommitDate: 2021-12-30 11:20:32 +0000 > > > >> > > > [...] > > > >> Ports that have added -D_WITH_CPU_SET_T to build on -CURRENT d= o > > > >> 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 maintai= ners > responses for explicit queries, it is basically a deadlock. > > I definitely cannot go over some random but large set of ports fixing the= m, > while maintainers are silent. > We do not know in advance that maintainers are silent, because we do not know in advance which ports are even affected. We can't outright claim there's a problem without knowing the scope. Nevertheless, yes, you're right- this is even a conversation we've had recently re: toolchain breakage, and I don't recall what the outcome of that conversation was. > In fact, with this set of changes, I initially provided some tools in bas= e > that were intended to ease the ports life, but still required some (minim= al) > 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. > And that was indeed helpful, thanks! > 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. > None of this is really applicable to this specific commit, though. The breakage identified this time was that a couple more definitions were expected, which does lean towards iteration on the patch rather than yet requiring the maintainer or ports committer aide. I suspect the answer for other scenarios is that we run the exp-run and shoot out a solicitation for help to -ports@ to cast a broader net. Ports committers already get stuck with the fallout from this stuff when maintainers don't notice or step up to the plate or even when the breakage is just bad enough. I imagine you'd have no problem catching some folks willing to help be proactive rather than reactive. > > > > > 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 ti= me > and indeed tried to fix all ports breakage, including digging into rust/g= hc > builds. I learned since, I will not do that again. > I don't want src committers to fix all of the breakage, I want them to at least do the bare minimum to identify when a change is going to break a lot of stuff and figure out the magnitude of that breakage. Sometimes we have to work with ports people on it, sometimes we just need to iterate on our own changes further. We can't punt on the latter because we haven't perfected the former yet. Thanks, Kyle Evans