From owner-freebsd-arch@freebsd.org Mon Aug 5 10:19:32 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C8EECBFC4C for ; Mon, 5 Aug 2019 10:19:32 +0000 (UTC) (envelope-from fabien.thomas@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 462DJz4k1Yz4TFD; Mon, 5 Aug 2019 10:19:31 +0000 (UTC) (envelope-from fabien.thomas@stormshield.eu) Received: from work.stormshield.eu (localhost.localdomain [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id 554D43767C1F; Mon, 5 Aug 2019 12:19:14 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 452533767C21; Mon, 5 Aug 2019 12:19:14 +0200 (CEST) Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gbpqQniMNSkE; Mon, 5 Aug 2019 12:19:14 +0200 (CEST) Received: from [192.168.129.1] (support1.stormshield.eu [91.212.116.2]) by work.stormshield.eu (Postfix) with ESMTPSA id 25DD83767C1F; Mon, 5 Aug 2019 12:19:14 +0200 (CEST) From: "Fabien Thomas" To: "John Baldwin" Cc: freebsd-arch@freebsd.org Subject: Re: Open Crypto Framework Changes: Round 1 Date: Mon, 05 Aug 2019 12:19:13 +0200 X-Mailer: MailMate Trial (1.12.5r5635) Message-ID: <9E88949D-92D5-40EA-8ACA-B10E56102476@stormshield.eu> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 462DJz4k1Yz4TFD X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fabien.thomas@stormshield.eu has no SPF policy when checking 91.212.116.1) smtp.mailfrom=fabien.thomas@stormshield.eu X-Spamd-Result: default: False [3.32 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.89)[0.887,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[stormshield.eu]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.97)[0.974,0]; IP_SCORE(0.56)[ip: (1.48), ipnet: 91.212.116.0/24(0.74), asn: 49068(0.59), country: FR(-0.01)]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[1.116.212.91.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:49068, ipnet:91.212.116.0/24, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 10:19:32 -0000 Hi John, Good news to know that you are working on it. > A while back I ranted about what I perceived to be several issues with > our in-kernel framework. I've been working on a first round of=20 > changes > over the past several months and believe I've gotten far enough to be > a first milestone that's probably suitable for merging. At this point > what I would most appreciate is design review on what I've done so far > (though an eye towards the future wouldn't hurt). I have more changes=20 > I > think I'd like to make, but this is a big enough chunk to chew on for > now. > > The code: > > https://github.com/freebsd/freebsd/compare/master...bsdjhb:ocf_rework > > Summary of changes: > > - The linked list of cryptoini structures used in session > initialization is replaced with a new flat structure: struct > crypto_session_params. This session includes a new mode to define > how the other fields should be interpreted. Available modes > include: > > - COMPRESS (for compression/decompression) > - CIPHER (for simple encryption/decryption) > - DIGEST (computing and verifying digests) > - AEAD (combined auth and encryption such as AES-GCM and AES-CCM) > - ETA (combined auth and encryption using encrypt-then-authenticate) > > Additional modes could be added in the future (e.g. if we wanted to > support TLS MtE for AES-CBC in the kernel we could add a new mode > for that. TLS modes might also affect how AAD is interpreted, etc.) > > The flat structure also includes the key lengths and algorithms as > before. However, code doesn't have to walk the linked list and > switch on the algorithm to determine which key is the auth key vs > encryption key. The 'csp_auth_*' fields are always used for auth > keys and settings and 'csp_cipher_*' for cipher. (Compression > algorithms are stored in csp_cipher_alg.) Good point as it was a limiting factor regarding IPsec performance. > > - Drivers no longer register a list of supported algorithms. This > doesn't quite work when you factor in modes (e.g. a driver might > support both AES-CBC and SHA2-256-HMAC separately but not combined > for ETA). Instead, a new 'crypto_probesession' method has been > added to the kobj interface for symmteric crypto drivers. This > method returns a negative value on success (similar to how > device_probe works) and the crypto framework uses this value to pick > the "best" driver. There are three constants for hardware > (e.g. ccr), accelerated software (e.g. aesni), and plain software > (cryptosoft) that give preference in that order. One effect of this > is that if you request hardware when creating a new session, you > will no longer get a session using accelerated software. > > Once a driver is chosen, 'crypto_newsession' is invoked as before. Is there an interest to have a software driver and then an accelerated=20 software ? Another approach would be to have a software driver with runtime=20 detection of accelerated algorithms. For example, base SHA1, SSE3 version, VIA SHA1, intel SHA1 instruction It has the advantage to: - allow all combination of software / accelerated software - single driver code (session db, =E2=80=A6) - avoid duplicate driver for software things Regarding the session db every driver has done its own implementation=20 with various performance issue in the past. Do you also plan to refactor the session db ? Regards, Fabien From owner-freebsd-arch@freebsd.org Mon Aug 5 17:15:10 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 01918A8629 for ; Mon, 5 Aug 2019 17:15:10 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 462PXY6DMnz3xRN; Mon, 5 Aug 2019 17:15:09 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-4.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 53657677; Mon, 5 Aug 2019 17:15:09 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Open Crypto Framework Changes: Round 1 To: Fabien Thomas Cc: freebsd-arch@freebsd.org References: <9E88949D-92D5-40EA-8ACA-B10E56102476@stormshield.eu> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Mon, 5 Aug 2019 10:15:08 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <9E88949D-92D5-40EA-8ACA-B10E56102476@stormshield.eu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 17:15:10 -0000 On 8/5/19 3:19 AM, Fabien Thomas wrote: >> - Drivers no longer register a list of supported algorithms. This >> doesn't quite work when you factor in modes (e.g. a driver might >> support both AES-CBC and SHA2-256-HMAC separately but not combined >> for ETA). Instead, a new 'crypto_probesession' method has been >> added to the kobj interface for symmteric crypto drivers. This >> method returns a negative value on success (similar to how >> device_probe works) and the crypto framework uses this value to pick >> the "best" driver. There are three constants for hardware >> (e.g. ccr), accelerated software (e.g. aesni), and plain software >> (cryptosoft) that give preference in that order. One effect of this >> is that if you request hardware when creating a new session, you >> will no longer get a session using accelerated software. >> >> Once a driver is chosen, 'crypto_newsession' is invoked as before. > > Is there an interest to have a software driver and then an accelerated > software ? > Another approach would be to have a software driver with runtime > detection of accelerated algorithms. > For example, base SHA1, SSE3 version, VIA SHA1, intel SHA1 instruction > It has the advantage to: > - allow all combination of software / accelerated software > - single driver code (session db, …) > - avoid duplicate driver for software things I'm not sure of the best approach. I do think it can be a feature that, for example, aesni.ko is a separate driver that can be unloaded if it had a bug (or if there was some future CPU vuln, etc.). My leaning is probably to use an approach where the existing accelerated software drivers would use the existing software code to implementing missing ETA modes as those are the only ones missing. > Regarding the session db every driver has done its own implementation > with various performance issue in the past. > Do you also plan to refactor the session db ? Conrad already fixed this. He changed sessions to be opaque pointers with driver-specific allocated data similar to device_get_softc which removed all the driver-side version of this entirely. Driver's now get a pointer to the session object during the process callback and are able to obtain their driver-specific session state in constant time via a single indirection. This change might only be in 12.0 or later (or head and later). -- John Baldwin From owner-freebsd-arch@freebsd.org Tue Aug 6 16:56:18 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D1308C570A; Tue, 6 Aug 2019 16:56:18 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46314L595Rz4CZk; Tue, 6 Aug 2019 16:56:18 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id E4DA4CA38; Tue, 6 Aug 2019 16:56:17 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Tue, 6 Aug 2019 16:56:14 +0000 From: Glen Barber To: John Baldwin Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: svn commit: r350550 - head/share/mk Message-ID: <20190806165614.GA41295@FreeBSD.org> References: <201908030106.x7316Ibx078529@repo.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <201908030106.x7316Ibx078529@repo.freebsd.org> User-Agent: Mutt/1.12.1 (2019-06-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 16:56:18 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: > Author: jhb > Date: Sat Aug 3 01:06:17 2019 > New Revision: 350550 > URL: https://svnweb.freebsd.org/changeset/base/350550 >=20 > Log: > Flip REPRODUCIBLE_BUILD back to off by default in head. > =20 > Having the full uname output can be useful on head even with > unmodified trees or trees that newvers.sh fails to recognize as > modified. > =20 > Reviewed by: emaste > Differential Revision: https://reviews.freebsd.org/D20895 >=20 I would like to request this commit be reverted. While the original commit message to enable this knob stated the commit would be reverted after stable/12 branched, I have seen no public complaints about enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see the benefit of disabling it by default -- why wouldn't we want reproducibility?). To me, this feels like a step backwards, with no tangible benefit. Note, newvers.sh does properly detect a modified tree if it can find the VCS metadata directory (i.e., .git, .svn) -- I know this because I personally helped with it. In my opinion, those that want the non-reproducible metadata included in output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their src.conf. Turning off a sane default for the benefit of what I suspect is likely a short list of use cases feels like a step in the wrong direction. Glen --zhXaljGHf11kAtnf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAl1JsSkACgkQAxRYpUeP 4pP1iQ/9HRagGOeEniZZhcv+PYAPG3x5PGj2Jw7x6XAG36wFAGGsPDtOl5T4It0x OFtfhiMWOAIE6BOlG1/7FRfldQq7HiZRanMjp8fPwSEooDJGDs97Rfw2y3iyjUaf mBi90XjF8oKmnQVMDnv3bcXNII2pt79VaDDryvLhpRMuH4fYALinu9I8DU7W+anh EN2PXq8lCR5EdzasZh45Sa+987uhX2zyhUfQsM7Q+Sgfbxc5rrCP8IJkjtmoE6Bu w27/7dQbGuAtygl8Zl8iEYdnfm2yv3uY/05cnjwLK85VBlWaPEEZiV6Dq2iGurtw yrrQQczrlXuv8pzjT43p3IScWU+3kDd0mD5EUYSVpBbaVcFuCEEcyMmn/bYh75nr EvkWzYgrveFupykpgF9k0EsqGViEt8SQNRAf3KihJhpAN4kl7q+hEXZardIcwoz7 pLqMA6rRMB5leOPXwEpLtZxPDHq4MX+GbmtaEOQtuPyJKlbMQ/ieDrfFQZ/Hv8pP EaWiPn7w2iuUliRCHTWsggVgdF/7kEMTfIMNfae/KYmD7fSXC2BHi5wOgKLJGs7H dZibtfqBgGTs8/prHyhBHy7ptSjhknTATfPnUVQ1rkWnpSMvyekoaR8QPM9mfVLR Iv7n30+QiMmhkSvR2CY2GbzI9DDgXdz9SkbwdnQagodV4h7MLmo= =tIoZ -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- From owner-freebsd-arch@freebsd.org Wed Aug 7 05:34:10 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 994DDBF520; Wed, 7 Aug 2019 05:34:10 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 463Ktn2yhCz4GBG; Wed, 7 Aug 2019 05:34:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id BC8561AF112; Wed, 7 Aug 2019 05:34:00 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id x775Y0DP063283 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 7 Aug 2019 05:34:00 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id x775Y0SF063282; Wed, 7 Aug 2019 05:34:00 GMT (envelope-from phk) To: Glen Barber cc: John Baldwin , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: svn commit: r350550 - head/share/mk In-reply-to: <20190806165614.GA41295@FreeBSD.org> From: "Poul-Henning Kamp" References: <201908030106.x7316Ibx078529@repo.freebsd.org> <20190806165614.GA41295@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <63280.1565156040.1@critter.freebsd.dk> Date: Wed, 07 Aug 2019 05:34:00 +0000 Message-ID: <63281.1565156040@critter.freebsd.dk> X-Rspamd-Queue-Id: 463Ktn2yhCz4GBG X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-0.66 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.76)[-0.757,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_LONG(-0.85)[-0.852,0]; NEURAL_SPAM_SHORT(0.90)[0.903,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(0.05)[ip: (0.09), ipnet: 130.225.0.0/16(0.04), asn: 1835(0.12), country: EU(-0.00)]; RCPT_COUNT_SEVEN(0.00)[7]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 05:34:10 -0000 -------- In message <20190806165614.GA41295@FreeBSD.org>, Glen Barber writes: >In my opinion, those that want the non-reproducible metadata included in >output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their >src.conf. Turning off a sane default for the benefit of what I suspect >is likely a short list of use cases feels like a step in the wrong >direction. Seconded. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Wed Aug 7 16:01:01 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 20E48AE3AE; Wed, 7 Aug 2019 16:01:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463bp506H1z3Mt2; Wed, 7 Aug 2019 16:01:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-4.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 30A0A15377; Wed, 7 Aug 2019 16:01:00 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: svn commit: r350550 - head/share/mk To: Glen Barber Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org References: <201908030106.x7316Ibx078529@repo.freebsd.org> <20190806165614.GA41295@FreeBSD.org> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> Date: Wed, 7 Aug 2019 09:00:58 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <20190806165614.GA41295@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 16:01:01 -0000 On 8/6/19 9:56 AM, Glen Barber wrote: > On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: >> Author: jhb >> Date: Sat Aug 3 01:06:17 2019 >> New Revision: 350550 >> URL: https://svnweb.freebsd.org/changeset/base/350550 >> >> Log: >> Flip REPRODUCIBLE_BUILD back to off by default in head. >> >> Having the full uname output can be useful on head even with >> unmodified trees or trees that newvers.sh fails to recognize as >> modified. >> >> Reviewed by: emaste >> Differential Revision: https://reviews.freebsd.org/D20895 >> > > I would like to request this commit be reverted. While the original > commit message to enable this knob stated the commit would be reverted > after stable/12 branched, I have seen no public complaints about > enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > the benefit of disabling it by default -- why wouldn't we want > reproducibility?). > > To me, this feels like a step backwards, with no tangible benefit. > Note, newvers.sh does properly detect a modified tree if it can find > the VCS metadata directory (i.e., .git, .svn) -- I know this because > I personally helped with it. > > In my opinion, those that want the non-reproducible metadata included in > output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their > src.conf. Turning off a sane default for the benefit of what I suspect > is likely a short list of use cases feels like a step in the wrong > direction. My arguments for flipping this in head (and head only) are that the data provided in uname -a when this is disabled is useful for development, and that in head we do tailor settings towards development (e.g. GENERIC in head vs GENERIC in stable). The logic to handle modified trees has an inherent assumption that I think is false, at least for my workflow and I suspect many others. I do builds and tests of kernels on separate machines (VMs or bare metal) from where I use VCS to manage sources so that a kernel crash doesn't toast my source tree. The trees are then shared to the build/test machines via NFS. As a result, the build/test machines are not always able to detect that the tree is modified either because a subset of the checkout is exported via NFS, or the VCS tool isn't installed on the build/test machines because they are generally barebones systems with only a base installed. This does mean that flipping the knob off doesn't provide all of the same info, but it does provide the path, and the path matters because 'kgdb -n last' uses it, and because if you use separate directories for separate projects (e.g. git worktrees), then the path tells you which test kernel you booted. (It is not uncommon for me to have several test projects in flight on a single test machine for different branches.) In the original discussion on arch, we collectively recognized that developer builds vs release builds were different and needed different defaults. The compromise reached at that time was to depend on the VCS to detect developer builds to choose the policy. What I have found is that in practice for at least my workflow that doesn't actually work. I posit that the majority of kernels built from head are developer builds, not releases, and that the default should cater to that. You could also always patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I think would give a more accurate sense of when builds are releases or not. However, I will yield to whatever the consensus is. -- John Baldwin From owner-freebsd-arch@freebsd.org Wed Aug 7 16:22:31 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CE475AEF8A; Wed, 7 Aug 2019 16:22:31 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 463cGt3nxFz3Pj4; Wed, 7 Aug 2019 16:22:30 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5A42B21CDA; Wed, 7 Aug 2019 12:22:29 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 07 Aug 2019 12:22:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsco.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=i KFQjkuBDI01x/nvatWdFxQkbSkjjB/b93reEcOvOKo=; b=mPIyOKSIROezMjsRG d7RExHoTxjqVF8ykCvLFTM9aEdAwHQ02Lw99iqPDYRDqGEK9HoJbp9kHqKRyMS40 cQSh9LMLO9flzaj5UWGtye1vaOJ1Qdf0A08f4KgJb+YVFbDPMzXurZlWodoStH0n jXiKIuPDv/PXPPCovGlROquEzg/VNM0kTH1YHw95fOys5z9nl7yE0b2cmei7ASTW QFVrn4p5L/7Mm++dcCw0OM4n7VLwSmq88fPQhy+gzRj7nGLf7hFVLKXT47UMhw1N yQXgb8C/4V1O7b05v6qdjD1J9kjE+Vl3xJn6xLidi4nPLcPTg3BUD4JnMS4eIenL hUnRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=iKFQjkuBDI01x/nvatWdFxQkbSkjjB/b93reEcOvO Ko=; b=eXL16uIOjNVpKaj/wWzZEcTyWEiC3poFN/sUNTu6fFXRvXcDAaURHW6Kt ynxI/asTgE0gK81yUayh2Cq8Y1ukQ3IhtjFqJK6dZdrFsy565giqpVo+rlGiZsLO fZgAKJ4WWVGWiHA/rwBMvVPQlnYXPrQvvURyTLfRkvOCq2YhFcCJwssD1yjJp5XO 44y1opy7srmgrd1xPFLgVaBs6RljO15kAVkiCyiT0/lWPzXF9UV3+t52Hn3Gf0D9 OAhdsf96b84nVnGJPnGlpOOcivlUUKr/ibV8N+5RDFuOfm5OaeAmjwCCsLKQgKxd 2d6aMQXUptugKA9JBCfk8mD+1z5+A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduvddguddttdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesth hqmhdthhdtjeenucfhrhhomhepufgtohhtthcunfhonhhguceoshgtohhtthhlsehsrghm shgtohdrohhrgheqnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecukfhppedule dvrdehhedrheegrdehkeenucfrrghrrghmpehmrghilhhfrhhomhepshgtohhtthhlsehs rghmshgtohdrohhrghenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [10.178.24.14] (unknown [192.55.54.58]) by mail.messagingengine.com (Postfix) with ESMTPA id 6047580059; Wed, 7 Aug 2019 12:22:27 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: svn commit: r350550 - head/share/mk From: Scott Long In-Reply-To: <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> Date: Wed, 7 Aug 2019 10:22:24 -0600 Cc: Glen Barber , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <201908030106.x7316Ibx078529@repo.freebsd.org> <20190806165614.GA41295@FreeBSD.org> <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 463cGt3nxFz3Pj4 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=samsco.org header.s=fm1 header.b=mPIyOKSI; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=eXL16uIO; dmarc=none; spf=pass (mx1.freebsd.org: domain of scottl@samsco.org designates 66.111.4.28 as permitted sender) smtp.mailfrom=scottl@samsco.org X-Spamd-Result: default: False [-0.78 / 15.00]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_XBL(5.00)[58.54.55.192.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.4]; R_DKIM_ALLOW(0.00)[samsco.org:s=fm1,messagingengine.com:s=fm3]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:66.111.4.28]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; DMARC_NA(0.00)[samsco.org]; BAD_REP_POLICIES(0.10)[]; NEURAL_HAM_LONG(-0.88)[-0.877,0]; RCVD_COUNT_THREE(0.00)[4]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[samsco.org:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_MEDIUM(-0.84)[-0.841,0]; IP_SCORE(-3.47)[ip: (-9.81), ipnet: 66.111.4.0/24(-4.81), asn: 11403(-2.68), country: US(-0.05)]; RCVD_IN_DNSWL_LOW(-0.10)[28.4.111.66.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 16:22:31 -0000 > On Aug 7, 2019, at 10:00 AM, John Baldwin wrote: >=20 > On 8/6/19 9:56 AM, Glen Barber wrote: >> On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: >>> Author: jhb >>> Date: Sat Aug 3 01:06:17 2019 >>> New Revision: 350550 >>> URL: https://svnweb.freebsd.org/changeset/base/350550 >>>=20 >>> Log: >>> Flip REPRODUCIBLE_BUILD back to off by default in head. >>>=20 >>> Having the full uname output can be useful on head even with >>> unmodified trees or trees that newvers.sh fails to recognize as >>> modified. >>>=20 >>> Reviewed by: emaste >>> Differential Revision: https://reviews.freebsd.org/D20895 >>>=20 >>=20 >> I would like to request this commit be reverted. While the original >> commit message to enable this knob stated the commit would be = reverted >> after stable/12 branched, I have seen no public complaints about >> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not = see >> the benefit of disabling it by default -- why wouldn't we want >> reproducibility?). >>=20 >> To me, this feels like a step backwards, with no tangible benefit. >> Note, newvers.sh does properly detect a modified tree if it can find >> the VCS metadata directory (i.e., .git, .svn) -- I know this because >> I personally helped with it. >>=20 >> In my opinion, those that want the non-reproducible metadata included = in >> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in = their >> src.conf. Turning off a sane default for the benefit of what I = suspect >> is likely a short list of use cases feels like a step in the wrong >> direction. >=20 > My arguments for flipping this in head (and head only) are that the = data > provided in uname -a when this is disabled is useful for development, = and > that in head we do tailor settings towards development (e.g. GENERIC = in > head vs GENERIC in stable). I=E2=80=99m in favor of how this works at the moment. It was a bit = jarring to me when the reproducible build flag was turned on and I lost all of the metadata = that I subconsciously use during development. I think that what John has = done is an appropriate compromise and is in line with how we=E2=80=99ve = treated similar development-facilitating features in the past, i.e. WITNESS/INVARIANTS, malloc-debug. Scott From owner-freebsd-arch@freebsd.org Wed Aug 7 16:24:28 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 391C4AF1D7 for ; Wed, 7 Aug 2019 16:24:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463cK73fmbz3QH8 for ; Wed, 7 Aug 2019 16:24:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x843.google.com with SMTP id h21so88883370qtn.13 for ; Wed, 07 Aug 2019 09:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n/Fm0FCS2HN/Egvw1tVv9mTzTn+zuyiqDM0UJqSx95U=; b=KSwI6alfRd194gxkmaG1kk+I9U26/37IuXj5dRlnju7BtJ6UrZY8+lRHornhgVPL4o or6umLNauDh9MCLGjzTMq60mq5PxDu+JnqEa9Pddt5AuBjtv5Ti3cTY533Y0nKDF6G3o SC4xy3m/K0/gOKLY9ilKOCvfzVYba9XfO5f0/oMwF+uN2uJ2AjSnCHkvHZopRRg1IlOG C5TOi6uKPcNF0I1sErXlQh7ko+KC7vD6PysgiIXTxkQRZbx6HO53RHLPfggSu0kMT9dy 5UIWhqJsiUJLHqonyqLMNr0qTRdOP4semacgm4snwCy5/hBhjn82vr4BMprfg6IJmAt1 8oog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n/Fm0FCS2HN/Egvw1tVv9mTzTn+zuyiqDM0UJqSx95U=; b=TntvgmcoOU0MdD5j9Bg5zj4baqQTgn01vl5ZcFODwKSnqJa3/yilnwvfJGT7VBBhPo 0Qb/T7I+Y0ht1vGwDNwnH41sH+RteXZ0iOH3+MAFy0Ib0g+E8vzJb/GFWcRNk1noXlQM 4LgkLYeWeZRgKzcEzkaXw8IqCJpct7oF3HNQxBfCEz/BdaXpSfIQP+FS/rQS0wv5Jk6M gzWH532StjoLesrmOoSKy4Cwdr4olcAbfixSmzQdqsWzc23YcDRKhf9PqOipK36PSLZ/ NCedi+B1jQUTt9r9UIZ5pYBv3Kyn/QBNqosR0j1JmAITFs0m1PQ+Mn1nylwwfP8+Wvdz 2mPQ== X-Gm-Message-State: APjAAAU9uzY64XJHBblFg3wMys6am3mK9oEuKMGoWSU1NwdD+xg++qtY cKD7L+iLFYBj5r2QglqzwOYzP7nixnAtGmNMLmBtwQ== X-Google-Smtp-Source: APXvYqwPIS5Fu8qMlm+LvPNDUCqwirihb14S3rYhnkP7sFwj7QAWzcdjATO32i8RnBDgu5xmXkNYSo0ZL3aVlVU9gd8= X-Received: by 2002:ac8:2baa:: with SMTP id m39mr9005043qtm.242.1565195066321; Wed, 07 Aug 2019 09:24:26 -0700 (PDT) MIME-Version: 1.0 References: <201908030106.x7316Ibx078529@repo.freebsd.org> <20190806165614.GA41295@FreeBSD.org> <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> In-Reply-To: <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> From: Warner Losh Date: Wed, 7 Aug 2019 10:24:15 -0600 Message-ID: Subject: Re: svn commit: r350550 - head/share/mk To: John Baldwin Cc: Glen Barber , svn-src-head , "freebsd-hackers@freebsd.org" , svn-src-all , src-committers , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 463cK73fmbz3QH8 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=KSwI6alf; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::843) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.61 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.983,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[9]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.99)[-0.991,0]; RCVD_IN_DNSWL_NONE(0.00)[3.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCPT_COUNT_SEVEN(0.00)[7]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.64)[ip: (2.33), ipnet: 2607:f8b0::/32(-3.03), asn: 15169(-2.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 16:24:28 -0000 On Wed, Aug 7, 2019 at 10:01 AM John Baldwin wrote: > On 8/6/19 9:56 AM, Glen Barber wrote: > > On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: > >> Author: jhb > >> Date: Sat Aug 3 01:06:17 2019 > >> New Revision: 350550 > >> URL: https://svnweb.freebsd.org/changeset/base/350550 > >> > >> Log: > >> Flip REPRODUCIBLE_BUILD back to off by default in head. > >> > >> Having the full uname output can be useful on head even with > >> unmodified trees or trees that newvers.sh fails to recognize as > >> modified. > >> > >> Reviewed by: emaste > >> Differential Revision: https://reviews.freebsd.org/D20895 > >> > > > > I would like to request this commit be reverted. While the original > > commit message to enable this knob stated the commit would be reverted > > after stable/12 branched, I have seen no public complaints about > > enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > > the benefit of disabling it by default -- why wouldn't we want > > reproducibility?). > > > > To me, this feels like a step backwards, with no tangible benefit. > > Note, newvers.sh does properly detect a modified tree if it can find > > the VCS metadata directory (i.e., .git, .svn) -- I know this because > > I personally helped with it. > > > > In my opinion, those that want the non-reproducible metadata included in > > output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their > > src.conf. Turning off a sane default for the benefit of what I suspect > > is likely a short list of use cases feels like a step in the wrong > > direction. > > My arguments for flipping this in head (and head only) are that the data > provided in uname -a when this is disabled is useful for development, and > that in head we do tailor settings towards development (e.g. GENERIC in > head vs GENERIC in stable). > > The logic to handle modified trees has an inherent assumption that I think > is false, at least for my workflow and I suspect many others. I do builds > and tests of kernels on separate machines (VMs or bare metal) from where I > use VCS to manage sources so that a kernel crash doesn't toast my source > tree. The trees are then shared to the build/test machines via NFS. As > a result, the build/test machines are not always able to detect that the > tree is modified either because a subset of the checkout is exported via > NFS, or the VCS tool isn't installed on the build/test machines because > they are generally barebones systems with only a base installed. This > does mean that flipping the knob off doesn't provide all of the same info, > but it does provide the path, and the path matters because 'kgdb -n last' > uses it, and because if you use separate directories for separate projects > (e.g. git worktrees), then the path tells you which test kernel you booted. > (It is not uncommon for me to have several test projects in flight on a > single test machine for different branches.) > > In the original discussion on arch, we collectively recognized that > developer builds vs release builds were different and needed different > defaults. The compromise reached at that time was to depend on the VCS > to detect developer builds to choose the policy. What I have found is that > in practice for at least my workflow that doesn't actually work. I posit > that the majority of kernels built from head are developer builds, not > releases, and that the default should cater to that. You could also always > patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I > think would give a more accurate sense of when builds are releases or not. > > However, I will yield to whatever the consensus is. > I'm with John here: the dirty tree stuff is too fragile for the diversity of development environments that are typical on -current, but not typical on -stable. We should not revert this. Warner From owner-freebsd-arch@freebsd.org Wed Aug 7 16:51:29 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A9B86B070F; Wed, 7 Aug 2019 16:51:29 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 463cwJ11Jdz40Dw; Wed, 7 Aug 2019 16:51:27 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id vP9nh4MQlIhW9vP9ohW99b; Wed, 07 Aug 2019 10:51:26 -0600 X-Authority-Analysis: v=2.3 cv=FcFJO626 c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=8nJEP1OIZ-IA:10 a=FmdZ9Uzk2mMA:10 a=-o65W9qwAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=N3yCi80q97NF-fv9y40A:9 a=wPNLvfGTeEIA:10 a=1tiFkAoI0pxFi1YEbzhn:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 32E1030D; Wed, 7 Aug 2019 09:51:22 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id x77GpLho055590; Wed, 7 Aug 2019 09:51:21 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id x77GpLBR055551; Wed, 7 Aug 2019 09:51:21 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201908071651.x77GpLBR055551@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Scott Long cc: John Baldwin , Glen Barber , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: svn commit: r350550 - head/share/mk In-reply-to: References: <201908030106.x7316Ibx078529@repo.freebsd.org> <20190806165614.GA41295@FreeBSD.org> <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> Comments: In-reply-to Scott Long message dated "Wed, 07 Aug 2019 10:22:24 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Wed, 07 Aug 2019 09:51:21 -0700 X-CMAE-Envelope: MS4wfD3GEMNYB235v89UuPrZvPA9ooszLwKhIXaveTtUWgl+RCuKVOeL/pE9e45rnZRgsgWD7g4Vag8Zu15QptSiER7CC9YU86hVxP4C1p05p6yOQY+FJs+L OYzvjmcQRTuIHCYZrECAI2PusblOheyxMT+Av9pKt2VygOcB4Lwh03mrJC26ocgCGAJlEow363Ir8uj7pOV0gQr8wxnqMdN8kHpPq6LKP1Iv6kqv3CWUtHsK 1RVTU4ImPrOsDiaCjHmpF9kYMq8wNlvNiuRa+Gq4XGQPHucaFvJIbk58XqQoKUZKkFeuQxXgcECrtY8vuz5devsZx3Dt2jkJm1kgZQcmpV8TF4LqpFirNuro KUWBf3Q/gBHttAZIFON7Z9vP2bmgiW8riW0zc5cKGeHpiJLwjYoz6RdZkSh9eTC8C6C1/ZEI X-Rspamd-Queue-Id: 463cwJ11Jdz40Dw X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.136.138) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-5.02 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; REPLYTO_EQ_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998,0]; RCVD_IN_DNSWL_NONE(0.00)[138.136.59.64.list.dnswl.org : 127.0.5.0]; RCPT_COUNT_SEVEN(0.00)[8]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.42)[ip: (-6.37), ipnet: 64.59.128.0/20(-3.18), asn: 6327(-2.48), country: CA(-0.09)]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 16:51:29 -0000 In message , Scott Long writes : > > > > On Aug 7, 2019, at 10:00 AM, John Baldwin wrote: > > > > On 8/6/19 9:56 AM, Glen Barber wrote: > >> On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: > >>> Author: jhb > >>> Date: Sat Aug 3 01:06:17 2019 > >>> New Revision: 350550 > >>> URL: https://svnweb.freebsd.org/changeset/base/350550 > >>> > >>> Log: > >>> Flip REPRODUCIBLE_BUILD back to off by default in head. > >>> > >>> Having the full uname output can be useful on head even with > >>> unmodified trees or trees that newvers.sh fails to recognize as > >>> modified. > >>> > >>> Reviewed by: emaste > >>> Differential Revision: https://reviews.freebsd.org/D20895 > >>> > >> > >> I would like to request this commit be reverted. While the original > >> commit message to enable this knob stated the commit would be reverted > >> after stable/12 branched, I have seen no public complaints about > >> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > >> the benefit of disabling it by default -- why wouldn't we want > >> reproducibility?). > >> > >> To me, this feels like a step backwards, with no tangible benefit. > >> Note, newvers.sh does properly detect a modified tree if it can find > >> the VCS metadata directory (i.e., .git, .svn) -- I know this because > >> I personally helped with it. > >> > >> In my opinion, those that want the non-reproducible metadata included in > >> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their > >> src.conf. Turning off a sane default for the benefit of what I suspect > >> is likely a short list of use cases feels like a step in the wrong > >> direction. > > > > My arguments for flipping this in head (and head only) are that the data > > provided in uname -a when this is disabled is useful for development, and > > that in head we do tailor settings towards development (e.g. GENERIC in > > head vs GENERIC in stable). > > I’m in favor of how this works at the moment. It was a bit jarring to me w > hen > the reproducible build flag was turned on and I lost all of the metadata that > I subconsciously use during development. I think that what John has done > is an appropriate compromise and is in line with how we’ve treated similar > development-facilitating features in the past, i.e. WITNESS/INVARIANTS, > malloc-debug. Agreed. As with John, I have a combination of git and svn trees on various machines. Some install to different partitions on physical hardware while others are tested in VMs. The extra information is handy in keeping track of what is installed where. End users who are concerned about reproducible builds in what we might call pseudo-production will probably not use WITNESS or INVARIANTS either. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Wed Aug 7 16:58:10 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8AC9FB0D77; Wed, 7 Aug 2019 16:58:10 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463d4239F0z40xL; Wed, 7 Aug 2019 16:58:10 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from [192.168.0.5] (unknown [181.52.72.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: pfg) by smtp.freebsd.org (Postfix) with ESMTPSA id C031315A91; Wed, 7 Aug 2019 16:58:09 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Subject: Re: svn commit: r350550 - head/share/mk To: src-committers@freebsd.org Cc: svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org References: <201908030106.x7316Ibx078529@repo.freebsd.org> <20190806165614.GA41295@FreeBSD.org> <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> From: Pedro Giffuni Organization: FreeBSD Message-ID: <86621ce5-3a8d-2e22-f146-3b0cc8252124@FreeBSD.org> Date: Wed, 7 Aug 2019 11:58:08 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 16:58:10 -0000 On 07/08/2019 11:00, John Baldwin wrote: > On 8/6/19 9:56 AM, Glen Barber wrote: >> On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: >>> Author: jhb >>> Date: Sat Aug 3 01:06:17 2019 >>> New Revision: 350550 >>> URL: https://svnweb.freebsd.org/changeset/base/350550 >>> >>> Log: >>> Flip REPRODUCIBLE_BUILD back to off by default in head. >>> >>> Having the full uname output can be useful on head even with >>> unmodified trees or trees that newvers.sh fails to recognize as >>> modified. >>> >>> Reviewed by: emaste >>> Differential Revision: https://reviews.freebsd.org/D20895 >>> >> I would like to request this commit be reverted. While the original >> commit message to enable this knob stated the commit would be reverted >> after stable/12 branched, I have seen no public complaints about >> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see >> the benefit of disabling it by default -- why wouldn't we want >> reproducibility?). >> >> To me, this feels like a step backwards, with no tangible benefit. >> Note, newvers.sh does properly detect a modified tree if it can find >> the VCS metadata directory (i.e., .git, .svn) -- I know this because >> I personally helped with it. >> >> In my opinion, those that want the non-reproducible metadata included in >> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their >> src.conf. Turning off a sane default for the benefit of what I suspect >> is likely a short list of use cases feels like a step in the wrong >> direction. > My arguments for flipping this in head (and head only) are that the data > provided in uname -a when this is disabled is useful for development, and > that in head we do tailor settings towards development (e.g. GENERIC in > head vs GENERIC in stable). > > The logic to handle modified trees has an inherent assumption that I think > is false, at least for my workflow and I suspect many others. I do builds > and tests of kernels on separate machines (VMs or bare metal) from where I > use VCS to manage sources so that a kernel crash doesn't toast my source > tree. The trees are then shared to the build/test machines via NFS. As > a result, the build/test machines are not always able to detect that the > tree is modified either because a subset of the checkout is exported via > NFS, or the VCS tool isn't installed on the build/test machines because > they are generally barebones systems with only a base installed. This > does mean that flipping the knob off doesn't provide all of the same info, > but it does provide the path, and the path matters because 'kgdb -n last' > uses it, and because if you use separate directories for separate projects > (e.g. git worktrees), then the path tells you which test kernel you booted. > (It is not uncommon for me to have several test projects in flight on a > single test machine for different branches.) > > In the original discussion on arch, we collectively recognized that > developer builds vs release builds were different and needed different > defaults. The compromise reached at that time was to depend on the VCS > to detect developer builds to choose the policy. What I have found is that > in practice for at least my workflow that doesn't actually work. I posit > that the majority of kernels built from head are developer builds, not > releases, and that the default should cater to that. You could also always > patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I > think would give a more accurate sense of when builds are releases or not. > > However, I will yield to whatever the consensus is. +1 keeping metadata in head. From owner-freebsd-arch@freebsd.org Wed Aug 7 20:12:26 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B26F5B6453; Wed, 7 Aug 2019 20:12:26 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 463jNB3W7bz4GTC; Wed, 7 Aug 2019 20:12:26 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x77KCOHh089133; Wed, 7 Aug 2019 13:12:24 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x77KCObt089132; Wed, 7 Aug 2019 13:12:24 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201908072012.x77KCObt089132@gndrsh.dnsmgr.net> Subject: Re: svn commit: r350550 - head/share/mk In-Reply-To: <86621ce5-3a8d-2e22-f146-3b0cc8252124@FreeBSD.org> To: Pedro Giffuni Date: Wed, 7 Aug 2019 13:12:24 -0700 (PDT) CC: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 463jNB3W7bz4GTC X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.95)[-0.954,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 20:12:26 -0000 > On 07/08/2019 11:00, John Baldwin wrote: > > On 8/6/19 9:56 AM, Glen Barber wrote: > >> On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: > >>> Author: jhb > >>> Date: Sat Aug 3 01:06:17 2019 > >>> New Revision: 350550 > >>> URL: https://svnweb.freebsd.org/changeset/base/350550 > >>> > >>> Log: > >>> Flip REPRODUCIBLE_BUILD back to off by default in head. > >>> > >>> Having the full uname output can be useful on head even with > >>> unmodified trees or trees that newvers.sh fails to recognize as > >>> modified. > >>> > >>> Reviewed by: emaste > >>> Differential Revision: https://reviews.freebsd.org/D20895 > >>> > >> I would like to request this commit be reverted. While the original > >> commit message to enable this knob stated the commit would be reverted > >> after stable/12 branched, I have seen no public complaints about > >> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > >> the benefit of disabling it by default -- why wouldn't we want > >> reproducibility?). > >> > >> To me, this feels like a step backwards, with no tangible benefit. > >> Note, newvers.sh does properly detect a modified tree if it can find > >> the VCS metadata directory (i.e., .git, .svn) -- I know this because > >> I personally helped with it. > >> > >> In my opinion, those that want the non-reproducible metadata included in > >> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their > >> src.conf. Turning off a sane default for the benefit of what I suspect > >> is likely a short list of use cases feels like a step in the wrong > >> direction. > > My arguments for flipping this in head (and head only) are that the data > > provided in uname -a when this is disabled is useful for development, and > > that in head we do tailor settings towards development (e.g. GENERIC in > > head vs GENERIC in stable). > > > > The logic to handle modified trees has an inherent assumption that I think > > is false, at least for my workflow and I suspect many others. I do builds > > and tests of kernels on separate machines (VMs or bare metal) from where I > > use VCS to manage sources so that a kernel crash doesn't toast my source > > tree. The trees are then shared to the build/test machines via NFS. As > > a result, the build/test machines are not always able to detect that the > > tree is modified either because a subset of the checkout is exported via > > NFS, or the VCS tool isn't installed on the build/test machines because > > they are generally barebones systems with only a base installed. This > > does mean that flipping the knob off doesn't provide all of the same info, > > but it does provide the path, and the path matters because 'kgdb -n last' > > uses it, and because if you use separate directories for separate projects > > (e.g. git worktrees), then the path tells you which test kernel you booted. > > (It is not uncommon for me to have several test projects in flight on a > > single test machine for different branches.) > > > > In the original discussion on arch, we collectively recognized that > > developer builds vs release builds were different and needed different > > defaults. The compromise reached at that time was to depend on the VCS > > to detect developer builds to choose the policy. What I have found is that > > in practice for at least my workflow that doesn't actually work. I posit > > that the majority of kernels built from head are developer builds, not > > releases, and that the default should cater to that. You could also always > > patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I > > think would give a more accurate sense of when builds are releases or not. > > > > However, I will yield to whatever the consensus is. > > +1 keeping metadata in head. I am conflicted on this one, and I think there is a reasonable argument on both sides, but from what I have read here this appears to be mostly the kernel that is at issue, loss of the meta data from newvers.sh in the kernel is infact a PITA, even on stable or production release systems. I propose a compromise, add 2 knobs: WITHOUT_REPRODUCIBLE_KERNEL (aka get your metadata in uname) WITH_REPRODUCIBLE_USERLAND (aka reproducible userland) WITH{,OUT}_REPRODUCIBLE_BUILD overrides both, for backwards compat, and neither should be defined by default. Somehow set WITH_REPRODUCIBLE_KERNEL for builds of GENERIC for releases/snapshots, but do not ship the system with it set (I can here a growl from Glen on this) Thus we build a reproducible kernel and ship it with the system but if the user builds a kernel it gets meta data to indicate it is no longer a stock kernel. FYI, upon finding I could not figure out what kernel I was running after installing 12.0 release I turnd off REPRODUCIBLE on my kernel build VM for 12.0. I do leave it on if I am building userland. Thoughts? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Wed Aug 7 20:14:53 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8BBDBB663E for ; Wed, 7 Aug 2019 20:14:53 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 463jR03lS2z4GwB for ; Wed, 7 Aug 2019 20:14:52 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7F96522022 for ; Wed, 7 Aug 2019 16:14:51 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 07 Aug 2019 16:14:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=dQh3nAkJc1evcwMAGC9kr1RRAOZ y21bZZbJ/eFlY4ZI=; b=JCiIkH74bSx6vKCOEDWEeJZYssH8gFeB3ZAKI64XJ0v V3mmaAS92f0auKPcXAmLp2YHMYK3XkBrBj4ykplkRgthwcx9zrFth+XOgx0iOg7E ufegWGnMkLJElgwX4aconYE/TPmsltq6YAqKTRiaVyfpRRxEMJUtl4Cstyj4Aatf g+MVM7uhL4Aho0NNwDxQYwa11IJSSMT5Yl+V7b5koYJ1syAvkbnC472bmo1tZmxh jsHvstPgqsZTfVw1dRQGHRZpI6wTSNtWC9vnF8RLe0XVHRgiXHSaZ+5GX3V2u1/9 Xg7IwQypL2+xEOQZtOTBqqsQn7jqI/t1bBumw9MPJPQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=dQh3nA kJc1evcwMAGC9kr1RRAOZy21bZZbJ/eFlY4ZI=; b=LwGMphsteSBJIAnShbUiiH IU6chMxNcinBiWodIU2k0lhWL7L59z6xc+gyloctIpU9i2vvlnexp2XJVrNVYfUD LCnK3v6iKcl+OflXIuynoFOAbcPlu2CBzmlJCYflNjmCh4nrxjurQEqdXVO7JPI9 33Hea8tfPF9nspzIDRBn1Wpa6xQVl+MiY4hic5eNy++VUmgI+umhBq31hGDCLpO3 qU09e86lLV2QsVmTuf8t1cKoOaksP01fM9myFRkaV2mtTv7Eyq+MYgxv+3D7EbxR 94F0oalUeSgU/xULkdwpeofpwFSuX5L4nwaaEnN3Wd97NRCjRzIy1xYIy5PNWPPw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduvddgudegiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjfgesgh dtreertdervdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhs seiihiigshhtrdhnvghtqeenucfkphepkedvrdejtddrledurdelleenucfrrghrrghmpe hmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: from bastion.zyxst.net (unknown [82.70.91.99]) by mail.messagingengine.com (Postfix) with ESMTPA id 42465380074 for ; Wed, 7 Aug 2019 16:14:50 -0400 (EDT) Date: Wed, 7 Aug 2019 21:14:48 +0100 From: tech-lists To: freebsd-arch@freebsd.org Subject: Re: svn commit: r350550 - head/share/mk Message-ID: <20190807201448.GA42725@bastion.zyxst.net> References: <201908030106.x7316Ibx078529@repo.freebsd.org> <20190806165614.GA41295@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: <20190806165614.GA41295@FreeBSD.org> User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 463jR03lS2z4GwB X-Spamd-Bar: --------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm3 header.b=JCiIkH74; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=LwGMphst; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.25 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-9.15 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm3,messagingengine.com:s=fm3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[zyxst.net]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.999,0]; SIGNED_PGP(-2.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[25.4.111.66.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-3.45)[ip: (-9.69), ipnet: 66.111.4.0/24(-4.81), asn: 11403(-2.68), country: US(-0.05)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 20:14:53 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Tue, Aug 06, 2019 at 04:56:14PM +0000, Glen Barber wrote: >I would like to request this commit be reverted. While the original >commit message to enable this knob stated the commit would be reverted >after stable/12 branched, I have seen no public complaints about >enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see >the benefit of disabling it by default -- why wouldn't we want >reproducibility?). > >To me, this feels like a step backwards, with no tangible benefit. >Note, newvers.sh does properly detect a modified tree if it can find >the VCS metadata directory (i.e., .git, .svn) -- I know this because >I personally helped with it. > >In my opinion, those that want the non-reproducible metadata included in >output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their >src.conf. Turning off a sane default for the benefit of what I suspect >is likely a short list of use cases feels like a step in the wrong >direction. Well, my use case is that I have some machines that follow 12-stable. I'm not a developer. But I keep an eye on things like security bulletins etc and when they come out it usually gives something like 'affecting 12-STABLE prior to r something like that. And I can easily look at uname -a to see if this or that 12-stable machine needs to be patched or whatever. That is, if reproductible_build is turned off. (or without_reproductible_build is turned on)=20 Or if I mail to stable@ asking for help I'll want to say *exactly* what sources I've built from. And sometimes someone will say "oh that was fixed after r" and so I'll grab sources after that revision=20 if I can and fix the problem. But like I say I'm not a dev. I'd guess, though, that lots of non-devs=20 use the revision info if they follow -stable, so if I'm right in thinking= =20 this, it'd be a short list of use cases but lots of affected people. unless there's another way to get the svn rev number? Why turn off this functionality by default? --=20 J. --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAl1LMSMACgkQs8o7QhFz NAU4xBAAh8VrhAoR/9icuzCvBWyh8KAAgrIZEbBM+qXyRDI0bDD41U3r1XRGfuKo 7/3TvaJipRhtXv0VPRdo495Plq9gUX/9uQzoMsd7p0gtZ/4zqu8/+hMrERcwPsrl m9V3upO0J9bVycQb7Wl0jYqPIkttoTa/Jzm/enqJLFCfa29igakOn5Xx9Y/HeCUw chd7I2jm7cwXqz6M7kzt4N+AeR5Cee1LVTfrfWWs8S9nuJMxR1giI1jHrJvpeATn SPk9FhBCKZq0YjXI4RWY9iM2R+PaXz5+VuAdyW58ksCXDL1XY2q0aT0YiVh7lQRP QFNblzjJXAH7dSBlgdWp3KS0aZ0OEd8+fnA0WFU+xuIOrBdF1YLv/l38HXQ1eSOn Phf665cLqPwlJGW+kNUyEaFs1d+MbPsfsiM9FGxC8wAYsVESVTbeE7qioytoyd4Z 7MvBVgqXZw6iIFWXeBYabT4MPlsLvRn0YXWUr1fuINfPN5GsnEvd56cQnipv11tG hTAEe4hIzaKq7gZywaqJshQGb86fHHv/GqJ85Um4fqFqPOubdg1W3a1XcCnpMxDG EPiYCGhbgrOXKYKJF869NSjOv+lBVUHuchm1FRhLqO2kngL84qdHgOTP/WKFbgLh l2E4bhP4KaSj48GmzyedBT3PKjLrqp+Xg1t2/4waDNPxDeefZQU= =CYHZ -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From owner-freebsd-arch@freebsd.org Wed Aug 7 20:27:50 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 738B9B6BA6; Wed, 7 Aug 2019 20:27:50 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463jjy2YpKz4HkD; Wed, 7 Aug 2019 20:27:50 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from [192.168.0.5] (unknown [181.52.72.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: pfg) by smtp.freebsd.org (Postfix) with ESMTPSA id 59B6A17353; Wed, 7 Aug 2019 20:27:49 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Subject: Re: svn commit: r350550 - head/share/mk To: rgrimes@freebsd.org Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org References: <201908072012.x77KCObt089132@gndrsh.dnsmgr.net> From: Pedro Giffuni Organization: FreeBSD Message-ID: Date: Wed, 7 Aug 2019 15:27:48 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <201908072012.x77KCObt089132@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 20:27:50 -0000 On 07/08/2019 15:12, Rodney W. Grimes wrote: >> On 07/08/2019 11:00, John Baldwin wrote: >>> On 8/6/19 9:56 AM, Glen Barber wrote: >>>> On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: >>>>> Author: jhb >>>>> Date: Sat Aug 3 01:06:17 2019 >>>>> New Revision: 350550 >>>>> URL: https://svnweb.freebsd.org/changeset/base/350550 >>>>> >>>>> Log: >>>>> Flip REPRODUCIBLE_BUILD back to off by default in head. >>>>> >>>>> Having the full uname output can be useful on head even with >>>>> unmodified trees or trees that newvers.sh fails to recognize as >>>>> modified. >>>>> >>>>> Reviewed by: emaste >>>>> Differential Revision: https://reviews.freebsd.org/D20895 >>>>> >>>> I would like to request this commit be reverted. While the original >>>> commit message to enable this knob stated the commit would be reverted >>>> after stable/12 branched, I have seen no public complaints about >>>> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see >>>> the benefit of disabling it by default -- why wouldn't we want >>>> reproducibility?). >>>> >>>> To me, this feels like a step backwards, with no tangible benefit. >>>> Note, newvers.sh does properly detect a modified tree if it can find >>>> the VCS metadata directory (i.e., .git, .svn) -- I know this because >>>> I personally helped with it. >>>> >>>> In my opinion, those that want the non-reproducible metadata included in >>>> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their >>>> src.conf. Turning off a sane default for the benefit of what I suspect >>>> is likely a short list of use cases feels like a step in the wrong >>>> direction. >>> My arguments for flipping this in head (and head only) are that the data >>> provided in uname -a when this is disabled is useful for development, and >>> that in head we do tailor settings towards development (e.g. GENERIC in >>> head vs GENERIC in stable). >>> >>> The logic to handle modified trees has an inherent assumption that I think >>> is false, at least for my workflow and I suspect many others. I do builds >>> and tests of kernels on separate machines (VMs or bare metal) from where I >>> use VCS to manage sources so that a kernel crash doesn't toast my source >>> tree. The trees are then shared to the build/test machines via NFS. As >>> a result, the build/test machines are not always able to detect that the >>> tree is modified either because a subset of the checkout is exported via >>> NFS, or the VCS tool isn't installed on the build/test machines because >>> they are generally barebones systems with only a base installed. This >>> does mean that flipping the knob off doesn't provide all of the same info, >>> but it does provide the path, and the path matters because 'kgdb -n last' >>> uses it, and because if you use separate directories for separate projects >>> (e.g. git worktrees), then the path tells you which test kernel you booted. >>> (It is not uncommon for me to have several test projects in flight on a >>> single test machine for different branches.) >>> >>> In the original discussion on arch, we collectively recognized that >>> developer builds vs release builds were different and needed different >>> defaults. The compromise reached at that time was to depend on the VCS >>> to detect developer builds to choose the policy. What I have found is that >>> in practice for at least my workflow that doesn't actually work. I posit >>> that the majority of kernels built from head are developer builds, not >>> releases, and that the default should cater to that. You could also always >>> patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I >>> think would give a more accurate sense of when builds are releases or not. >>> >>> However, I will yield to whatever the consensus is. >> +1 keeping metadata in head. > I am conflicted on this one, and I think there is a reasonable argument > on both sides, but from what I have read here this appears to be mostly > the kernel that is at issue, loss of the meta data from newvers.sh in > the kernel is infact a PITA, even on stable or production release > systems. > > I propose a compromise, add 2 knobs: > WITHOUT_REPRODUCIBLE_KERNEL (aka get your metadata in uname) > WITH_REPRODUCIBLE_USERLAND (aka reproducible userland) > > WITH{,OUT}_REPRODUCIBLE_BUILD overrides both, for backwards compat, > and neither should be defined by default. Too complex IMHO. Either the system is reproducible or it isn't. > Somehow set WITH_REPRODUCIBLE_KERNEL for builds of GENERIC > for releases/snapshots, but do not ship the system with it > set (I can here a growl from Glen on this) Thus we build > a reproducible kernel and ship it with the system but if > the user builds a kernel it gets meta data to indicate it > is no longer a stock kernel. > FYI, upon finding I could not figure out what kernel I was running > after installing 12.0 release I turnd off REPRODUCIBLE on my kernel > build VM for 12.0. I do leave it on if I am building userland. > > Thoughts? Among other things, reproducible builds implies that pkg upgrades are smaller. I see it makes sense to make releases, and in fact -stable, completely reproducible. For -current I am fine with it not being reproducible, All just IMHO. Pedro. From owner-freebsd-arch@freebsd.org Wed Aug 7 20:41:16 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DBF43B73B1; Wed, 7 Aug 2019 20:41:16 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 463k1R2q6lz4Jr1; Wed, 7 Aug 2019 20:41:14 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x77KfDIK089237; Wed, 7 Aug 2019 13:41:13 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x77KfDv1089236; Wed, 7 Aug 2019 13:41:13 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201908072041.x77KfDv1089236@gndrsh.dnsmgr.net> Subject: Re: svn commit: r350550 - head/share/mk In-Reply-To: To: Pedro Giffuni Date: Wed, 7 Aug 2019 13:41:13 -0700 (PDT) CC: rgrimes@freebsd.org, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 463k1R2q6lz4Jr1 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd@gndrsh.dnsmgr.net X-Spamd-Result: default: False [1.72 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[rgrimes@freebsd.org]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; NEURAL_SPAM_MEDIUM(0.73)[0.727,0]; IP_SCORE(0.05)[ip: (0.15), ipnet: 69.59.192.0/19(0.08), asn: 13868(0.05), country: US(-0.05)]; NEURAL_HAM_SHORT(-0.63)[-0.630,0]; NEURAL_SPAM_LONG(0.68)[0.679,0]; RCPT_COUNT_SEVEN(0.00)[7]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 20:41:16 -0000 > On 07/08/2019 15:12, Rodney W. Grimes wrote: > >> On 07/08/2019 11:00, John Baldwin wrote: > >>> On 8/6/19 9:56 AM, Glen Barber wrote: > >>>> On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: > >>>>> Author: jhb > >>>>> Date: Sat Aug 3 01:06:17 2019 > >>>>> New Revision: 350550 > >>>>> URL: https://svnweb.freebsd.org/changeset/base/350550 > >>>>> > >>>>> Log: > >>>>> Flip REPRODUCIBLE_BUILD back to off by default in head. > >>>>> > >>>>> Having the full uname output can be useful on head even with > >>>>> unmodified trees or trees that newvers.sh fails to recognize as > >>>>> modified. > >>>>> > >>>>> Reviewed by: emaste > >>>>> Differential Revision: https://reviews.freebsd.org/D20895 > >>>>> > >>>> I would like to request this commit be reverted. While the original > >>>> commit message to enable this knob stated the commit would be reverted > >>>> after stable/12 branched, I have seen no public complaints about > >>>> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > >>>> the benefit of disabling it by default -- why wouldn't we want > >>>> reproducibility?). > >>>> > >>>> To me, this feels like a step backwards, with no tangible benefit. > >>>> Note, newvers.sh does properly detect a modified tree if it can find > >>>> the VCS metadata directory (i.e., .git, .svn) -- I know this because > >>>> I personally helped with it. > >>>> > >>>> In my opinion, those that want the non-reproducible metadata included in > >>>> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their > >>>> src.conf. Turning off a sane default for the benefit of what I suspect > >>>> is likely a short list of use cases feels like a step in the wrong > >>>> direction. > >>> My arguments for flipping this in head (and head only) are that the data > >>> provided in uname -a when this is disabled is useful for development, and > >>> that in head we do tailor settings towards development (e.g. GENERIC in > >>> head vs GENERIC in stable). > >>> > >>> The logic to handle modified trees has an inherent assumption that I think > >>> is false, at least for my workflow and I suspect many others. I do builds > >>> and tests of kernels on separate machines (VMs or bare metal) from where I > >>> use VCS to manage sources so that a kernel crash doesn't toast my source > >>> tree. The trees are then shared to the build/test machines via NFS. As > >>> a result, the build/test machines are not always able to detect that the > >>> tree is modified either because a subset of the checkout is exported via > >>> NFS, or the VCS tool isn't installed on the build/test machines because > >>> they are generally barebones systems with only a base installed. This > >>> does mean that flipping the knob off doesn't provide all of the same info, > >>> but it does provide the path, and the path matters because 'kgdb -n last' > >>> uses it, and because if you use separate directories for separate projects > >>> (e.g. git worktrees), then the path tells you which test kernel you booted. > >>> (It is not uncommon for me to have several test projects in flight on a > >>> single test machine for different branches.) > >>> > >>> In the original discussion on arch, we collectively recognized that > >>> developer builds vs release builds were different and needed different > >>> defaults. The compromise reached at that time was to depend on the VCS > >>> to detect developer builds to choose the policy. What I have found is that > >>> in practice for at least my workflow that doesn't actually work. I posit > >>> that the majority of kernels built from head are developer builds, not > >>> releases, and that the default should cater to that. You could also always > >>> patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I > >>> think would give a more accurate sense of when builds are releases or not. > >>> > >>> However, I will yield to whatever the consensus is. > >> +1 keeping metadata in head. > > I am conflicted on this one, and I think there is a reasonable argument > > on both sides, but from what I have read here this appears to be mostly > > the kernel that is at issue, loss of the meta data from newvers.sh in > > the kernel is infact a PITA, even on stable or production release > > systems. > > > > I propose a compromise, add 2 knobs: > > WITHOUT_REPRODUCIBLE_KERNEL (aka get your metadata in uname) > > WITH_REPRODUCIBLE_USERLAND (aka reproducible userland) > > > > WITH{,OUT}_REPRODUCIBLE_BUILD overrides both, for backwards compat, > > and neither should be defined by default. > Too complex IMHO. Either the system is reproducible or it isn't. > > Somehow set WITH_REPRODUCIBLE_KERNEL for builds of GENERIC > > for releases/snapshots, but do not ship the system with it > > set (I can here a growl from Glen on this) Thus we build > > a reproducible kernel and ship it with the system but if > > the user builds a kernel it gets meta data to indicate it > > is no longer a stock kernel. > > FYI, upon finding I could not figure out what kernel I was running > > after installing 12.0 release I turnd off REPRODUCIBLE on my kernel > > build VM for 12.0. I do leave it on if I am building userland. > > > > Thoughts? > > Among other things, reproducible builds implies that pkg upgrades are Do you mean freebsd-update? > smaller. I see it makes sense to make releases, and in fact -stable, > completely reproducible. For -current I am fine with it not being > reproducible, > > All just IMHO. Let me try to add a case for it on ^head, weekly snapshots are built, if ^head was running reproducible it would be possible to diff these snapshots in a meaniful way. It would also mean one could get pretty creative with ZFS, zfs-snapshots and the built snapshots to actually have on line almost all binary versions of ^head in a fairly compact form. > Pedro. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Wed Aug 7 20:50:08 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 675D1B76A5 for ; Wed, 7 Aug 2019 20:50:08 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 463kCg3vFKz4KKD for ; Wed, 7 Aug 2019 20:50:07 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x77Ko5AH089299; Wed, 7 Aug 2019 13:50:05 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x77Ko5QD089298; Wed, 7 Aug 2019 13:50:05 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201908072050.x77Ko5QD089298@gndrsh.dnsmgr.net> Subject: Re: svn commit: r350550 - head/share/mk In-Reply-To: <20190807201448.GA42725@bastion.zyxst.net> To: tech-lists Date: Wed, 7 Aug 2019 13:50:05 -0700 (PDT) CC: freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 463kCg3vFKz4KKD X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [0.02 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.29)[-0.289,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.11)[0.106,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.74)[-0.742,0]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.05)[ip: (0.15), ipnet: 69.59.192.0/19(0.08), asn: 13868(0.05), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 20:50:08 -0000 > Hello, > > On Tue, Aug 06, 2019 at 04:56:14PM +0000, Glen Barber wrote: > > >I would like to request this commit be reverted. While the original > >commit message to enable this knob stated the commit would be reverted > >after stable/12 branched, I have seen no public complaints about > >enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > >the benefit of disabling it by default -- why wouldn't we want > >reproducibility?). > > > >To me, this feels like a step backwards, with no tangible benefit. > >Note, newvers.sh does properly detect a modified tree if it can find > >the VCS metadata directory (i.e., .git, .svn) -- I know this because > >I personally helped with it. > > > >In my opinion, those that want the non-reproducible metadata included in > >output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their > >src.conf. Turning off a sane default for the benefit of what I suspect > >is likely a short list of use cases feels like a step in the wrong > >direction. > > Well, my use case is that I have some machines that follow 12-stable. > > I'm not a developer. But I keep an eye on things like security bulletins > etc and when they come out it usually gives something like 'affecting > 12-STABLE prior to r something like that. And I can easily look > at uname -a to see if this or that 12-stable machine needs to be patched > or whatever. That is, if reproductible_build is turned off. (or > without_reproductible_build is turned on) > > Or if I mail to stable@ asking for help I'll want to say *exactly* what > sources I've built from. And sometimes someone will say "oh that was > fixed after r" and so I'll grab sources after that revision > if I can and fix the problem. > > But like I say I'm not a dev. I'd guess, though, that lots of non-devs > use the revision info if they follow -stable, so if I'm right in thinking > this, it'd be a short list of use cases but lots of affected people. > > unless there's another way to get the svn rev number? > > Why turn off this functionality by default? > -- > J. Actually you have a very good point here. Let me raise the issue, the rXXXXXX is infact reproducible, why is that being excluded from reproducible builds? If I build from the same source at the same version I get the same rXXXXX string in the resulting file. This is reproducible. So WHY are we excluding rXXXXXX from the reproducible build? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Wed Aug 7 21:08:28 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8C9FDB7EC4 for ; Wed, 7 Aug 2019 21:08:28 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463kcq58X2z4LYg for ; Wed, 7 Aug 2019 21:08:27 +0000 (UTC) (envelope-from delphij@gmail.com) Received: by mail-ot1-x342.google.com with SMTP id l15so52757411oth.7 for ; Wed, 07 Aug 2019 14:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CmJwj/wnplZt9NdsZr5NOIv7Ie6P1+Bm9d/Xa2XSOjc=; b=RJR3wW5f2cj8FTcl3AU2pR/y47gOPwYBFxx0MSc+Vc36XWDDXLXdwOrfXqzJc1RCXH S/bvBY3n8Yx//k9NwXeUvM/qzd8rMf7aj4eTrqSk3J5LbZFcL4cK0jgaZTRoUymJtvEz e1MB8vH1ZLEs9+rXEr/pblB/i/zeMkOu+nrwAC7Dg7byJMeD0fnMpSgUVs7KQMjzaW/C HfhDkjxqSdlgBR2T6Q/C1fPS9YXfpWp4IigsV/4Y5tECww/fy1GMI3XAQc4AsmAwY2Un umkWQnmureY7q8RKQffR3agxEphcWxt58kuW/jOsEiff6Z5GKhfPXmXW5/U4YhGEXxtV 4txw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CmJwj/wnplZt9NdsZr5NOIv7Ie6P1+Bm9d/Xa2XSOjc=; b=Nx2LIYA7a83jmZJteoJ3ynfwzwm2kOtr/UWg5tWkj6ocZAbXi21wcGNHgjnlNmhQBR Z+rHxXsRKjlWydVU6gxCLIo9xz+T9hD0YYdEmUeMN7hKuJdsyYLzrLDqwbzmSAGK1SVA aM/jPAHy6HQC0a0kC3MXozxDeihk0rXdLhxv05cT3jkU8Ziy41Izxyg30Fvv0UdHaKIL x1VNImLyjNNGlPilPUwvaza/tTpr2+rxDql0HOdVAM4ub9Jow7TG/FO9QHre4oUllERT aO/84nsvhwlzdC/uu9anjfzTn/ySFAicW0iX7D3ebgpvyUe9fuJzVJdOR2wJm6s0Rohx F7qQ== X-Gm-Message-State: APjAAAVXJTh9JNwsvPk1B6yRNehz9F7nz3M3B6BgymUPAoN8yDEZUm3U PX+wIJ3KhJiLzECo+cfzh10GaslQnGKmMymf+v4= X-Google-Smtp-Source: APXvYqwEhjyFyiycGfl3BqADNuEhFqSR0Va4ayxw0Ww6nEFA4axj0KmbXAZd/IcjaUSGiYF8We4yTRIlBruJRqgdEmI= X-Received: by 2002:a05:6808:a04:: with SMTP id n4mr109927oij.40.1565212106244; Wed, 07 Aug 2019 14:08:26 -0700 (PDT) MIME-Version: 1.0 References: <20190807201448.GA42725@bastion.zyxst.net> <201908072050.x77Ko5QD089298@gndrsh.dnsmgr.net> In-Reply-To: <201908072050.x77Ko5QD089298@gndrsh.dnsmgr.net> From: Xin LI Date: Wed, 7 Aug 2019 14:08:14 -0700 Message-ID: Subject: Re: svn commit: r350550 - head/share/mk To: "Rodney W. Grimes" Cc: tech-lists , freebsd-arch@freebsd.org X-Rspamd-Queue-Id: 463kcq58X2z4LYg X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=RJR3wW5f; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of delphij@gmail.com designates 2607:f8b0:4864:20::342 as permitted sender) smtp.mailfrom=delphij@gmail.com X-Spamd-Result: default: False [-2.98 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[1]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (2.58), ipnet: 2607:f8b0::/32(-3.03), asn: 15169(-2.43), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2.4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 21:08:28 -0000 On Wed, Aug 7, 2019 at 1:50 PM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > Hello, > > > > On Tue, Aug 06, 2019 at 04:56:14PM +0000, Glen Barber wrote: > > > > >I would like to request this commit be reverted. While the original > > >commit message to enable this knob stated the commit would be reverted > > >after stable/12 branched, I have seen no public complaints about > > >enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > > >the benefit of disabling it by default -- why wouldn't we want > > >reproducibility?). > > > > > >To me, this feels like a step backwards, with no tangible benefit. > > >Note, newvers.sh does properly detect a modified tree if it can find > > >the VCS metadata directory (i.e., .git, .svn) -- I know this because > > >I personally helped with it. > > > > > >In my opinion, those that want the non-reproducible metadata included in > > >output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their > > >src.conf. Turning off a sane default for the benefit of what I suspect > > >is likely a short list of use cases feels like a step in the wrong > > >direction. > > > > Well, my use case is that I have some machines that follow 12-stable. > > > > I'm not a developer. But I keep an eye on things like security bulletins > > etc and when they come out it usually gives something like 'affecting > > 12-STABLE prior to r something like that. And I can easily look > > at uname -a to see if this or that 12-stable machine needs to be patched > > or whatever. That is, if reproductible_build is turned off. (or > > without_reproductible_build is turned on) > > > > Or if I mail to stable@ asking for help I'll want to say *exactly* what > > sources I've built from. And sometimes someone will say "oh that was > > fixed after r" and so I'll grab sources after that revision > > if I can and fix the problem. > > > > But like I say I'm not a dev. I'd guess, though, that lots of non-devs > > use the revision info if they follow -stable, so if I'm right in > thinking > > this, it'd be a short list of use cases but lots of affected people. > > > > unless there's another way to get the svn rev number? > > > > Why turn off this functionality by default? > > -- > > J. > > Actually you have a very good point here. > Let me raise the issue, the rXXXXXX is infact reproducible, why is > that being excluded from reproducible builds? If I build from the > same source at the same version I get the same rXXXXX string in > the resulting file. This is reproducible. > > So WHY are we excluding rXXXXXX from the reproducible build? > Because svnversion returns the base revision (the repository revision as of last checkout) instead of the 'COMMITTED' revision (the last commit revision of the working copy that was checked out), and it means for the same set of source, there can be multiple possibilities, making it no longer reproducible? I haven't dig deep on this topic, but it seems that parsing 'svn info' output would solve it (by using "Last Changed Rev:" value). This issue do not exist on git. From owner-freebsd-arch@freebsd.org Wed Aug 7 21:26:31 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0D623B8796 for ; Wed, 7 Aug 2019 21:26:31 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463l1f6cLCz4Md7; Wed, 7 Aug 2019 21:26:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-4.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 72D0017A55; Wed, 7 Aug 2019 21:26:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: svn commit: r350550 - head/share/mk To: tech-lists , freebsd-arch@freebsd.org References: <201908030106.x7316Ibx078529@repo.freebsd.org> <20190806165614.GA41295@FreeBSD.org> <20190807201448.GA42725@bastion.zyxst.net> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <1603dc7f-f840-3ad6-b1e5-68871eeead9b@FreeBSD.org> Date: Wed, 7 Aug 2019 14:26:29 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <20190807201448.GA42725@bastion.zyxst.net> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 21:26:31 -0000 On 8/7/19 1:14 PM, tech-lists wrote: > Hello, > > On Tue, Aug 06, 2019 at 04:56:14PM +0000, Glen Barber wrote: > >> I would like to request this commit be reverted. While the original >> commit message to enable this knob stated the commit would be reverted >> after stable/12 branched, I have seen no public complaints about >> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see >> the benefit of disabling it by default -- why wouldn't we want >> reproducibility?). >> >> To me, this feels like a step backwards, with no tangible benefit. >> Note, newvers.sh does properly detect a modified tree if it can find >> the VCS metadata directory (i.e., .git, .svn) -- I know this because >> I personally helped with it. >> >> In my opinion, those that want the non-reproducible metadata included in >> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their >> src.conf. Turning off a sane default for the benefit of what I suspect >> is likely a short list of use cases feels like a step in the wrong >> direction. > > Well, my use case is that I have some machines that follow 12-stable. > > I'm not a developer. But I keep an eye on things like security bulletins > etc and when they come out it usually gives something like 'affecting > 12-STABLE prior to r something like that. And I can easily look > at uname -a to see if this or that 12-stable machine needs to be patched > or whatever. That is, if reproductible_build is turned off. (or > without_reproductible_build is turned on) > > Or if I mail to stable@ asking for help I'll want to say *exactly* what > sources I've built from. And sometimes someone will say "oh that was > fixed after r" and so I'll grab sources after that revision > if I can and fix the problem. > > But like I say I'm not a dev. I'd guess, though, that lots of non-devs > use the revision info if they follow -stable, so if I'm right in thinking > this, it'd be a short list of use cases but lots of affected people. > > unless there's another way to get the svn rev number? > > Why turn off this functionality by default? If you have checked out the sources using svn, I believe you get the svn revision number in uname -a even with the knob enabled. The knob is more about other metadata fields such as the source pathname and date/time of the build. -- John Baldwin From owner-freebsd-arch@freebsd.org Wed Aug 7 22:19:51 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 93EC8B9921 for ; Wed, 7 Aug 2019 22:19:51 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 463mCB4mq5z4QH9 for ; Wed, 7 Aug 2019 22:19:50 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C430C21B62 for ; Wed, 7 Aug 2019 18:19:49 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 07 Aug 2019 18:19:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=xYcomtvsg47Tt2dTpJFRoY29qQ7 6QiwN/BV6yyfnUWY=; b=eZ4pNKqcHg4J//hcBq+/G3qlZyEbcWXV6vArATPgpt8 /FtD5T2lnPLkzxVzLIrIZXmuYmlohbHATSrzpUwbJvPPGty0R2z16521agsiQbkD R3LRp3o+ZhkOiNkxYIIp/7NsjO3ZGk8t5/2cB3ZVc6c4IKAAL09rKbIVGYQUT8DW xUXnHP6MHdtgmu3DRxvayMu1KLcShegJKeB9h5sCNDGJOicvli60A3e4YddcH1gY zB1lPqiboYpT1bhWamDynCXGEE/yq/rgrAXgc8EU6+HhgYa8Fp5VRALAHJPc090i RfMvzad/80+1mL7YNYcUsH9DTb1yvmrFhSYBU7anWlg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=xYcomt vsg47Tt2dTpJFRoY29qQ76QiwN/BV6yyfnUWY=; b=qLPBZgbGXUOP8GyZ45it7/ gi/OxmeLt6p8jMagyvor3K8nK2mU/zl2ryKHk80+1Nd/4cpqsDyL5R1YvWyyCy+Q nhBO6hJQDFyon6k+kDB4xS67zFySpDEj0Hi/1/R6t2LCJNTF6tYUTyGj/Fli/lDK fU4BA9NYPFh3MNz2xqxFoXYMNbyYojmMfwqYmokizQUPDdzrnH5j+NR553U2FziC B3nRcEQTevUQRNyly4A+WWDs4KrcUxIDSg04bLkZ8AM5rn0lroGFIIceEB/HQToV rN5vR2drnemU0HL+2vWGBTrDZkyolqc7eIH7pvelBIPPeUOSULv+zLKN+OS7tgIQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddufedguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehgtd erredtredvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshes iiihgihsthdrnhgvtheqnecukfhppeekvddrjedtrdeluddrleelnecurfgrrhgrmhepmh grihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: from bastion.zyxst.net (unknown [82.70.91.99]) by mail.messagingengine.com (Postfix) with ESMTPA id F2A0B380075 for ; Wed, 7 Aug 2019 18:19:48 -0400 (EDT) Date: Wed, 7 Aug 2019 23:19:46 +0100 From: tech-lists To: freebsd-arch@freebsd.org Subject: Re: svn commit: r350550 - head/share/mk Message-ID: <20190807221946.GB42725@bastion.zyxst.net> References: <20190807201448.GA42725@bastion.zyxst.net> <201908072050.x77Ko5QD089298@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dc+cDN39EJAMEtIO" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 463mCB4mq5z4QH9 X-Spamd-Bar: --------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm3 header.b=eZ4pNKqc; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=qLPBZgbG; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.26 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-9.13 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm3,messagingengine.com:s=fm3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[zyxst.net]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; SIGNED_PGP(-2.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[26.4.111.66.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-3.44)[ip: (-9.66), ipnet: 66.111.4.0/24(-4.81), asn: 11403(-2.68), country: US(-0.05)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 22:19:51 -0000 --dc+cDN39EJAMEtIO Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 07, 2019 at 02:08:14PM -0700, Xin LI wrote: Hi, >I haven't dig deep on this topic, but it seems that parsing 'svn info' >output would solve it (by using "Last Changed Rev:" value). > >This issue do not exist on git. svn info will not return the revision of the running system. This is my point. With reproductible build turned on, there is no way as far as I'm aw= are of getting the revision of the sources the system was built from, and that bit of info can be very useful diagnosing/fixing and updating. It will return the revision of what the source directory was last updated t= o. That will probably be later than the running system. It won't return anything at all of course if the sources are no longer there. I'll try explaining another way. Let's say I'm relatively new to freebsd and I read up on downloading a 12-stable-snapshot and follow stable. Some issue with the base system happens. I email to stable@ and they ask what I'm running. I say, (because reproductible build defaults to "on" in this example) 12-stable. It's not really helpful to those wanting to assist. What benefit is had by losing this information by default? --=20 J. --dc+cDN39EJAMEtIO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAl1LTnYACgkQs8o7QhFz NAX3ShAArxcVlgVxAANkIPDAXyjK4AxkWq7vU248PbHo43mjX0hBNmShMeDcnPnI R6QQF0YnhFfMZlJJSlbqnyZa0fkphZWWNAb/dx15rY36DRtj6gMXDhLbHn4N3/9d xLAflcUclFwdFmrqgOQzB2B4FNOohhS+zwXJSANHkbCFQ3E7DXVItJ1LEtLzlN2O DeXHvnycKlg06otYRY0QQ5KT9IW9tgfYh37FIY53P7YzJOUmOxOq0Contl+UIys7 mvM3YY5y/6g7IKI5WjWBs/jwtGf/y/yiCVqmXSSjTWFrmOOYPWHbBel1TUJ1JF3d dFez91PLxjyQqEYSS9bi1w6LkzS1IV7ae5TRAWWXwV8RVmlE7RLN+GXlhc+jYsor 5rlbtT8uFvSMtDli/fgL92XacB5fXIfAYhjWN3Hmk9impxDkAJ0TKPNTJVhCrWZP MIh5E3YdW2/duMLvZyzpNc4dWTPNtjBQzi1zlXnKUZvfWXodrkF9Pb6Uoh1e1Z1O Ts5PquGNDPpm10S5oBPp0VEwNNvPSFH86tT34GaPQHkTwwpIt9ywYfi2RQKPzmtt GzASA23rxNCU8+E2VErPV/H4C23bDTLU+B3QVyJdnfpglkao2GjA8Ixj8RmRDftH /hVjburOhs1Ektxg223jwjP7wfMVtRyqiBseVczOtxW6NXQeYPo= =1w4s -----END PGP SIGNATURE----- --dc+cDN39EJAMEtIO-- From owner-freebsd-arch@freebsd.org Thu Aug 8 01:18:09 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6E27BBDC7D for ; Thu, 8 Aug 2019 01:18:09 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463r8w3twMz4Zmk for ; Thu, 8 Aug 2019 01:18:08 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-ot1-f44.google.com with SMTP id l15so112058699otn.9 for ; Wed, 07 Aug 2019 18:18:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uHJpg54EdL8MVSyZmy/U66ZJlSjS8zABbYlyhDNdi/M=; b=Q/2i4ddTYzYYvQaTEcgKJ9vpdj9lmB6/lo/AcVSVGHknVXBMwpe2tLLqRSpQYSE8/g lUQvjqkwxvjATPYK5LXhVInkM19YXTlB5EKiGZVL5N5aiwRFsr1oUuocdiEwpPthmO+w gjiEwV36fZO84sQyhWrq0oYRO5zos8rZiW3hvQrpAsQn28BwgwOG8vTy7WN8/5OpibN9 m2IuYatPUe4gSCJsLQDwnyLxijH2OWSJgQ0lgEoOD0JMW+xhLZP5MBSdIDf5p+yRIzb7 y8FD8ft88EtWzBCN2wKo03GpBl03Kmds6R5MC8abWbKoaW+KpLT6AvSCUF2zIUqoZM3T bR9w== X-Gm-Message-State: APjAAAUkFrCTnH4FJtco3S423AHyDkRHhXwV1YD+Jw+6eN5B6WVLflDa +AQbfZSYV5BIZjPoK/goYouVxbZDET5gNNILLR1leg== X-Google-Smtp-Source: APXvYqwpHaGXtV4fdD9L7rSon7T3kFtujH9cTNv7NJ755sKQgEkMAi9I1kH0/raJx29BnxRIb0qDb9cfFLxZgn8e8vM= X-Received: by 2002:a02:9004:: with SMTP id w4mr13642037jaf.111.1565227087195; Wed, 07 Aug 2019 18:18:07 -0700 (PDT) MIME-Version: 1.0 References: <20190807201448.GA42725@bastion.zyxst.net> <201908072050.x77Ko5QD089298@gndrsh.dnsmgr.net> <20190807221946.GB42725@bastion.zyxst.net> In-Reply-To: <20190807221946.GB42725@bastion.zyxst.net> From: Ed Maste Date: Wed, 7 Aug 2019 07:21:15 -0400 Message-ID: Subject: Re: svn commit: r350550 - head/share/mk To: tech-lists Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 463r8w3twMz4Zmk X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.210.44 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-4.26 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.995,0]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[44.210.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.27)[ip: (-0.47), ipnet: 209.85.128.0/17(-3.39), asn: 15169(-2.43), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 01:18:09 -0000 On Wed, 7 Aug 2019 at 18:19, tech-lists wrote: > > svn info will not return the revision of the running system. This is my > point. With reproductible build turned on, there is no way as far as I'm aware > of getting the revision of the sources the system was built from, and > that bit of info can be very useful diagnosing/fixing and updating. With REPRODUCIBLE_BUILD turned on the svn revision of the running system is available - in uname. rXXXXXX is included in uname with WITH_REPRODUCIBLE_BUILD or WITHOUT_REPRODUCIBLE_BUILD. From owner-freebsd-arch@freebsd.org Thu Aug 8 01:19:03 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AAD6FBDDD3 for ; Thu, 8 Aug 2019 01:19:03 +0000 (UTC) (envelope-from jhb@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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463r9z3ydxz4Zsk; Thu, 8 Aug 2019 01:19:03 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-4.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 0518519561; Thu, 8 Aug 2019 01:19:02 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: svn commit: r350550 - head/share/mk To: "Rodney W. Grimes" , tech-lists Cc: freebsd-arch@freebsd.org References: <201908072050.x77Ko5QD089298@gndrsh.dnsmgr.net> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <9c03a13c-8eed-06cb-bdef-faa1de8ea272@FreeBSD.org> Date: Wed, 7 Aug 2019 18:18:58 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <201908072050.x77Ko5QD089298@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 01:19:03 -0000 On 8/7/19 1:50 PM, Rodney W. Grimes wrote: >> Hello, >> >> On Tue, Aug 06, 2019 at 04:56:14PM +0000, Glen Barber wrote: >> >>> I would like to request this commit be reverted. While the original >>> commit message to enable this knob stated the commit would be reverted >>> after stable/12 branched, I have seen no public complaints about >>> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see >>> the benefit of disabling it by default -- why wouldn't we want >>> reproducibility?). >>> >>> To me, this feels like a step backwards, with no tangible benefit. >>> Note, newvers.sh does properly detect a modified tree if it can find >>> the VCS metadata directory (i.e., .git, .svn) -- I know this because >>> I personally helped with it. >>> >>> In my opinion, those that want the non-reproducible metadata included in >>> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their >>> src.conf. Turning off a sane default for the benefit of what I suspect >>> is likely a short list of use cases feels like a step in the wrong >>> direction. >> >> Well, my use case is that I have some machines that follow 12-stable. >> >> I'm not a developer. But I keep an eye on things like security bulletins >> etc and when they come out it usually gives something like 'affecting >> 12-STABLE prior to r something like that. And I can easily look >> at uname -a to see if this or that 12-stable machine needs to be patched >> or whatever. That is, if reproductible_build is turned off. (or >> without_reproductible_build is turned on) >> >> Or if I mail to stable@ asking for help I'll want to say *exactly* what >> sources I've built from. And sometimes someone will say "oh that was >> fixed after r" and so I'll grab sources after that revision >> if I can and fix the problem. >> >> But like I say I'm not a dev. I'd guess, though, that lots of non-devs >> use the revision info if they follow -stable, so if I'm right in thinking >> this, it'd be a short list of use cases but lots of affected people. >> >> unless there's another way to get the svn rev number? >> >> Why turn off this functionality by default? >> -- >> J. > > Actually you have a very good point here. > Let me raise the issue, the rXXXXXX is infact reproducible, why is > that being excluded from reproducible builds? If I build from the > same source at the same version I get the same rXXXXX string in > the resulting file. This is reproducible. > > So WHY are we excluding rXXXXXX from the reproducible build? We don't. The svn revision is present in uname -a even for reproducible builds. -- John Baldwin From owner-freebsd-arch@freebsd.org Thu Aug 8 01:21:51 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 70EEFBE15C for ; Thu, 8 Aug 2019 01:21:51 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463rFC2Qrtz4bBy; Thu, 8 Aug 2019 01:21:51 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-4.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id E391F1969E; Thu, 8 Aug 2019 01:21:50 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: svn commit: r350550 - head/share/mk To: tech-lists , freebsd-arch@freebsd.org References: <20190807201448.GA42725@bastion.zyxst.net> <201908072050.x77Ko5QD089298@gndrsh.dnsmgr.net> <20190807221946.GB42725@bastion.zyxst.net> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <47b92756-0289-cf04-85a8-fbb2216da87e@FreeBSD.org> Date: Wed, 7 Aug 2019 18:21:49 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <20190807221946.GB42725@bastion.zyxst.net> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 01:21:51 -0000 On 8/7/19 3:19 PM, tech-lists wrote: > On Wed, Aug 07, 2019 at 02:08:14PM -0700, Xin LI wrote: > > Hi, > >> I haven't dig deep on this topic, but it seems that parsing 'svn info' >> output would solve it (by using "Last Changed Rev:" value). >> >> This issue do not exist on git. > > svn info will not return the revision of the running system. This is my > point. With reproductible build turned on, there is no way as far as I'm aware > of getting the revision of the sources the system was built from, and > that bit of info can be very useful diagnosing/fixing and updating. > > It will return the revision of what the source directory was last updated to. > That will probably be later than the running system. It won't return > anything at all of course if the sources are no longer there. > > I'll try explaining another way. Let's say I'm relatively new to freebsd > and I read up on downloading a 12-stable-snapshot and follow stable. > Some issue with the base system happens. I email to stable@ and they ask > what I'm running. I say, (because reproductible build defaults to "on" in > this example) 12-stable. It's not really helpful to those wanting to > assist. What benefit is had by losing this information by default? That is not affected by the reproducible knob. Builds always include the output of svnversion. For example, my desktop machine on stable that has the default (reproducible on) has: % uname -a FreeBSD desktop 12.0-STABLE FreeBSD 12.0-STABLE r347074 GENERIC amd64 As long as you can do 'svn up -r' to get the same tree that uname -a claims, svnversion is doing its job, even if the last N commits are userland-only and don't impact the kernel. -- John Baldwin From owner-freebsd-arch@freebsd.org Thu Aug 8 01:50:04 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1FC73BF3EE for ; Thu, 8 Aug 2019 01:50:04 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 463rsk4ghlz4d81 for ; Thu, 8 Aug 2019 01:50:02 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 75A5F21E5B for ; Wed, 7 Aug 2019 21:50:01 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 07 Aug 2019 21:50:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=jT95do1jy13Mgccl4kkuy0gtUDl BKmC4ttvsLxQlYIA=; b=WzvcREDwXyTjuxuQd1L3wt8PKMyS6wKJxdZHSVh20OS xnw9prWjRu/c8ooNII3V6Rhz/GNgy0Udi93LkK63Rg/6kgruNHR8U7EoyDKMJ7jh bpFJu7c1Lww8Ewp977P0mJ/pYLFVgczki97JqypvhQ+CNQZAs54DO7kaoM4dK31A mb+6aP4AwmxqG7ZFVN6+LKFkQkq70pVizkJkw6r6a3vXKAVybV9g4P79efEQc0Io XAz19xkGxvyh3/tDzr76GbskQex0FxAoS3wYeTGakY5YfPDScoRe2K5EQpbLlhZO eFEaHU1r89xJN5ydfZL27aSF6tPOqh+egCURAqbaUUQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=jT95do 1jy13Mgccl4kkuy0gtUDlBKmC4ttvsLxQlYIA=; b=WpA0fJZNmLJh6Hm6rqIny5 gF4GrVJw0F+RTUyez8L/dsi0tq0FjJCupwZBL+ftw6s3aSh9nu+hf3pkvxoBrUCg yRTar10DRGeKh+robYemDucM7NH16k3TV1TQ61yGfUQQLX163HKqLEvQ9R1F6iYI kUBeiHtR4zpWOo7id6F0Q4O2HMANOWhfHXWiQPDExCqz0lTedu9hSFRxcbdnaLYV ahABf5nv57f4u3TiM6ulmwgP6ZBSPAVtB0HZLZx2uNPe7f6F5FuVcBG3b7EHvsjE umyuFemiaNof9fBLMmzSS/OOsBzO99GUuhMG4/4rLUI0pnxwnxyVE4xKT96htFRw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddugedgvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehgtd erredtredvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshes iiihgihsthdrnhgvtheqnecukfhppeekvddrjedtrdeluddrleelnecurfgrrhgrmhepmh grihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: from bastion.zyxst.net (unknown [82.70.91.99]) by mail.messagingengine.com (Postfix) with ESMTPA id 703E58005B for ; Wed, 7 Aug 2019 21:50:00 -0400 (EDT) Date: Thu, 8 Aug 2019 02:49:58 +0100 From: tech-lists To: freebsd-arch@freebsd.org Subject: Re: svn commit: r350550 - head/share/mk Message-ID: <20190808014958.GE42725@bastion.zyxst.net> References: <20190807201448.GA42725@bastion.zyxst.net> <201908072050.x77Ko5QD089298@gndrsh.dnsmgr.net> <20190807221946.GB42725@bastion.zyxst.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DqhR8hV3EnoxUkKN" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 463rsk4ghlz4d81 X-Spamd-Bar: --------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm3 header.b=WzvcREDw; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=WpA0fJZN; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.27 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-9.16 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm3,messagingengine.com:s=fm3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[zyxst.net]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; SIGNED_PGP(-2.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[27.4.111.66.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-3.47)[ip: (-9.79), ipnet: 66.111.4.0/24(-4.81), asn: 11403(-2.68), country: US(-0.05)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 01:50:04 -0000 --DqhR8hV3EnoxUkKN Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 07, 2019 at 07:21:15AM -0400, Ed Maste wrote: >On Wed, 7 Aug 2019 at 18:19, tech-lists wrote: >> >> svn info will not return the revision of the running system. This is my >> point. With reproductible build turned on, there is no way as far as I'm= aware >> of getting the revision of the sources the system was built from, and >> that bit of info can be very useful diagnosing/fixing and updating. > >With REPRODUCIBLE_BUILD turned on the svn revision of the running >system is available - in uname. rXXXXXX is included in uname with >WITH_REPRODUCIBLE_BUILD or WITHOUT_REPRODUCIBLE_BUILD. really? When the setting first became available, I found it wasn't the case, and that's why on all my stable systems I had to set WITHOUT_REPRODUCIBLE_BUILD=3DYES in /etc/src.conf in order to preserve prev= ious uname -a behaviour. This is the reason why I became aware of it and why I h= ad=20 an opinion about it. It was a while ago, though. if rXXXXXX is available in uname -a regardless now then it's all good.=20 --=20 J. --DqhR8hV3EnoxUkKN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIyBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAl1Lf60ACgkQs8o7QhFz NAW9jQ/0CC3by6QRZCpsgzYHp3XQ1/lVBhk/Q1za45bu5962KIX7ojSw+N7OZhp0 vwHwAU2ajpLILT9re/l+HMx+nHTkIpVP0OCVQhIpMKwrUp3XFodCJThq8+2huFno 3oV0XVNE10wRHUVnhbHZflu6477PD+6epyg4jG8WdV0Twc0TBDoAKTnY0gknjI2x Y+/L5TyFEUpkYJcmSe/HosyTMAEkA5O9YyoIsU64vkGYfL3beaWTuUl5TVQVDAl+ RX3Z5IQm36Amtw+n57WyHInSKGeeABlqbjw11MY4qthEohyGw61cRYetIBXZppGA jxGxYcoq1lz5GKHJE2Vwn7s+mUExNUv4xGwNP11yZcm1mck1GHW9ZFJrDml7RuHN ywTNrHkpTi96B2vA9Hr8CqPW1fzdVRtWexnc+KIYqiz09zNoFJol3ITkiiW6r5mH mrApf0IAw1GtAGjy02b+Mfa1WCv0o1DtUGMlcyajjiJk3eksmMtySOjRJIBK0XGK MnwDBQkWAf2RKaXo6iZYrLdvxGjZ2NN/1aehlzhb9Xt8Q+jSuyuDVJocH3+65Kmj EmURjGXTgbPVfV9flVx3uhlVz+Oh2NDrM5+l38nIdtahAKlEumlKU8/jymwYlIYl LFNBbXxYAju9CD/BHjUos+24twQ/M1YIcsbKO590Sa4iZoAlcA== =ZHbw -----END PGP SIGNATURE----- --DqhR8hV3EnoxUkKN-- From owner-freebsd-arch@freebsd.org Thu Aug 8 02:47:27 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 13D0BC149D for ; Thu, 8 Aug 2019 02:47:27 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 463t7y575Dz3FYF; Thu, 8 Aug 2019 02:47:26 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x782lLJW090501; Wed, 7 Aug 2019 19:47:21 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x782lL31090500; Wed, 7 Aug 2019 19:47:21 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201908080247.x782lL31090500@gndrsh.dnsmgr.net> Subject: Re: svn commit: r350550 - head/share/mk In-Reply-To: <9c03a13c-8eed-06cb-bdef-faa1de8ea272@FreeBSD.org> To: John Baldwin Date: Wed, 7 Aug 2019 19:47:21 -0700 (PDT) CC: "Rodney W. Grimes" , tech-lists , freebsd-arch@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 463t7y575Dz3FYF X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 02:47:27 -0000 > On 8/7/19 1:50 PM, Rodney W. Grimes wrote: > >> Hello, > >> > >> On Tue, Aug 06, 2019 at 04:56:14PM +0000, Glen Barber wrote: > >> > >>> I would like to request this commit be reverted. While the original > >>> commit message to enable this knob stated the commit would be reverted > >>> after stable/12 branched, I have seen no public complaints about > >>> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > >>> the benefit of disabling it by default -- why wouldn't we want > >>> reproducibility?). > >>> > >>> To me, this feels like a step backwards, with no tangible benefit. > >>> Note, newvers.sh does properly detect a modified tree if it can find > >>> the VCS metadata directory (i.e., .git, .svn) -- I know this because > >>> I personally helped with it. > >>> > >>> In my opinion, those that want the non-reproducible metadata included in > >>> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their > >>> src.conf. Turning off a sane default for the benefit of what I suspect > >>> is likely a short list of use cases feels like a step in the wrong > >>> direction. > >> > >> Well, my use case is that I have some machines that follow 12-stable. > >> > >> I'm not a developer. But I keep an eye on things like security bulletins > >> etc and when they come out it usually gives something like 'affecting > >> 12-STABLE prior to r something like that. And I can easily look > >> at uname -a to see if this or that 12-stable machine needs to be patched > >> or whatever. That is, if reproductible_build is turned off. (or > >> without_reproductible_build is turned on) > >> > >> Or if I mail to stable@ asking for help I'll want to say *exactly* what > >> sources I've built from. And sometimes someone will say "oh that was > >> fixed after r" and so I'll grab sources after that revision > >> if I can and fix the problem. > >> > >> But like I say I'm not a dev. I'd guess, though, that lots of non-devs > >> use the revision info if they follow -stable, so if I'm right in thinking > >> this, it'd be a short list of use cases but lots of affected people. > >> > >> unless there's another way to get the svn rev number? > >> > >> Why turn off this functionality by default? > >> -- > >> J. > > > > Actually you have a very good point here. > > Let me raise the issue, the rXXXXXX is infact reproducible, why is > > that being excluded from reproducible builds? If I build from the > > same source at the same version I get the same rXXXXX string in > > the resulting file. This is reproducible. > > > > So WHY are we excluding rXXXXXX from the reproducible build? > > We don't. The svn revision is present in uname -a even for reproducible > builds. I think I know what it is that IS removed, it is the path to the kernel build, and the host, that is what I am missing. That data is rather critical to me, as it is I believe your objection too. Again, I think if we split this into kernel/userland we can have it kernel off, userland on in head and I think that takes care of everyones complaint about wanting it turned off in head, and keeps the state that has those of us wanting it turned on in head. Am I correct in that your main reason for wanting to have this off in head is to get the kernel meta data for the path to the kernel John? If that is the one use case in head can we just turn it on for the kernel build only? > John Baldwin -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Thu Aug 8 03:02:47 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D0DBBC1A97 for ; Thu, 8 Aug 2019 03:02:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463tTf6jQBz3GSd for ; Thu, 8 Aug 2019 03:02:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x834.google.com with SMTP id x22so17256378qtp.12 for ; Wed, 07 Aug 2019 20:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KA6m24ZQye6qC8C2hA5hJASCEDDlYCAJrtZTX5hwTB0=; b=ezJPTwdlKA++UDboM/plaGm6LSrehUrDSAdmuUwywJa6/wfgedcETUkpWyQbVHBDJm Qr3NRlFUDC1n00pUvZFbfmxAMS0VH5ExM5SxqSariD9k3/tY6Ed+DdjRfpll5oOvOtwM ZlJCOFJD+9uGmaYnmXOhFoGGxP5765OaBOyuA1MiBbQR+n0LGDiNFdA7iirNdKM/fJAu g9gpPl3KBJAL/OsD4LGWLpFoQRgiRfNLtqodD2SYgQEI5YCsRL7iDayuNO5bCxcmEkHO nHSUfLjSwmz6EBN6kW5CzTE1p4gKvYO+oOFhJgZquiST5TRd7KKHyVhbwnC32vcjwiG3 lpHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KA6m24ZQye6qC8C2hA5hJASCEDDlYCAJrtZTX5hwTB0=; b=Ke9TLU3ZTaJJrreQcioEMqyawKVab/0ksjKqZ4bZKvAJyCpc3oMeAx0nsPTNAgwaOg nhASU+NuSGZn53ZwMJNVDwhGVxZiIcZQlgGi2vjgRbEbgvtVgKwSPyARvuawYcgGR2MH PJlsXgg8n8wCvqaqAvMH43TcLlg2sRhxnugG+XqHf5BoUnik3j5ZZEblfkoiQeGCvbtq mBOfa1YkAXsBjm2l32ImQOUwFJtgZThQrX63boAKTx8bl8SyE20yRGFCMXcMkyHnAovD ZxN2McERFDi5Qhe9RZNdu/yVh0/IgQh6w261TNEusbC3OVvpM+TgCZl7ylO3LmpbaNP4 ADKA== X-Gm-Message-State: APjAAAWHBwy6vMojlEsxrjIIAQtXdliOqES3TXd4YvGEeqDpRBWsKSp2 rnWPjuX+SZCQGK+i2deshCvQ9IHIZ/lGLwws69fCQAXyXiY= X-Google-Smtp-Source: APXvYqx47N127d5/jJwEfHIZfaCyt5oHKQTKwVK8c/pigI7faqj63PwySOsytKkoam7oR5y0vfEf9BYVyLiih6vcjKQ= X-Received: by 2002:ac8:244f:: with SMTP id d15mr10659552qtd.32.1565233365135; Wed, 07 Aug 2019 20:02:45 -0700 (PDT) MIME-Version: 1.0 References: <9c03a13c-8eed-06cb-bdef-faa1de8ea272@FreeBSD.org> <201908080247.x782lL31090500@gndrsh.dnsmgr.net> In-Reply-To: <201908080247.x782lL31090500@gndrsh.dnsmgr.net> From: Warner Losh Date: Wed, 7 Aug 2019 21:02:31 -0600 Message-ID: Subject: Re: svn commit: r350550 - head/share/mk To: "Rodney W. Grimes" Cc: John Baldwin , freebsd-arch@freebsd.org, tech-lists X-Rspamd-Queue-Id: 463tTf6jQBz3GSd X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=ezJPTwdl; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::834) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-5.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000,0]; RCVD_IN_DNSWL_NONE(0.00)[4.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.99)[ip: (-9.45), ipnet: 2607:f8b0::/32(-3.03), asn: 15169(-2.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 03:02:47 -0000 On Wed, Aug 7, 2019, 8:47 PM Rodney W. Grimes wrote: > > On 8/7/19 1:50 PM, Rodney W. Grimes wrote: > > >> Hello, > > >> > > >> On Tue, Aug 06, 2019 at 04:56:14PM +0000, Glen Barber wrote: > > >> > > >>> I would like to request this commit be reverted. While the original > > >>> commit message to enable this knob stated the commit would be > reverted > > >>> after stable/12 branched, I have seen no public complaints about > > >>> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not > see > > >>> the benefit of disabling it by default -- why wouldn't we want > > >>> reproducibility?). > > >>> > > >>> To me, this feels like a step backwards, with no tangible benefit. > > >>> Note, newvers.sh does properly detect a modified tree if it can find > > >>> the VCS metadata directory (i.e., .git, .svn) -- I know this because > > >>> I personally helped with it. > > >>> > > >>> In my opinion, those that want the non-reproducible metadata > included in > > >>> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in > their > > >>> src.conf. Turning off a sane default for the benefit of what I > suspect > > >>> is likely a short list of use cases feels like a step in the wrong > > >>> direction. > > >> > > >> Well, my use case is that I have some machines that follow 12-stable. > > >> > > >> I'm not a developer. But I keep an eye on things like security > bulletins > > >> etc and when they come out it usually gives something like 'affecting > > >> 12-STABLE prior to r something like that. And I can easily > look > > >> at uname -a to see if this or that 12-stable machine needs to be > patched > > >> or whatever. That is, if reproductible_build is turned off. (or > > >> without_reproductible_build is turned on) > > >> > > >> Or if I mail to stable@ asking for help I'll want to say *exactly* > what > > >> sources I've built from. And sometimes someone will say "oh that was > > >> fixed after r" and so I'll grab sources after that > revision > > >> if I can and fix the problem. > > >> > > >> But like I say I'm not a dev. I'd guess, though, that lots of > non-devs > > >> use the revision info if they follow -stable, so if I'm right in > thinking > > >> this, it'd be a short list of use cases but lots of affected people. > > >> > > >> unless there's another way to get the svn rev number? > > >> > > >> Why turn off this functionality by default? > > >> -- > > >> J. > > > > > > Actually you have a very good point here. > > > Let me raise the issue, the rXXXXXX is infact reproducible, why is > > > that being excluded from reproducible builds? If I build from the > > > same source at the same version I get the same rXXXXX string in > > > the resulting file. This is reproducible. > > > > > > So WHY are we excluding rXXXXXX from the reproducible build? > > > > We don't. The svn revision is present in uname -a even for reproducible > > builds. > > I think I know what it is that IS removed, it is the path to > the kernel build, and the host, that is what I am missing. > That data is rather critical to me, as it is I believe your > objection too. > > Again, I think if we split this into kernel/userland we can > have it kernel off, userland on in head and I think that > takes care of everyones complaint about wanting it turned off > in head, and keeps the state that has those of us wanting it > turned on in head. > > Am I correct in that your main reason for wanting to have this > off in head is to get the kernel meta data for the path to the > kernel John? If that is the one use case in head can we just > turn it on for the kernel build only? > I think that's too much complication for too little benefit. It's a development system, so there is little benefit to making things reproduction... almost none. If we want to build packages for current, those few machines can make it reproducible. It's no different than WITNESS or malloch checking... Warner > John Baldwin > -- > Rod Grimes > rgrimes@freebsd.org > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Thu Aug 8 18:31:39 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5DB53AE4D1 for ; Thu, 8 Aug 2019 18:31:39 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com [209.85.210.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 464H5Q3qrWz4gp2 for ; Thu, 8 Aug 2019 18:31:38 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-ot1-f46.google.com with SMTP id x21so29250818otq.12 for ; Thu, 08 Aug 2019 11:31:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9DIBsaGfdmYXnfoRXgS3YuBAHEmd1bCiybcvc2XhbaI=; b=ZzB10ZDxZ+XFPCv/qyansCWa/z/86mk3OchMOx/FU9W0RQb2pN3Ku1LlIgG//ixwmx bwBQXkkDJeM3gAfyFkuzoUwO9gMj+H/6av96iDTUlVESHgMJbd0d/aEqVNS2u9SC5zKf 7Xh9FSSkYg3NrC2hELZSgPUAfA6i/cv9xrIxMEixQBxj7X0IP4ZqNP1deIX/I1vOGZ2S CLytQERiWjhWyQ9czLMySC3z9pfDkP3t5UrXjqQdQb4uSJGh6MIj6rQ9VvAfI+4u7LiV 7O2JT4gZF3NdccjQTUORmiMNGUAY9sgxWMNLxkyct0+wuLNkQrQ8x8C7KQN6JPtvN3Li /nqQ== X-Gm-Message-State: APjAAAVT4MnRykfTQXdXKI4zFyg1PXCQCT2y4Ad99MCb8SYdMrygUmWo GCtSpGKKhbDXwKnmKpzAAV1FW8Ypq4BNf55vcJ020c1x X-Google-Smtp-Source: APXvYqyaL1slFN9Bw4xjjdrNIKZ7cX5kMvByj4HCR0ZeRlD9EvyRdILxhaUYo5REN+GEil0TPmr/+6RucZIZSfE+U20= X-Received: by 2002:a6b:8ed7:: with SMTP id q206mr9329743iod.120.1565289097159; Thu, 08 Aug 2019 11:31:37 -0700 (PDT) MIME-Version: 1.0 References: <20190807201448.GA42725@bastion.zyxst.net> <201908072050.x77Ko5QD089298@gndrsh.dnsmgr.net> <20190807221946.GB42725@bastion.zyxst.net> <20190808014958.GE42725@bastion.zyxst.net> In-Reply-To: <20190808014958.GE42725@bastion.zyxst.net> From: Ed Maste Date: Thu, 8 Aug 2019 00:34:45 -0400 Message-ID: Subject: Re: svn commit: r350550 - head/share/mk To: tech-lists Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 464H5Q3qrWz4gp2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.210.46 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-4.27 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.994,0]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[46.210.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.27)[ip: (-0.49), ipnet: 209.85.128.0/17(-3.39), asn: 15169(-2.43), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 18:31:39 -0000 On Wed, 7 Aug 2019 at 21:50, tech-lists wrote: > > really? When the setting first became available, I found it wasn't the case, > and that's why on all my stable systems I had to set > WITHOUT_REPRODUCIBLE_BUILD=YES in /etc/src.conf in order to preserve previous > uname -a behaviour. WITH_REPRODUCIBLE_BUILD has never affected the method used to determine the SVN version or whether it was included - the same SVN version has always been in uname -a regardless of the REPRODUCIBLE_BUILD knob. The REPRODUCIBLE_BUILD knob affects exactly two invocations in the build process. When set -r or -R is passed tosys/conf/newvers.sh and stand/common/newvers.sh. This controls timestamp, user, and host in the loader, and the build count, time, date, user, host, and build directory in the kernel (as reported by uname). From owner-freebsd-arch@freebsd.org Thu Aug 8 18:32:55 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 592E2AE6AE for ; Thu, 8 Aug 2019 18:32:55 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 464H6t3p9vz4h3G; Thu, 8 Aug 2019 18:32:54 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-ot1-f44.google.com with SMTP id b7so72315369otl.11; Thu, 08 Aug 2019 11:32:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xyjAxLXISNKb2XcMC+CRR+rSv5IaEyP+JVLHOFL5XB0=; b=oygR7CHo2Rk396FoP4yrIN3kbXJDHuhQxvnVZWnqFeDcQv+SuWK59Sd2XeFbkO2uJJ fCoHVZpRWlG9WS4vLEXJ8AhIo7Xyk+jSSD1A5zIq4svGrcGnma7pcSt6gNav5oUJJiRw wohh6lUNgGk5Ox0/3ch7FX3qppUXCAVc8G0eEj1HtMz63StS0FZdELvcYJsqP91hj0ww +MDP+ZPOkw4bk99xbCZ7BltEQ+zsUpXGqQtxm6/vnT1GMXJ6i9lyNGwg67tbEhERLqRE HR4Xy1JE4FjeNzInlclqhBSSM7KO5BGn0rYOhDrzMdFU8fiHNje4BR6mo4j9JSKYmZRh D08A== X-Gm-Message-State: APjAAAWvfJvtGDEPd658oo2F0AhxQPJp0Ek+wUq3JXRD/b4MZrCyPYk8 VrjOPWhkIulhYw8wOn+PyiFRuI6kV1DMIfyb/sxlhQ== X-Google-Smtp-Source: APXvYqyuaGqAZHdxzCzXdZiAKyY/104z5XiZKkVlgDjOlnVx0CaYSB10vj89ESx0q9IkEa/lpbQHz6hcR4Oz6JIgER4= X-Received: by 2002:a6b:7e07:: with SMTP id i7mr7114385iom.254.1565289173328; Thu, 08 Aug 2019 11:32:53 -0700 (PDT) MIME-Version: 1.0 References: <9c03a13c-8eed-06cb-bdef-faa1de8ea272@FreeBSD.org> <201908080247.x782lL31090500@gndrsh.dnsmgr.net> In-Reply-To: <201908080247.x782lL31090500@gndrsh.dnsmgr.net> From: Ed Maste Date: Thu, 8 Aug 2019 00:36:03 -0400 Message-ID: Subject: Re: svn commit: r350550 - head/share/mk To: "Rodney W. Grimes" Cc: John Baldwin , "freebsd-arch@freebsd.org" , tech-lists Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 464H6t3p9vz4h3G X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.210.44 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-4.25 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; RCVD_IN_DNSWL_NONE(0.00)[44.210.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.26)[ip: (-0.46), ipnet: 209.85.128.0/17(-3.38), asn: 15169(-2.43), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 18:32:55 -0000 On Wed, 7 Aug 2019 at 22:47, Rodney W. Grimes wrote: > > Again, I think if we split this into kernel/userland we can > have it kernel off, userland on in head and I think that > takes care of everyones complaint about wanting it turned off > in head, and keeps the state that has those of us wanting it > turned on in head. There's not really anything to split - the knob affects the kernel and loader build, nothing else in userland. From owner-freebsd-arch@freebsd.org Thu Aug 8 20:17:29 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 31C42B1901 for ; Thu, 8 Aug 2019 20:17:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-9.consmr.mail.ne1.yahoo.com (sonic313-9.consmr.mail.ne1.yahoo.com [66.163.185.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 464KRW0FB7z4pRq for ; Thu, 8 Aug 2019 20:17:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: AVLOrmAVM1nAWUal3l.eFWA3qcw6p7GQq1x7bh9dHo1Rarm3crMoEXGt3XSG52b 61nWy8MU_sVC52YsPCv.VzEMXeFrUvvl1PdnR.xhRrdubRbb7cWmEk5_.liIDg60IR_F_xu0ysgl DnAYGw3ZR2ArofI7tQxfR7AQi1JLAHViasBTAcjGT46TimfcQUnV33WljteFWQDydqaMuuObclwB v357yx.8gYqHTdZENnF8BY.kW0kFIyD2mwGYIDAtl6H_kOTIg2jfyYZD7D2nQQomQSG9DKYIDl04 UnW1hdpx6A0osZNSTkvdCMMGQiegboJk09alI63Qe6.glQZqYLXNLvOGtkQIhkVF4J7H5NsudrLi R7RTIP6QrOGSWLUbKOC4QFb_Jti.zafPJ6vm3Puv5Yc56ElK0UmLlSqdywH6twrEdviKdTNdA4CJ .sXP3wb56gnpm6sz3.BZiHjQk83tDDCLGBk6n_Rm_EcRHrAxk8ratxxCj9bkB5eVe2INjAVx8GGU Y6fldci.Yi2zaogxEjbGTMSCJAtA_PLxgD7XsmjKM_LpUEy5zAw6rrlqymvp26u_OMKnW4WwS3OJ DR.kPO7a8gU0E.dGfMm8TrajErM5D8_vWeLPZ_zmJhgU_RD98Whxq4nfXATHHEDNpmh.sU6evt1V 3U0xbNe_jGRLC3m1b3t5qFWdqfAF9cyJuNldMAN.zlyaZZ__Ml98YTzLc_GTZ4NXyAHofX.3mCnf fHKcwqFM6UF4HJvuZjHaYFQqu8UdwT8Ne_ADNQc2nVKv.pXd4naW3P40PZTp5_Nu1ZXMCHsoCfgs hjaUe_xyoZBnRIslYnozD6v4T1ULPNuTHCtPbmbdiQN1KU__9154F2iEksm_sWx3ro3bp.fp7uqO Iv.XJ5hQAzRzu7V2o5xByJL8WLkkb4BjOQlATAVBXmyJ1ztQxegA.Dx4XYvjpYrWVgk6GP0xG3Ma HzPZqbDQACTWD19nUlj_vYVcgjo0GftMGl_Uu.MTXGI5WOPW0p_KXpQ7mTUg5nOqJWgD8xZp6AYU 5R2Wv8RKIfuCFkVrduqwE6_YuCpyNK4iWVGGzgqkpnRxM7O9ZX2cxtS6_fVYLoXwY6r2VkhRPvh3 ND7DSXZ30YqHNh0eFG1FWAutkeGjoLBc8ytO1G4rw.uYz6iKLEcwZ6vZtr1YhB1owuxEFVyRrE4V E3YVyOsU.HLuVvw4PGCAmvsdmA.ww4g_poOVwBr2IX1sJmjHjtyrFc4DrJnYUst7rfFqOw_FLsgR a1Vfi09E- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Thu, 8 Aug 2019 20:17:25 +0000 Received: by smtp417.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a23f480845d83a5bc481ce7f05f95e4e; Thu, 08 Aug 2019 20:17:21 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: svn commit: r350550 - head/share/mk Message-Id: <53987F8A-25FC-44D0-ACE0-680ECBFFEF48@yahoo.com> Date: Thu, 8 Aug 2019 13:17:19 -0700 To: freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 464KRW0FB7z4pRq X-Spamd-Bar: + X-Spamd-Result: default: False [1.47 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_NONE(0.00)[]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; FAKE_REPLY(1.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.26)[-0.261,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.98)[0.978,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (1.57), ipnet: 66.163.184.0/21(1.27), asn: 36646(1.02), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(0.26)[0.258,0]; RCVD_IN_DNSWL_NONE(0.00)[32.185.163.66.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 20:17:29 -0000 Something has seemed incomplete in the descriptions that I've seen in the posts (based on a vague memory and observed behavior in my context). So I looked: # grep -r -U3 REPRO_FLAG /usr/src/sys/ /usr/src/stand/ | less /usr/src/sys/conf/kern.post.mk- ${NORMAL_CTFCONVERT} /usr/src/sys/conf/kern.post.mk- /usr/src/sys/conf/kern.post.mk-.if ${MK_REPRODUCIBLE_BUILD} !=3D "no" /usr/src/sys/conf/kern.post.mk:REPRO_FLAG=3D"-R" /usr/src/sys/conf/kern.post.mk-.endif /usr/src/sys/conf/kern.post.mk-vers.c: $S/conf/newvers.sh $S/sys/param.h = ${SYSTEM_DEP} /usr/src/sys/conf/kern.post.mk: MAKE=3D"${MAKE}" sh $S/conf/newvers.sh = ${REPRO_FLAG} ${KERN_IDENT} /usr/src/sys/conf/kern.post.mk- /usr/src/sys/conf/kern.post.mk-vnode_if.c: $S/tools/vnode_if.awk = $S/kern/vnode_if.src /usr/src/sys/conf/kern.post.mk- ${AWK} -f $S/tools/vnode_if.awk = $S/kern/vnode_if.src -c -- /usr/src/stand/loader.mk-CLEANFILES+=3D vers.c /usr/src/stand/loader.mk-VERSION_FILE?=3D ${.CURDIR}/version /usr/src/stand/loader.mk-.if ${MK_REPRODUCIBLE_BUILD} !=3D no /usr/src/stand/loader.mk:REPRO_FLAG=3D -r /usr/src/stand/loader.mk-.endif /usr/src/stand/loader.mk-vers.c: ${LDRSRC}/newvers.sh ${VERSION_FILE} /usr/src/stand/loader.mk: sh ${LDRSRC}/newvers.sh ${REPRO_FLAG} = ${VERSION_FILE} \ /usr/src/stand/loader.mk- ${NEWVERSWHAT} /usr/src/stand/loader.mk- /usr/src/stand/loader.mk-.if ${MK_LOADER_VERBOSE} !=3D "no" Then the question is the -r vs. -R distinction (for just /usr/src/sys/conf/newvers.sh as it turns out, /usr/src/stand/loader.mk only supports -r use): . . . # -r Reproducible build. Do not embed directory names, user = names, # time stamps or other dynamic information into the output = file. # This is intended to allow two builds done at different = times # and even by different people on different hosts to = produce # identical output. # # -R Reproducible build if the tree represents an unmodified # checkout from a version control system. Metadata is = included # if the tree is modified. . . . include_metadata=3Dyes modified=3Dno while getopts crRvV: opt; do case "$opt" in c) echo "$COPYRIGHT" exit 0 ;; r) include_metadata=3Dno ;; R) include_metadata=3Dif-modified ;; . . . As stands -r is never used for sys/conf/newvers.sh unless one changes /usr/src/sys/conf/kern.post.mk or some such. So if I use WITH_REPRODUCEABLE_BUILD I still see the varying metadata (but I do not have an independent svn with my own checkins, just differences with FreeBSD svnlite update -r?????? materials). May be what some folks are asking for is some means of control over -R vs. -r being supplied to sys/conf/newvers.sh , without having to edit sys/conf/kern.post.mk ? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arch@freebsd.org Thu Aug 8 23:51:47 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D65F6B7117 for ; Thu, 8 Aug 2019 23:51:47 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 464QBq4XF4z3L5K; Thu, 8 Aug 2019 23:51:47 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x78NphLg094818; Thu, 8 Aug 2019 16:51:43 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x78NpgBR094817; Thu, 8 Aug 2019 16:51:42 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201908082351.x78NpgBR094817@gndrsh.dnsmgr.net> Subject: Re: svn commit: r350550 - head/share/mk In-Reply-To: To: Ed Maste Date: Thu, 8 Aug 2019 16:51:42 -0700 (PDT) CC: tech-lists , "freebsd-arch@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 464QBq4XF4z3L5K X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.958,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 23:51:47 -0000 > On Wed, 7 Aug 2019 at 21:50, tech-lists wrote: > > > > really? When the setting first became available, I found it wasn't the case, > > and that's why on all my stable systems I had to set > > WITHOUT_REPRODUCIBLE_BUILD=YES in /etc/src.conf in order to preserve previous > > uname -a behaviour. > > WITH_REPRODUCIBLE_BUILD has never affected the method used to > determine the SVN version or whether it was included - the same SVN > version has always been in uname -a regardless of the > REPRODUCIBLE_BUILD knob. > > The REPRODUCIBLE_BUILD knob affects exactly two invocations in the > build process. When set -r or -R is passed tosys/conf/newvers.sh and > stand/common/newvers.sh. This controls timestamp, user, and host in > the loader, and the build count, time, date, user, host, and build > directory in the kernel (as reported by uname). Thank you for the clarification on this, if that infact is the only effect this knob has on all of the build artifacts I am completly fine with it set either way and shall continue to force it off on all my kernel build VM's so that I do have my critical host and path information when I need it. I formally retract my proposal. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Fri Aug 9 03:35:15 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CCD14BB021; Fri, 9 Aug 2019 03:35:15 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 464W8f2hssz40Jv; Fri, 9 Aug 2019 03:35:14 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id x793Z6as074460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2019 04:35:07 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id x793Z5WP074456; Fri, 9 Aug 2019 04:35:05 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201908090335.x793Z5WP074456@donotpassgo.dyslexicfish.net> Date: Fri, 09 Aug 2019 04:35:05 +0100 Organization: Dyslexic Fish To: jhb@freebsd.org, gjb@freebsd.org Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: svn commit: r350550 - head/share/mk References: <201908030106.x7316Ibx078529@repo.freebsd.org> <20190806165614.GA41295@FreeBSD.org> In-Reply-To: <20190806165614.GA41295@FreeBSD.org> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Fri, 09 Aug 2019 04:35:07 +0100 (BST) X-Rspamd-Queue-Id: 464W8f2hssz40Jv X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-3.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; HAS_ORG_HEADER(0.00)[]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_SHORT(-0.71)[-0.710,0]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; RCPT_COUNT_SEVEN(0.00)[7]; IP_SCORE(-0.40)[ipnet: 2001:19f0::/38(-1.74), asn: 20473(-0.18), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 03:35:15 -0000 Glen Barber wrote: > after stable/12 branched, I have seen no public complaints about > enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > the benefit of disabling it by default -- why wouldn't we want > reproducibility?). I track stable. I had no need to complain because I could edit src.conf and add WITHOUT_REPRODUCIBLE_BUILD=YES Please don't remove this ability thinking no-one minds reproducible builds.. I personally think they are pointless. Cheers, Jamie From owner-freebsd-arch@freebsd.org Fri Aug 9 13:32:29 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 25733C96CB for ; Fri, 9 Aug 2019 13:32:29 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 464mPm23m8z4ZVY for ; Fri, 9 Aug 2019 13:32:27 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id w50Jh9M6osAGkw50KhsGe3; Fri, 09 Aug 2019 07:32:25 -0600 X-Authority-Analysis: v=2.3 cv=WeVylHpX c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=FmdZ9Uzk2mMA:10 a=vxP3BzG0AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=HfSEoNKeE166lXEH_6IA:9 a=QEXdDO2ut3YA:10 a=4tHceQipB5Rc01mo_vQZ:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [192.168.1.103] (S0106002401cb186f.gv.shawcable.net [70.67.125.17]) by spqr.komquats.com (Postfix) with ESMTPSA id 5E36145D; Fri, 9 Aug 2019 06:32:22 -0700 (PDT) Date: Fri, 09 Aug 2019 06:32:20 -0700 In-Reply-To: <20190807221946.GB42725@bastion.zyxst.net> References: <20190807201448.GA42725@bastion.zyxst.net> <201908072050.x77Ko5QD089298@gndrsh.dnsmgr.net> <20190807221946.GB42725@bastion.zyxst.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: svn commit: r350550 - head/share/mk To: freebsd-arch@freebsd.org,tech-lists From: Cy Schubert Message-ID: X-CMAE-Envelope: MS4wfDH5Wqx+Et7IzCDwLjJ56ALqzJBWCqHaWHIJyvmF1VgkwS/6g0h2+shh3BFpC+qjrSfrbb4ax59q7LNOzOPM8t0htj64f0CO9ckhLyqtS4WkQmWHTdgq sWbX6fqyWWsxrPgNwmfSmuG1ju+1GG/ViRGEP8/VJ5e4+Ffiya+HBGjCEh03wLpbOIYe5JwMROaZF1Sau20V/QLzz7buuKd4H0SJIus554MTk6a1yzMRvV7y X-Rspamd-Queue-Id: 464mPm23m8z4ZVY X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.9) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-5.53 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.994,0]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[9.134.59.64.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.44)[ip: (-6.48), ipnet: 64.59.128.0/20(-3.17), asn: 6327(-2.47), country: CA(-0.09)]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 13:32:29 -0000 On August 7, 2019 3:19:46 PM PDT, tech-lists wrote= : >On Wed, Aug 07, 2019 at 02:08:14PM -0700, Xin LI wrote: > >Hi, > >>I haven't dig deep on this topic, but it seems that parsing 'svn info' >>output would solve it (by using "Last Changed Rev:" value)=2E >> >>This issue do not exist on git=2E > >svn info will not return the revision of the running system=2E This is my >point=2E With reproductible build turned on, there is no way as far as >I'm aware >of getting the revision of the sources the system was built from, and >that bit of info can be very useful diagnosing/fixing and updating=2E > >It will return the revision of what the source directory was last >updated to=2E >That will probably be later than the running system=2E It won't return >anything at all of course if the sources are no longer there=2E > >I'll try explaining another way=2E Let's say I'm relatively new to >freebsd >and I read up on downloading a 12-stable-snapshot and follow stable=2E >Some issue with the base system happens=2E I email to stable@ and they >ask >what I'm running=2E I say, (because reproductible build defaults to "on" >in >this example) 12-stable=2E It's not really helpful to those wanting to >assist=2E What benefit is had by losing this information by default? This change doesn't affect and never will affect users of stable=2E This i= s a -current (13-current to be exact) change only=2E --=20 Pardon the typos and autocorrect, small keyboard in use=2E Cheers, Cy Schubert FreeBSD UNIX: Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E From owner-freebsd-arch@freebsd.org Fri Aug 9 16:56:08 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EDBCBCD10E for ; Fri, 9 Aug 2019 16:56:08 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 464rwm1CZQz3Hn5 for ; Fri, 9 Aug 2019 16:56:07 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x79Gu4FU098296; Fri, 9 Aug 2019 09:56:04 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x79Gu4du098295; Fri, 9 Aug 2019 09:56:04 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201908091656.x79Gu4du098295@gndrsh.dnsmgr.net> Subject: Re: svn commit: r350550 - head/share/mk In-Reply-To: To: Cy Schubert Date: Fri, 9 Aug 2019 09:56:04 -0700 (PDT) CC: freebsd-arch@freebsd.org, tech-lists X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 464rwm1CZQz3Hn5 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [2.00 / 15.00]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.78)[0.776,0]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.20)[0.196,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.08)[0.082,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.05)[ip: (0.15), ipnet: 69.59.192.0/19(0.08), asn: 13868(0.05), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 16:56:09 -0000 > On August 7, 2019 3:19:46 PM PDT, tech-lists wrote: > >On Wed, Aug 07, 2019 at 02:08:14PM -0700, Xin LI wrote: > > > >Hi, > > > >>I haven't dig deep on this topic, but it seems that parsing 'svn info' > >>output would solve it (by using "Last Changed Rev:" value). > >> > >>This issue do not exist on git. > > > >svn info will not return the revision of the running system. This is my > >point. With reproductible build turned on, there is no way as far as > >I'm aware > >of getting the revision of the sources the system was built from, and > >that bit of info can be very useful diagnosing/fixing and updating. > > > >It will return the revision of what the source directory was last > >updated to. > >That will probably be later than the running system. It won't return > >anything at all of course if the sources are no longer there. > > > >I'll try explaining another way. Let's say I'm relatively new to > >freebsd > >and I read up on downloading a 12-stable-snapshot and follow stable. > >Some issue with the base system happens. I email to stable@ and they > >ask > >what I'm running. I say, (because reproductible build defaults to "on" > >in > >this example) 12-stable. It's not really helpful to those wanting to > >assist. What benefit is had by losing this information by default? > > This change doesn't affect and never will affect users of stable. This is a -current (13-current to be exact) change only. It effects one group of users, release engineering, who now have added an action item to post stable branch operation to turn this flag back to WITH_REPRODUCABLE_BUILDS. -- Rod Grimes rgrimes@freebsd.org