From nobody Fri Dec 31 15:37:16 2021 X-Original-To: dev-commits-src-main@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 CB727192F7E4; Fri, 31 Dec 2021 15:37:28 +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 4JQTm83ptGz4qfC; Fri, 31 Dec 2021 15:37:28 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) (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 4EB03BBB1; Fri, 31 Dec 2021 15:37:28 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f173.google.com with SMTP id bp39so24159050qtb.6; Fri, 31 Dec 2021 07:37:28 -0800 (PST) X-Gm-Message-State: AOAM530tLpoBw6Ku9TCnwQ5ZtJjra7u8rFwGRucoIz7WT2hSC2K/bnH3 2bw8/tuSb3xLCeuNqnIhHVzzY3THCPWWAGnBQ1c= X-Google-Smtp-Source: ABdhPJzwr/T2RLlDPjD4p6MP51f+zc0d7nJ7b4SVKkl/7JvsMAgiw7Fuu/ds53Fg3Ople5OngLrxTiZq/wWkCR5qyTE= X-Received: by 2002:a05:622a:4c:: with SMTP id y12mr31615755qtw.21.1640965047734; Fri, 31 Dec 2021 07:37:27 -0800 (PST) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 References: <202112301154.1BUBsR1q017491@gitrepo.freebsd.org> In-Reply-To: From: Kyle Evans Date: Fri, 31 Dec 2021 09:37:16 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: git: e2650af157bc - main - Make CPU_SET macros compliant with other implementations To: Stefan Esser Cc: Antoine Brodin , Konstantin Belousov , 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=1640965048; 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=k+3ttxnN6nfT7hZcWmTuh6vt1JI8vSCa8c3IHbMiDdQ=; b=yjsJGVpQAx1Lv2qxHs3NY4kFOC+lP1ose1G+XAcsqqwceCg8N9srH7pFHXwPPhbL7se8uw 7zX99gCTf+CNOHQaBXMeA/twnz3vWzT+E9VNQd6CbJNBl2Z5SbhOMHlLZ6OXUYA/kXZuIT B6JZ5MxZEYSOU2kOaSBmPX3BuzuPLOFrVyHVbvcsw/eTeObVw848HQBhJZwEnVi54nDuKp sj1BE6C5vggU5QgabpTFQtYLnwm86Qff9m9ASRgvi+W3Fl6OJomck+sK1oHqX0Jo1lkeS3 q1B/buWs0PPDNqUwuEvUqmFki6G26NQu74DZym3rZmFv9rdlFogxDLfLAip1Tw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640965048; a=rsa-sha256; cv=none; b=YvckNx/axVR53prFxkKhSHzgwRAg7Yes3WORCHEuJQJzo5NNeiB6Xtc2XHj/mxreK7kJPe +hnAjDnk8ciAxJS1U5bG21yFanSziFfIOfMLsr17SlFLPywO/ybri7AKoK9Dw5OVmCXmqe 6ygGddKe7dP6yA2Jk/CBlpQGIepzp8vo1wjHjOZwgcKUlUqVKx21afkmPuCIMOrWHmNTiR EetEFWJwgS8cT8HELf9gor6hrluGqQ41B6GZ2i454kmLhzs1vjJQccLVCh30HnZM4AedfT NaHzKDgQyVXFA1P+9e1v0AJ2zdB3ugg+pQQsFBb3UUFDugyssZ9QK3Yho8ki+A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N 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 wrot= e: > >> > >> The branch main has been updated by se: > >> > >> URL: https://cgit.FreeBSD.org/src/commit/?id=3De2650af157bc7489deaf2c9= 054995f0f88a6e5da > >> > >> 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 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. > 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. > 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. > > 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