From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from 6.mo576.mail-out.ovh.net (6.mo576.mail-out.ovh.net [46.105.50.107]) by sourceware.org (Postfix) with ESMTPS id 048B83858D1E for ; Wed, 20 Dec 2023 17:40:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 048B83858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sk2.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sk2.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 048B83858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=46.105.50.107 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703094037; cv=none; b=jhWoOcgc2lPx3CrWzbvesXa1kL+19Jr08n4CX9tpUq99143qI9t3SNf04BxZBWFWewZ16r4VTaNvpDMdyVywsUd5SPGIwq/m/TgZWAVok3NG1XppwDK+9jHJXgrCJmvsgq2OzXfEAG14Kotri6AOZW9ec20kTde1xHXDM+uVNKk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703094037; c=relaxed/simple; bh=cWfcCeFj3yuvPIdCchdLAmBoMcL7PWHW4lftleb56kc=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=psAAIEHf1jljPecdbtQrAHAdTqNAORoMAmp0hcVFgLWADhGMxGGHSmE4hZvZKrjik1JdA89Ft2PvqaBCiAH5i+4Q0yHLTW+QUIVsOhSNgAAa5m5JOqeMpJrsV0uBsahrgfiiI7qjPsk/Qs0L21yEygrNXL5ntH9QUGkhsddFpdM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from director9.ghost.mail-out.ovh.net (unknown [10.108.25.12]) by mo576.mail-out.ovh.net (Postfix) with ESMTP id 9276F304D5 for ; Wed, 20 Dec 2023 17:40:34 +0000 (UTC) Received: from ghost-submission-6684bf9d7b-6bgkt (unknown [10.110.96.50]) by director9.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 7CCA61FD10; Wed, 20 Dec 2023 17:40:33 +0000 (UTC) Received: from sk2.org ([37.59.142.109]) by ghost-submission-6684bf9d7b-6bgkt with ESMTPSA id O/tXGhEng2XSFAsA4C6f1Q (envelope-from ); Wed, 20 Dec 2023 17:40:33 +0000 Authentication-Results:garm.ovh; auth=pass (GARM-109S0039b7ed650-00af-4ac3-a8f4-00840c32d125, 84CD74454C20E69FCD15F5690931621FDA03B438) smtp.auth=steve@sk2.org X-OVh-ClientIp:82.65.25.201 Date: Wed, 20 Dec 2023 18:40:25 +0100 From: Stephen Kitt To: Jan Beulich Cc: binutils@sourceware.org Subject: Re: [PATCH v2] tests: force non-deterministic mode in non-deterministic tests Message-ID: <20231220184025.61f0e8fd@heffalump.sk2.org> In-Reply-To: <23880051-342a-414a-8af7-c54916f76c00@suse.com> References: <20231219215307.2578951-1-steve@sk2.org> <23880051-342a-414a-8af7-c54916f76c00@suse.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.24; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/T0YDCu0D/11=QXxXvJEG/8f"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Ovh-Tracer-Id: 2815312720188376710 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvkedrvdduvddguddtfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfgjfhfogggtsehgtderreertdejnecuhfhrohhmpefuthgvphhhvghnucfmihhtthcuoehsthgvvhgvsehskhdvrdhorhhgqeenucggtffrrghtthgvrhhnpeetgeevhfegvdfhvdevfeejkeelfeeffeehueethedthffhudfhheduvedvudetteenucffohhmrghinhepuggvsghirghnrdhorhhgnecukfhppeduvdejrddtrddtrddupdekvddrieehrddvhedrvddtuddpfeejrdehledrudegvddruddtleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepoehsthgvvhgvsehskhdvrdhorhhgqedpnhgspghrtghpthhtohepuddprhgtphhtthhopegsihhnuhhtihhlshesshhouhhrtggvfigrrhgvrdhorhhgpdfovfetjfhoshhtpehmohehjeeipdhmohguvgepshhmthhpohhuth X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --Sig_/T0YDCu0D/11=QXxXvJEG/8f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 20 Dec 2023 09:03:37 +0100, Jan Beulich wrote: > On 19.12.2023 22:53, Stephen Kitt wrote: > > Since ar can be built defaulting to deterministic mode, tests which > > expect non-deterministic behaviour need to explicitly set the U flag. > > They also need to run without SOURCE_DATE_EPOCH since that also > > enables deterministic mode. =20 >=20 > Not quite - the env var controls only time stamps, not UID/GID or > permissions, aiui. That's merely a matter of changing the wording of > course. Right, I=E2=80=99ll update the wording. > > --- a/binutils/testsuite/binutils-all/ar.exp > > +++ b/binutils/testsuite/binutils-all/ar.exp > > @@ -571,6 +571,8 @@ proc replacing_non_deterministic_member { } { > > return > > } > > =20 > > + unsetenv SOURCE_DATE_EPOCH > > + > > set archive tmpdir/artest.a > > set older_objfile tmpdir/bintest.${obj} > > set newer_objfile tmpdir/ar/bintest.${obj} =20 >=20 > I think it would be nice if this was done in the place where, > respectively, replacing_sde_deterministic_member has its setenv > (and then, like that, if it also had a brief comment). Unless of > course there's an issue with moving this down by a few lines. Yes, that makes sense. > Furthermore I'm afraid I'm less comfortable approving this, as the > correctness of the unconditional unsetenv in > replacing_sde_deterministic_member isn't really clear to me: If that > variable was indeed set in the environment up front, it's not clear > to me whether it really is okay to permanently alter the environment. > Otoh of course your change merely moves the (possible) problem ahead > by a tiny bit, so yes - with the cosmetic adjustments done the change > is probably still okay. The scenario I=E2=80=99m trying to address is indeed when SOURCE_DATE_EPOCH= is set in the environment on entry to the tests. This is what happens for example in Debian builds, and that=E2=80=99s where I ran into this. https://buildd.debian.org/status/fetch.php?pkg=3Dbinutils-mingw-w64&arch=3D= amd64&ver=3D11.1&stamp=3D1702977480&raw=3D0 provides an example. I think it=E2=80=99s fine for tests to make sure their environment is appro= priate for their own tests, but I agree it would be better for them to restore the environment as it was on entry. The Linaro build bot is complaining about this too; it=E2=80=99s failing be= cause unsetenv is called on a variable which isn=E2=80=99t present in the environ= ment. It seems I should check for the variable=E2=80=99s presence before unsetting i= t, or perhaps just set it to empty... Incidentally, builds with this patch in Debian all pass these tests (with SOURCE_DATE_EPOCH set in the environment), but fail on i386 tests on big-endian systems; see https://buildd.debian.org/status/package.php?p=3Dbinutils-mingw-w64 for log= s. git bisect tells me that the culprit is 734dfd1cc966aff736eaeda68bfa4807ee4b50c1 but I haven=E2=80=99t figured out = why yet. Regards, Stephen --Sig_/T0YDCu0D/11=QXxXvJEG/8f Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEnPVX/hPLkMoq7x0ggNMC9Yhtg5wFAmWDJwkACgkQgNMC9Yht g5wigA/6A/Pm6lqO8E9U1s5rJSR0ovUgBEXjZf/6lXraJRZb4U67jKOTtUMNIXZ2 jzNYzmNg41KXObQneWUBW6bBpCG7cv66B5T8AT3pOmXFWonxsg+xmOx3GyP+bVnv ajV2G3iHs2qM6aHJbA3LocXxMqeTrhF7sWBZUIzo5Surq9X6AomuodfdK/7rLMHX exOKyzcJKs+wKTILGvGPCDhL0n+VP6CCtAc04GWuBKtGvgmPXIy+wqlaRtKgGKLM ED+gOhXB0g2QyPLv90rUWz/2n7plBG3s1unt6My8y77o24FqKFw6BP/kABKBCsSA WW8hxMfsh65Wy3ufX5nUjgJTfWmC7rn7OW5Oxkwp5UchUTHy8adGCkulA8eXW/4s qzMZ/yjdbku6WNopKrXiFkCl3y9ljkZGT5xEIdyxEmP9sIxjPuMNbcGk7L9GbelA IeOqLHu1mdDPUi12YZn80IHh42LgikpsYM4Z+PeJivYR6n/SvpiEuc4CSIfvdlsf qIv4y2z1pOSQEVKF1yeJ2TSGWGJWHduRTGwwdODGCTSx02DFLwDC+F2S/VuSRrSV eEKxXESKqrqmgN4q8IlD0kCCJK5mz+YaOiX4Et/o/Ft2zs10fXyWnKpYOAnv7xhU pqgD0sthaxXQ1WwAEcONdy1Pf6LlYOM2zXwGq1V7n4u3yC734p0= =Bsic -----END PGP SIGNATURE----- --Sig_/T0YDCu0D/11=QXxXvJEG/8f--