Received: (at 57598) by debbugs.gnu.org; 13 Oct 2023 14:23:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 13 10:23:07 2023 Received: from localhost ([127.0.0.1]:47035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qrJ4E-0001b4-NA for submit <at> debbugs.gnu.org; Fri, 13 Oct 2023 10:23:07 -0400 Received: from albert.telenet-ops.be ([2a02:1800:110:4::f00:1a]:41982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <maximedevos@HIDDEN>) id 1qrJ4C-0001aH-9I for 57598 <at> debbugs.gnu.org; Fri, 13 Oct 2023 10:23:05 -0400 Received: from [IPV6:2a02:1808:87:3d3a:d21a:b3f4:d302:52bc] ([IPv6:2a02:1808:87:3d3a:d21a:b3f4:d302:52bc]) by albert.telenet-ops.be with bizsmtp id xSNX2A00P26bbaT06SNYUK; Fri, 13 Oct 2023 16:22:33 +0200 Message-ID: <e1efb06c-13ad-5824-7adf-cc2f00dc4026@HIDDEN> Date: Fri, 13 Oct 2023 16:22:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US To: 57598 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer@HIDDEN> From: Maxime Devos <maximedevos@HIDDEN> Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc. Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------PQR6XHaqTAIATYck8XUdJcNa" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r23; t=1697206953; bh=phwJz3pgIN+BtxI3Ee341Qn/GofU+66VJfglQfyxo3c=; h=Date:To:From:Subject; b=e5gw9BNZHqG539oaGD8fM4I8Wpz/bLckaPWet9+/y399WbH7BD9PSfmA9YlHgdi9u sha19vUsktxX59fFX3a9RY3nBUKiSrfz7EpoWn2J0imFngstnarGLU8Co1WNLL597d kurff0Z3Uw77tdVFGV3W44Pk9P8eo34jfsdREWnx/GumpiUIzcJLI3K+BiNRxcJvrO hkMNSGsJA32DOvXt7K7SEYrULPRo69bPzRjhcln3V3Em9NzGxb5wrRTEFJPc9rtgnx CUi8fjTGGgopjHSV8qPizFy99AKuophYxcQblN1Q9Zj8nShOcNe9Wu002HIu8982FQ Ccymnb3wETefw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 57598 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------PQR6XHaqTAIATYck8XUdJcNa Content-Type: multipart/mixed; boundary="------------QH8AmV6REWg7w11pORmG77Tf"; protected-headers="v1" From: Maxime Devos <maximedevos@HIDDEN> To: 57598 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer@HIDDEN> Message-ID: <e1efb06c-13ad-5824-7adf-cc2f00dc4026@HIDDEN> Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc. --------------QH8AmV6REWg7w11pORmG77Tf Content-Type: multipart/mixed; boundary="------------7dgZ2hXDJQVhbPfvPEpqflqG" --------------7dgZ2hXDJQVhbPfvPEpqflqG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 PiANCj4gICAgIFRoZSBzb3VyY2Ugb2YgdGhlIHBhY2thZ2UgbmVlZHMgdG8gY29ycmVzcG9u ZCB0byB3aGF0IGlzIGFjdHVhbGx5IGJ1aWx0DQo+ICAgICAoaS5lLiwgYWN0IGFzIHRoZSBj b3JyZXNwb25kaW5nIHNvdXJjZSksIHRvIGZ1bGZpbGwgb3VyIGV0aGljYWwgYW5kDQo+ICAg ICBsZWdhbCBvYmxpZ2F0aW9ucy4NCg0KKE5vdGU6IHRoaXMgbWF5IG5lZWQgdG8gYmUgY2hh bmdlZCBhIGJpdCwgaW4gdGhlIHNlbnNlIG9mICJndWl4IGJ1aWxkIA0KLS1zb3VyY2U9dHJh bnNpdGl2ZSxhbGwiIGluc3RlYWQgIG9mICJndWl4IGJ1aWxkIC0tc291cmNlIi4pDQoNCj4g VGhpcyBhbHNvIHNlZW1zIHdvcmRlZCB0b28gc3Ryb25nbHkgLS0gSSBkb24ndCB0aGluayBH dWl4IGlzIGJvdW5kIHRvDQo+IHRoZSBjb25jZXB0IG9mIHRoZSAiY29ycmVzcG9uZGluZyBz b3VyY2UiLCBhbHRob3VnaCBpdCBpcyBhIG5pY2UNCj4gcHJvcGVydHkuDQoNCkFzIGxvbmcg YXMgY29weXJpZ2h0IGxhdyBleGlzdHMgaW4gc29tZXRoaW5nIHN1ZmZpY2llbnRseSBjbG9z ZSB0byBpdHMgDQpjdXJyZW50IGZvcm0sIGFzIGxvbmcgYXMgR3VpeCBjb250YWlucyBHUEwg c29mdHdhcmUgYW5kIGFzIGxvbmcgYXMgR3VpeCANCmludGVuZHMgdG8gYmUgbGVnYWwsIEd1 aXggaXMgYm91bmQgdG8gdGhlIGNvbmNlcHQgb2YgY29ycmVzcG9uZGluZyBzb3VyY2UuDQoN CklmIEd1aXggZGVjaWRlcyBpdCBpc24ndCBib3VuZCBieSB0aGUgY29uY2VwdCBvZiBjb3Jy ZXNwb25kaW5nIHNvdXJjZSwgDQp0aGVyZSBpcyBzb21lIHNvZnR3YXJlIGluIEd1aXggSSBh bSBhIGNvcHlyaWdodCBob2xkZXIgb2YgYW5kIHRoZSBHUEwgDQpoYXMgYSBzZWN0aW9uIOKA mDguICBUZXJtaW5hdGlvbuKAmS4gIElJUkMsIGxhc3QgdGltZSBJIGNoZWNrZWQsICJndWl4 IGJ1aWxkIA0KLS1zb3VyY2VzPXRyYW5zaXRpdmUsYWxsIHNjaGVtZS1nbnVuZXQgZ3VpbGUt ZmliZXJzIiBzdGlsbCB3b3JrcywgYnV0IGlmIA0KdGhhdCBmdW5jdGlvbmFsaXR5IGlzIHJl bW92ZWQgd2l0aG91dCBhIHJlcGxhY2VtZW50IC4uLg0KDQpCZXN0IHJlZ2FyZHMsDQpNYXhp bWUgRGV2b3MNCg== --------------7dgZ2hXDJQVhbPfvPEpqflqG Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc" Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2 ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc /gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4 LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0 k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D =3DOVqp -----END PGP PUBLIC KEY BLOCK----- --------------7dgZ2hXDJQVhbPfvPEpqflqG-- --------------QH8AmV6REWg7w11pORmG77Tf-- --------------PQR6XHaqTAIATYck8XUdJcNa Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCZSlSpwUDAAAAAAAKCRBJ4+4iGRcl7txr AQD6owrhNNysD2fTlNXg0LVmvlEMOKyhWnxBlbLN+A8CkQD8Du9RDc0+UbPY2CclSrLOoGSd9x/B nGBOxYw9UEZEtwo= =ATVO -----END PGP SIGNATURE----- --------------PQR6XHaqTAIATYck8XUdJcNa--
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.Received: (at 57598) by debbugs.gnu.org; 13 Oct 2023 14:15:33 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 13 10:15:32 2023 Received: from localhost ([127.0.0.1]:47015 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qrIwu-0001MO-B8 for submit <at> debbugs.gnu.org; Fri, 13 Oct 2023 10:15:32 -0400 Received: from baptiste.telenet-ops.be ([2a02:1800:120:4::f00:13]:51132) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <maximedevos@HIDDEN>) id 1qrIwn-0001M2-EU for 57598 <at> debbugs.gnu.org; Fri, 13 Oct 2023 10:15:30 -0400 Received: from [IPV6:2a02:1808:87:3d3a:d21a:b3f4:d302:52bc] ([IPv6:2a02:1808:87:3d3a:d21a:b3f4:d302:52bc]) by baptiste.telenet-ops.be with bizsmtp id xSEu2A00R26bbaT01SEv9D; Fri, 13 Oct 2023 16:14:56 +0200 Message-ID: <a11dbe65-ad8c-0e3f-cfdd-7ce90e5db46f@HIDDEN> Date: Fri, 13 Oct 2023 16:14:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US To: 57598 <at> debbugs.gnu.org, =?UTF-8?Q?Ludovic_Court=c3=a8s?= <ludo@HIDDEN> From: Maxime Devos <maximedevos@HIDDEN> Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc. Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------F9b0xHfWx2yLlTzzDl8Ar42J" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r23; t=1697206496; bh=TspZ6n5zhFXDFulpwMVnyNCZsrEhVjJCtEM/fcU/O9o=; h=Date:To:From:Subject; b=FP8Owaz0hQ7YSJ/ma75otujrLTP9PPnadLVGdtqBBjMR9yonTC2wum5VjqZanCyIm TVAiX0ozDpkLZHgkH81PPKlY8JetpQYJvsabyEMJzc6Wt/ER4SixqiUfOf5KStGbs+ BKPQEfAieCUeGWoelbl1+VrEJ1quxuMk+ewbaX7UgXGlABGcdl1OFT+p41mcXo9RaZ fmwCqhxWLnvoFzlVQetbsgznCHcIEtTOzlPHyphXsCwORyho8Em6dL5ouPLzCuBbfX wUEnVB9UxjQcD1kq/Wb/+EYSTdZwUW0KwR+9kRd0Dembh4BolVrFke86Gj/5OOitMi VFQDQyM2iskAg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 57598 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------F9b0xHfWx2yLlTzzDl8Ar42J Content-Type: multipart/mixed; boundary="------------YuWL9z5PnyeAGoTKCiXBNRQ6"; protected-headers="v1" From: Maxime Devos <maximedevos@HIDDEN> To: 57598 <at> debbugs.gnu.org, =?UTF-8?Q?Ludovic_Court=c3=a8s?= <ludo@HIDDEN> Message-ID: <a11dbe65-ad8c-0e3f-cfdd-7ce90e5db46f@HIDDEN> Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc. --------------YuWL9z5PnyeAGoTKCiXBNRQ6 Content-Type: multipart/mixed; boundary="------------mKQHC2belrlmtdGnqsSDj182" --------------mKQHC2belrlmtdGnqsSDj182 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Pj4gK0d1aXggaGFzIHRyZWUgbWFpbiB3YXlzIG9mIG1vZGlmeWluZyB0aGUgc291cmNlIGNv ZGUgb2YgYSBwYWNrYWdlLCB0aGF0DQo+PiAreW91IGFzIGEgcGFja2FnZXIgbWF5IHVzZS4g IFRoZXNlIGFyZSBwYXRjaGVzLCBzbmlwcGV0cyBhbmQgcGhhc2VzLg0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgXg0KPiDigJxtYXkgdXNlOiBwYXRjaGVzLCBzbmlwcGV0cywg YW5kIGJ1aWxkIHBoYXNlcy7igJ0NCg0KT0ssIGZvciB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRo ZSBwYXRjaCBJIHdvbid0IHdyaXRlLg0KDQo+PiArRWFjaCBvbmUgaGFzIGl0cyBzdHJlbmd0 aHMgYW5kIGRyYXdiYWNrcy4gIFRvIGRlY2lkZSBiZXR3ZWVuIHRoZSB0aHJlZSwNCj4gDQo+ IHMvZGVjaWRlIGJldHdlZW4gdGhlIHRocmVlL2Nob29zZSBhbW9uZyB0aGVzZS8NCg0KV2h5 Pw0KDQo+IFRvZ2dsZSBxdW90ZSAoNyBsaW5lcykNCj4+ICt0aGVyZSBhcmUgYSBmZXcgZ3Vp ZGluZyBwcmluY2lwbGVzIHRvIHNhdGlzZnkgc2ltdWx0YW51b3VzbHkgd2hlcmUNCj4+ICtw b3NzaWJsZToNCj4+ICsNCj4+ICtAaXRlbWl6ZQ0KPj4gK0BpdGVtDQo+PiArSW4gcHJpbmNp cGxlLCBHdWl4IG9ubHkgaGFzIGZyZWUgc29mdHdhcmU7IHdoZW4gdGhlIHVwc3RyZWFtIHNv dXJjZQ0KPiANCj4gcy9JbiBwcmluY2lwbGUsIEd1aXggb25seSBoYXMgZnJlZSBzb2Z0d2Fy ZS9FdmVyeSBwYWNrYWdlIGluIEd1aXggaXMNCj4gZnJlZSBzb2Z0d2FyZS9nDQoNClRoaXMg bmV3IHNlbnRlbmNlIGlzIG1vc3QgbGlrZWx5IGZhbHNlLiAgVGhlcmUgaGF2ZSBiZWVuIHBh Y2thZ2VzIGluIA0KR3VpeCB0aGF0IHdlcmUgbm9uLWZyZWUgYW5kIGhhdmUgYmVlbiBub24t ZnJlZSwgcXVpdGUgbGlrZWx5IHRoZXJlIHdpbGwgDQpiZSBub24tZnJlZSBwYWNrYWdlcyBp biBHdWl4IGluIHRoZSBmdXR1cmUuICBJIHdvdWxkIHJhdGhlciBoYXZlIHRoYXQgDQpHdWl4 IGRvZXNuJ3QgbGllIGFib3V0IGl0c2VsZi4NCg0KPj4gK2NvbW11bml0eSAoaS5lLiwgcGF0 dGVybnMgdGhhdCBhcHBlYXIgdGhyb3VnaG91dCBAY29kZXtnbnUvcGFja2FnZXMvLi4ufSkN Cj4gDQo+IE5vcm1hbGx5IHN1Y2ggcGFyZW50aGV0aWNhbCBleHByZXNzaW9ucyBnbyBiZXR3 ZWVuIGVtIGRhc2hlczoNCj4gDQo+ICAgY29tbXVuaXR5LS0taS5lLiwgcGF0dGVybnMgdGhh dCBhcHBlYXIgdGhyb3VnaG91dA0KPiAgIEBmaWxle2dudS9wYWNrYWdlc30tLS1hbmQg4oCm DQoNCkVyciwgc291cmNlPyAgTm9ybWFsbHkgcGFyZW50aGV0aWNhbCBleHByZXNzaW9ucyBn byBiZXR3ZWVuIHBhcmVudGhlc2VzLiANCiAgQWxzbywgbm9ybWFsaXR5IGlzIGlycmVsZXZh bnQuDQoNCj4+ICtUbyBtYWtlIHRoaW5ncyBtb3JlIGNvbmNyZXRlIGFuZCB0byByZXNvbHZl IGNvbmZsaWN0cyBiZXR3ZWVuIHRoZQ0KPj4gK3ByaW5jaXBsZXMsIGEgZmV3IGNhc2VzIGhh dmUgYmVlbiB3b3JrZWQgb3V0Og0KPj4gKw0KPj4gK0BzdWJzdWJzZWN0aW9uIFJlbW92aW5n IG5vbi1mcmVlIHNvZnR3YXJlDQo+PiArTm9uLWZyZWUgc29mdHdhcmUgaGFzIHRvIGJlIHJl bW92ZWQgaW4gc25pcHBldHM7IHRoZSByZWFzb24gaXMgdGhhdA0KPj4gK3BhdGNoZXMgb3Ig cGhhc2VzIHdpbGwgbm90IHdvcmsuDQo+IA0KPiBZb3UgY2Fu4oCZdCBoYXZlIGEgY29sb24g YmV0d2VlbiB0aGUgc2VjdGlvbiBoZWFkaW5nLiAgSW5zdGVhZCwgeW91IGNhbg0KPiB3cml0 ZSDigJxhIGZldyBjYXNlcyBoYXZlIGJlZW4gd29ya2VkIG91dCBhbmQgd2lsbCBiZSBpbGx1 c3RyYXRlZCBpbiB0aGUNCj4gZm9sbG93aW5nIHNlY3Rpb25zLuKAnQ0KDQpZb3UgZGVmaW5p dGVseSBjYW4gaGF2ZSBhIGNvbG9uIGJldHdlZW4gdGhlIHNlY3Rpb24gaGVhZGluZywgSSBq dXN0IGRpZCANCnNvLiAgQWxzbywgdGhhdCBuZXcgc2VudGVuY2UgaGFzIGEgZGlmZmVyZW50 IG1lYW5pbmcuDQoNCiA+IFNlY3Rpb24gdGl0bGVzIHNob3VsZCBiZSBjYXBpdGFsaXplZC4N Cg0KVGhlIGxldHRlciBSIGlzIGNhcGl0YWxpemVkLiAgSSBkaXNhZ3JlZSB0aGF0IG5vbi1m aXJzdCB3b3JkcyBzaG91bGQgYmUgDQpjYXBpdGFsaXplZCwgYnV0IEkgc3VwcG9zZSB0aGF0 J3MgYSBzdHlsZSBjaGFuZ2UgdGhhdCwgaWYgZG9uZSwgc2hvdWxkIA0KYmUgc2VwYXJhdGUg ZnJvbSB0aGlzIHBhdGNoLg0KDQo+IExlYXZlIGEgYmxhbmsgbGluZSBhZnRlciB0aGUgc2Vj dGlvbiB0aXRsZS4NCg0KV2h5Pw0KDQo+IEluc3RlYWQgb2Yg4oCcd2lsbCBub3Qgd29ya+KA nSwgd2hpY2ggaXMgdmFndWUsIEnigJlkIHN1Z2dlc3QgbW9yZSBleHBsaWNpdA0KPiB3b3Jk aW5nOiDigJx3b3VsZCBub3QgYmUgYXBwcm9wcmlhdGUgYmVjYXVzZSB0aGV5IHdvdWxkIGV4 cG9zZSB0aGUNCj4gb2ZmZW5kaW5nIGNvZGUu4oCdDQoNClRvIGJlIG1vcmUgcHJlY2lzZToN Cg0Kcy93b3VsZCBub3QgYmUgYXBwcm9wcmlhdGUvd291bGQgYmUgaW5hcHByb3ByaWF0ZQ0K DQrigJhleHBvc2UgY29kZeKAmSBhbmQg4oCYb2ZmZW5kaW5nIGNvZGXigJkgc2VlbXMgcmF0 aGVyIHZhZ3VlIHRvIG1lLiAg4oCYd2lsbCBub3QgDQp3b3Jr4oCZIG1pZ2h0IGJlIHNsaWdo dGx5IHZhZ3VlLCBidXQgaXQncyBjbGVhciBmcm9tIGNvbnRleHQgKGkuZS4sIHRoZSANCndv cmRzIGJlZm9yZSB0aGUgc2VtaWNvbG9uKS4gIEFsc28sIGRpZG4ndCB5b3UgaGF2ZSBjb21w bGFpbnRzIGFib3V0IA0KZGVuc2VuZXNzPw0KDQo+PiArRm9yIHBhdGNoZXMsIHRoZSBwcm9i bGVtIGlzIHRoYXQgYSBwYXRjaCByZW1vdmluZyBhIG5vbi1mcmVlIGZpbGUNCj4+ICthdXRv bWF0aWNhbGx5IGNvbnRhaW5zIHRoZSBub24tZnJlZSBmaWxlQGZvb3Rub3Rle0l0IGhhcyBi ZWVuIG5vdGVkIHRoYXQNCj4+ICtnaXQgcGF0Y2hlcyBzdXBwb3J0IHJlbW92aW5nIGZpbGVz IHdpdGhvdXQgaW5jbHVkaW5nIHRoZSBmaWxlIGluIHRoZQ0KPj4gK3BhdGNoIGluDQo+PiAr QHVybHtodHRwczovL3loZXRpbC5vcmcvZ3VpeC84YjEzZTg5OS1lYjYwLTQ5MGItYTI2OC02 MzkyNDk2OThjODFAQHd3dy5mYXN0bWFpbC5jb20vfS4gSWYNCj4+ICtpdCBpcyB2ZXJpZmll ZCB0aGF0IHRoZSBAY29tbWFuZHtwYXRjaH0gdXRpbGl0eSBzdXBwb3J0cyBzdWNoIHBhdGNo ZXMsDQo+PiArdGhpcyBtZXRob2QgY2FuIGJlIHVzZWQgYW5kIHRoaXMgcG9saWN5IGFkanVz dGVkIGFwcHJvcHJpYXRlbHkufSwgYW5kIHdlDQo+PiArZG8gbm90IHdhbnQgYW55dGhpbmcg bm9uLWZyZWUgaW4gR3VpeCBldmVuIGlmIG9ubHkgaW4gaXRzIHBhdGNoZXMuDQo+IA0KPiBJ 4oCZZCBkcm9wIHRoZSBmb290bm90ZSwgaXTigJlzIGFscmVhZHkgZGVuc2UgZW5vdWdoLg0K DQpJIHdvdWxkIHJhdGhlciBrZWVwIHRoZSBmb290bm90ZSAtLSB0aGVyZSBhcmUgbm8gZmls ZSBzaXplIGNvbmNlcm5zIGZvciANCmluZm8gZmlsZXMsIGl0IGNvbnRhaW5zIHVzZWZ1bCBp bmZvcm1hdGlvbiwgYW5kIGl0J3MgYSBfZm9vdG5vdGVfLiAgT25lIA0Kb2YgdGhlIG1haW4g YmVuZWZpdHMgb2YgZm9vdG5vdGVzIGlzIHRoYXQgdGhleSBhcmUgb3V0IG9mIHRoZSB3YXkg YW5kIA0KeW91IGNhbiBqdXN0IHNraXAgdGhlbSBpZiB5b3UgZG9uJ3Qgd2FudCB0byByZWFk IHRoZW0/DQoNCj4gcy9zbmlwcGV0cyBoZXJlOi9zbmlwcGV0cyBoZXJlLi8NCg0KRXJyLCBu bz8gRGlyZWN0bHkgYWZ0ZXIgdGhpcyBzZW50ZW5jZSBJJ20gc2F5aW5nIHdoaWNoIHRoZSBi ZW5lZml0cyBhcmUsIA0Kc28gdGhpcyBzaG91bGQgYmUgJzonLCBub3QgJy4nIC0tICc6JyBp cyBzdHJpY3RseSBiZXR0ZXIgaGVyZS4NCg0KPiBzL1doZW4gdXNpbmcgc25pcHBldHMvRmly c3QsIHdoZW4gdXNpbmcgc25pcHBldHMvDQoNClRoZSBuZXh0IHNlbnRlbmNlcyBkb24ndCBk byDigJhTZWNvbmQsIC4uLuKAmSwg4oCYVGhpcmQsIC4uLuKAmSwgc28gbm8uDQoNCj4gVG9n Z2xlIHF1b3RlICgyIGxpbmVzKQ0KPj4gK0FzIHN1Y2gsIHNuaXBwZXRzIGFyZSByZWNvbW1l bmRlZCBoZXJlLg0KPiANCj4gcy9hcmUgcmVjb21tZW5kZWQgaGVyZS9hcmUgdGhlIHJlY29t bWVuZGVkIHdheSB0byBkZWxldGUgbm9uLWZyZWUgbWF0ZXJpYWwvDQoNCk5vLiAgUGxlYXNl IHNlZSBzZWUgdGhlIHN1YnN1YnNlY3Rpb24gdGl0bGU6DQoNCiA+ICtAc3Vic3Vic2VjdGlv biBSZW1vdmluZyBidW5kbGVkIGxpYnJhcmllcw0KDQpJdCdzIG5vdCBtZXJlbHkgYWJvdXQg bm9uLWZyZWUgbWF0ZXJpYWwgaW4gaW4gYnVuZGxlZCBsaWJyYXJpZXMsIGl0IGlzIA0KYWJv dXQgYWxsIGJ1bmRsZWQgbGlicmFyaWVzLiAgSXQgaXMgbm90IGFib3V0IGFsbCBub24tZnJl ZSBtYXRlcmlhbCwgYnV0IA0Kb25seSBhYm91dCBtYXRlcmlhbCBpbiBidW5kbGVkIGxpYnJh cmllcyAodW5idW5kbGVkIG5vbi1mcmVlIG1hdGVyaWFsIA0KYXJlIHRyZWF0ZWQgaW4gdGhl IHByZXZpb3VzIHN1YnN1YnNlY3Rpb24pLg0KDQpBcyBzdWNoLCB0aGUgcHJvcG9zZWQgbmV3 IHNlbnRlbmNlIGRvZXMgbm90IGZpdCB0aGUgc3Vic3Vic2VjdGlvbi4NCg0KPiBUb2dnbGUg cXVvdGUgKDIgbGluZXMpDQo+PiArQHN1YnN1YnNlY3Rpb24gRml4aW5nIHRlY2huaWNhbCBp c3N1ZXMgKGNvbXBpbGF0aW9uIGVycm9ycywgdGVzdCBmYWlsdXJlcywgb3RoZXIgYnVncyAu Li4pDQo+IA0KPiBJbiBhZGRpdGlvbiB0byBjYXBpdGFsaXppbmcsIHBsZWFzZSByZW1vdmUg dGhlIHBhcmVudGhldGljYWwgYml0Lg0KDQpOby4gIOKAmFRlY2huaWNhbCBpc3N1ZXPigJkg aXMgdmFndWUsIHRoZSBwYXJlbnRoZXRpY2FsIGJpdCBjbGFyaWZpZXMgDQp0aGluZ3MuICBC ZXNpZGVzLCBpbiBhbm90aGVyIGNvbW1lbnQgZm9yIHNvbWV0aGluZyBlbHNlIHlvdSB3YW50 ZWQgDQp0aGluZ3MgdG8gYmUgbGVzcyB2YWd1ZSBieSBhZGRpbmcgYWRkaXRpb25hbCB0ZXh0 Lg0KDQogPiBDb3VsZCB5b3Ugc2VuZCBhbiB1cGRhdGVkIHZlcnNpb24/DQoNCk5vLiAgVGhl IGNvbnRpbnVlZCBtaXN1bmRlcnN0YW5kaW5nIGVsc2V3aGVyZSBpbiB0aGUgdGhyZWFkIGFu ZCB0aGUgDQppbmNvbnNpc3RlbmN5IGFuZCBvY2Nhc2lvbmFsIHZhZ3VlbmVzcyBpbiBhcmd1 bWVudHMgaXMgdGlyZXNvbWUuDQoNCkJlc3QgcmVnYXJkcywNCk1heGltZSBEZXZvcy4NCg== --------------mKQHC2belrlmtdGnqsSDj182 Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc" Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2 ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc /gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4 LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0 k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D =3DOVqp -----END PGP PUBLIC KEY BLOCK----- --------------mKQHC2belrlmtdGnqsSDj182-- --------------YuWL9z5PnyeAGoTKCiXBNRQ6-- --------------F9b0xHfWx2yLlTzzDl8Ar42J Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCZSlQ3QUDAAAAAAAKCRBJ4+4iGRcl7kbF APsF4aNm31Y2pABe7MvA8/Fz6vs5FoytQl8KIkKj36ELLQEA+iID5WeiMr3M70cPbZ9j3svgnQBW 2zZSq+13EKO64QM= =6JlF -----END PGP SIGNATURE----- --------------F9b0xHfWx2yLlTzzDl8Ar42J--
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.Christopher Baines <mail@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 57598) by debbugs.gnu.org; 4 Nov 2022 16:39:11 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 04 12:39:11 2022 Received: from localhost ([127.0.0.1]:54673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oqzip-0003uX-1r for submit <at> debbugs.gnu.org; Fri, 04 Nov 2022 12:39:11 -0400 Received: from mail-wr1-f50.google.com ([209.85.221.50]:42658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <zimon.toutoune@HIDDEN>) id 1oqzim-0003uH-PU for 57598 <at> debbugs.gnu.org; Fri, 04 Nov 2022 12:39:09 -0400 Received: by mail-wr1-f50.google.com with SMTP id cl5so7802818wrb.9 for <57598 <at> debbugs.gnu.org>; Fri, 04 Nov 2022 09:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=tP3ri0gawcTtJd58/IEs5J/Rb1+/sKQNnLtG2/guAQk=; b=a3M2OuCRja+E4LRt8QGoqdweQrQrVvAI7bRe+qcswMDJ+mmTp3G06Cjx6ROsVpr1oy wnYO8afhqfGlp/gXGoPpD01ZWs5dRa39p0OHyOC/N+DqxgLPB9N+lKP5oNghJhePXpXv gXyDWX5K3LnS0bgVFR0AojgktY5bSELHxz5hGNcl1h1rBvqQizz2iSou2A2FQHTzYcAo qpDSeGe+mfVz5T7DbRqgdmlaXRtGvhoPhgGsr6uDEpzyq1xHuWHmMrlN/tUtNMKxDsxP EpzJqVjiwGs/c84v19MGJWOGCexhLGVJ2dUATXGmTvbn/5fzWuWfuuw/zUpoUSHB2pw5 tfgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=tP3ri0gawcTtJd58/IEs5J/Rb1+/sKQNnLtG2/guAQk=; b=t0w+qedqijdrMJNDaBk7M8m6CFgcPttIDf/BRrYIIjYI7k1KZ1DvVk6R3EMttr2bHk j+T9oN992Y4OqksOtaDkgCcIntM2ZQXaBZGDMJQsazWuWK/hqkzTtTvBCzTyVMSLBUGx X8xW5S1wBehgLyYhlovIR3UuYrAEF6sDmlM4iFbCtcFUdOUqDS0cwKGAeW/GUD7ItM0Y zFINY355JQXbNRf6Pn6rJxhhMP/oiH8kGoHnPyDrLLjVdysRdACwcoMV48TAOEP1clXB XbWHFCcP8nkwk/lgR1PWFoT8DRCKnfv4L1DRRiMtAeQRtXbsPV5XTqYOeiFVZnrRow0t OZGA== X-Gm-Message-State: ACrzQf3JivQj3A4dlG78yEtStkdoRWmH94c/nmcYqUY8NdUrHoRTVer2 5ap9TnArlmUmCH6UfpOopD0= X-Google-Smtp-Source: AMsMyM44FiI0TcJMFTmKC5pIz85tYg9Tw3xRP13ED+tVgLkW6rUgARBE4v6KWXOzcOW7uGipSPE3Yw== X-Received: by 2002:a5d:6d02:0:b0:236:ed2d:b3eb with SMTP id e2-20020a5d6d02000000b00236ed2db3ebmr11071577wrq.456.1667579942296; Fri, 04 Nov 2022 09:39:02 -0700 (PDT) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id l21-20020a05600c4f1500b003c6bd12ac27sm3772897wmq.37.2022.11.04.09.39.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 09:39:01 -0700 (PDT) From: zimoun <zimon.toutoune@HIDDEN> To: Maxime Devos <maximedevos@HIDDEN> Subject: Re: bug#57598: [PATCH] doc: Update contribution guidelines on patches, etc. References: <20220905160048.18173-1-maximedevos@HIDDEN> <20220909123051.15747-1-maximedevos@HIDDEN> Date: Fri, 04 Nov 2022 17:07:53 +0100 In-Reply-To: <20220909123051.15747-1-maximedevos@HIDDEN> (Maxime Devos's message of "Fri, 9 Sep 2022 14:30:51 +0200") Message-ID: <86pme24s9y.fsf_-_@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 57598 Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= <ludo@HIDDEN>, Kyle Meyer <kyle@HIDDEN>, 57598 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer@HIDDEN>, Liliana Marie Prikler <liliana.prikler@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hi, Some work and energy had been put in these patches #57598 [1,2] and they appear to me a nice improvement. So what is missing? Some rewording here or there? Merge some wording from one to the other? 1: <https://issues.guix.gnu.org/issue/57598#msgid-1ba11b761cf81336b9788d5f0650b3742eed9d7f> 2: <https://issues.guix.gnu.org/issue/57598#msgid-7b0e5632669defb4d951b1cec54515bacc1c0a89> Cheers, simon
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.
Received: (at 57598) by debbugs.gnu.org; 26 Sep 2022 00:47:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 25 20:47:40 2022
Received: from localhost ([127.0.0.1]:48751 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1occHc-000230-Fq
for submit <at> debbugs.gnu.org; Sun, 25 Sep 2022 20:47:40 -0400
Received: from mail-qv1-f45.google.com ([209.85.219.45]:41766)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <maxim.cournoyer@HIDDEN>) id 1occHZ-00022K-Kd
for 57598 <at> debbugs.gnu.org; Sun, 25 Sep 2022 20:47:38 -0400
Received: by mail-qv1-f45.google.com with SMTP id l14so3491313qvq.8
for <57598 <at> debbugs.gnu.org>; Sun, 25 Sep 2022 17:47:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=content-transfer-encoding:mime-version:user-agent:message-id
:in-reply-to:date:references:subject:cc:to:from:from:to:cc:subject
:date; bh=Jm7/wvws2HaMGhoVs7Rkc/13pq705R/qLkD3gHDTGzc=;
b=KJFDjWYEdX4L6+JCdHvWgSD/F5yQg4T6cKtncIwSc7LMJbuz8aKElPmTR3ObZS8ehN
0Ji6qf+FPn8wo/moIuqsZIy+sj65RbRlHcP2/V8SVnEVCfuuqPrRVMO3V2Sjkk7oQ6G3
RZod9UMwNJFX9lAKRKtFejmsofXh4mjVGOydt1JU0PxGJaAaf8EqllRocom74HsmyLCf
NDTbp8hSHsgG7exAzVIGhc6eLKuTDvOqo/SQOYOXTdpk+IVW8wKGXJsbuuBARWcMtmVz
mP32rSuuGW6GbPQ8xkHt8phqwW6WS6Y9+1ZNhB6+FSfesYkDtWZSO2nFTYfXhnKIzz3P
ouXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=content-transfer-encoding:mime-version:user-agent:message-id
:in-reply-to:date:references:subject:cc:to:from:x-gm-message-state
:from:to:cc:subject:date;
bh=Jm7/wvws2HaMGhoVs7Rkc/13pq705R/qLkD3gHDTGzc=;
b=jCmICaLcIOugADpG/ZsspY+fVfRWHk0op2vYi6I/rcEqmMlC7bwhq6EkrIBwy8Xwu0
jLSt68fWFC39upEy2CjbS3I50+xVKfr44yAx/9xK2ejRSxOKm7YZ3Lnjgq8G4EKMzXiT
Gf9oG5jb8teZuRwFMFY+h0bO1wpOx22udlTL8n8AyNHSkdZFadmQEqTgr6fRk6XkR0P0
3zoZ+o60Gi6244cTYN7zdU19+PFl0LA1WmTDsjtopQkkJEA9SuapCehkJuskxLVJn6vn
f0+q10qBUWgOEBgWWkILsxf5HqA6RwYoFXc4h9qp2LhwAItg+JH3urhpF0QnotYoZRNI
NboQ==
X-Gm-Message-State: ACrzQf3lEAxNVtC6223s5NDOUWBtUv3/IslaYru94f1zcnVqKas8doGn
OR+EoIN9j3zPD2yBX9s6Phu4D9/JO5w=
X-Google-Smtp-Source: AMsMyM79NgbhQqbUTgnwn4Q9Jts9mOe+NcHeUlYELZAw987bSHSC+WhMv78MotAzJ7i3BaDKSJRUCg==
X-Received: by 2002:a05:6214:20aa:b0:4ac:a951:11d6 with SMTP id
10-20020a05621420aa00b004aca95111d6mr15371758qvd.88.1664153251999;
Sun, 25 Sep 2022 17:47:31 -0700 (PDT)
Received: from hurd (dsl-10-132-99.b2b2c.ca. [72.10.132.99])
by smtp.gmail.com with ESMTPSA id
u2-20020ae9d802000000b006ce407b996asm10450989qkf.69.2022.09.25.17.47.30
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 25 Sep 2022 17:47:31 -0700 (PDT)
From: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
To: Ludovic =?utf-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Subject: Re: bug#57598: [PATCH] doc: Update contribution guidelines on
patches, etc.
References: <20220905160048.18173-1-maximedevos@HIDDEN>
<20220909123051.15747-1-maximedevos@HIDDEN>
<87zgeoapr4.fsf_-_@HIDDEN>
Date: Sun, 25 Sep 2022 20:47:29 -0400
In-Reply-To: <87zgeoapr4.fsf_-_@HIDDEN> ("Ludovic =?utf-8?Q?Court=C3=A8s?=
=?utf-8?Q?=22's?= message of "Sat, 24 Sep 2022 15:03:27 +0200")
Message-ID: <87h70v6jxa.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 57598
Cc: Maxime Devos <maximedevos@HIDDEN>, 57598 <at> debbugs.gnu.org,
guix-maintainers@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Hi,
Ludovic Court=C3=A8s <ludo@HIDDEN> writes:
> Hi!
>
> Thanks for this welcome addition! Modulo the cosmetic suggestions
> below, I think it=E2=80=99s fine.
>
> Maintainers, if you have something to say on the guidelines, now=E2=80=99=
s the
> time!
>
> https://issues.guix.gnu.org/57598
A couple things, on top of things you spot yourself and discussed by
Liliana (although I haven't read the full thread, which is getting
rather long):
1. s/tree/three/
2. I think it'd be nice to mention that that the work of freeing
software should not be done in Guix, but in upstream or if that fails as
a second upstream project. That's easier to maintain longer term (more
interested parties can share the burden), and friendlier to other FSDG
distributions. Also, software containing nonfree software is risky: we
have no reasons to trust they won't add more nonfree things to it,
putting our users at risk, so deciding to include such software should
be made carefully. It may be preferable to simply not include it, if
the risks outweighs the benefits.
3. "guiding principles" sounds a bit too serious/strong to my taste. I
think it's more guidelines we're discussing.
4.
The source of the package needs to correspond to what is actually built
(i.e., act as the corresponding source), to fulfill our ethical and
legal obligations.
This also seems worded too strongly -- I don't think Guix is bound to
the concept of the "corresponding source", although it is a nice
property.
I find the new text rather long but it does add value, and I wouldn't
know how to structure or improve it much, so I'm in favor of including
it.
Thanks,
Maxim
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.Received: (at 57598) by debbugs.gnu.org; 25 Sep 2022 18:59:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 25 14:59:00 2022 Received: from localhost ([127.0.0.1]:48547 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ocWqC-0001tS-4g for submit <at> debbugs.gnu.org; Sun, 25 Sep 2022 14:59:00 -0400 Received: from out2.migadu.com ([188.165.223.204]:50140) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <kyle@HIDDEN>) id 1ocWq6-0001tF-8g for 57598 <at> debbugs.gnu.org; Sun, 25 Sep 2022 14:58:58 -0400 X-Report-Abuse: Please report any abuse attempt to abuse@HIDDEN and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kyleam.com; s=key1; t=1664132332; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=o71eCuQbift4kMDDGFhPtKQOaxXkgc0D4XPBNDednJk=; b=R9+WWBpGDmt2LqNh9IhlHzb//zYI79J7TYZC3ctTuddD4zY/itN2zIQ63RN05BjwohKRdk 69Z4xzMEvQnIzH6ntQ8bmr4KT7WOlNFLDT8UWZnW8TB/WhfY89CtMWAgJedcTazFnAKi8r 24UFR1E/i4AcUSQquU5raFAPuAqmfSaRrdtxUTlbezczsSlXaMMlY+KM55ZC3dP5afvFSQ 1i93KomEiKG1a0mIV1Zevx6bcSucEJyBYJqwsOzppurDgjpA+cE6hFXw2+NviszMYwUHQE i2BycebNMQ5alzkK/1FrsuWLtmw1PEYz6fwScfobqfbXsI675C+3zQ5XLc56ZQ== From: Kyle Meyer <kyle@HIDDEN> To: Maxime Devos <maximedevos@HIDDEN> Subject: Re: [bug#57598] [PATCH] doc: Update contribution guidelines on patches, etc. In-Reply-To: <66417bb1-f81e-b2e6-6f37-c5dc9bb39dc9@HIDDEN> References: <20220905160048.18173-1-maximedevos@HIDDEN> <20220909123051.15747-1-maximedevos@HIDDEN> <87zgeoapr4.fsf_-_@HIDDEN> <66417bb1-f81e-b2e6-6f37-c5dc9bb39dc9@HIDDEN> Date: Sun, 25 Sep 2022 14:58:50 -0400 Message-ID: <87pmfj1dsl.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: kyleam.com X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57598 Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= <ludo@HIDDEN>, 57598 <at> debbugs.gnu.org, guix-maintainers@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Maxime Devos writes: > On 24-09-2022 15:03, Ludovic Court=C3=A8s wrote: [...] >> You can write comments below the --- and diffstats. That way, =E2=80=98= git am=E2=80=99 >> will ignore them when applying the patch. > > I know of '---', but AFAICT this is undocumented behaviour, so I'm=20 > hesitant to rely on that. I don't think you should be worried about Git changing that behavior. It's used heavily by the Git project itself as well as many other projects. Here are some mentions in git.git (4fd6c5e444): ,----[ Documentation/SubmittingPatches ] | You often want to add additional explanation about the patch, | other than the commit message itself. Place such "cover letter" | material between the three-dash line and the diffstat. For | patches requiring multiple iterations of review and discussion, | an explanation of changes between each iteration can be kept in | Git-notes and inserted automatically following the three-dash | line via `git format-patch --notes`. `---- ,----[ Documentation/git-notes.txt ] | Notes can also be added to patches prepared with `git format-patch` by | using the `--notes` option. Such notes are added as a patch commentary | after a three dash separator line. `---- ,----[ Documentation/user-manual.txt ] | `git format-patch` can include an initial "cover letter". You can insert | commentary on individual patches after the three dash line which | `format-patch` places after the commit message but before the patch | itself. If you use `git notes` to track your cover letter material, | `git format-patch --notes` will include the commit's notes in a similar | manner. `---- ,----[ Documentation/git-format-patch.txt ] | Typically it will be placed in a MUA's drafts folder, edited to add | timely commentary that should not go in the changelog after the three | dashes, and then sent as a message whose body, in our example, starts | with "arch/arm config files were...". On the receiving end, readers [...] `----
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.Received: (at 57598) by debbugs.gnu.org; 25 Sep 2022 17:59:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 25 13:59:59 2022 Received: from localhost ([127.0.0.1]:48506 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ocVv4-0000RZ-PI for submit <at> debbugs.gnu.org; Sun, 25 Sep 2022 13:59:59 -0400 Received: from andre.telenet-ops.be ([195.130.132.53]:34726) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <maximedevos@HIDDEN>) id 1ocVv3-0000RR-9r for 57598 <at> debbugs.gnu.org; Sun, 25 Sep 2022 13:59:57 -0400 Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16] ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]) by andre.telenet-ops.be with bizsmtp id QHzv2800R20ykKC01HzwHl; Sun, 25 Sep 2022 19:59:56 +0200 Message-ID: <66417bb1-f81e-b2e6-6f37-c5dc9bb39dc9@HIDDEN> Date: Sun, 25 Sep 2022 19:59:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: bug#57598: [PATCH] doc: Update contribution guidelines on patches, etc. Content-Language: en-US To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= <ludo@HIDDEN> References: <20220905160048.18173-1-maximedevos@HIDDEN> <20220909123051.15747-1-maximedevos@HIDDEN> <87zgeoapr4.fsf_-_@HIDDEN> From: Maxime Devos <maximedevos@HIDDEN> In-Reply-To: <87zgeoapr4.fsf_-_@HIDDEN> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------6QnkPfuL5ILUpfCso4m5K8P9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1664128796; bh=9A6DPaRxmSLRlnHSSOBBnN4fmlDzfqObdvpFNQu9Rvc=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=e25LzUsllnmO8cSC6GLkUehH9Gd4g0E0uVtn6AuVqtdfxYcAg8jIxX8NCx4Eqo6H9 xWW7eLVx8P36Z5GPRLwekztdb7uPMB/56GoXdCbMz765sRkf6p5kkT0RkqnCxqHwoM ws7GgB+nhCq5RKNgagUDvke+wZAVL+GTw5u12/vq96OARefpL0eXxLR09DeTtMrrNp s0x7wg91EoLgxt/PNiPOwgKDk2raQCZ/etnEkN6LwrvSzSTiy5pUTn9TG0kGp76Sea b1zMOolrgSrIajeD5qo2i7ay06U1AZQxLjeN1ojN5B058IDWxV16SPHgdCYZNGBNJp Zwu/3sN1T5tUQ== X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 57598 Cc: 57598 <at> debbugs.gnu.org, guix-maintainers@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.5 (---) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------6QnkPfuL5ILUpfCso4m5K8P9 Content-Type: multipart/mixed; boundary="------------zgJHLE0uRRZmtVO075t1fQ8n"; protected-headers="v1" From: Maxime Devos <maximedevos@HIDDEN> To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= <ludo@HIDDEN> Cc: 57598 <at> debbugs.gnu.org, guix-maintainers@HIDDEN Message-ID: <66417bb1-f81e-b2e6-6f37-c5dc9bb39dc9@HIDDEN> Subject: Re: bug#57598: [PATCH] doc: Update contribution guidelines on patches, etc. References: <20220905160048.18173-1-maximedevos@HIDDEN> <20220909123051.15747-1-maximedevos@HIDDEN> <87zgeoapr4.fsf_-_@HIDDEN> In-Reply-To: <87zgeoapr4.fsf_-_@HIDDEN> --------------zgJHLE0uRRZmtVO075t1fQ8n Content-Type: multipart/mixed; boundary="------------8v09X0mmvj1s6LeOTCnT0f91" --------------8v09X0mmvj1s6LeOTCnT0f91 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQoNCk9uIDI0LTA5LTIwMjIgMTU6MDMsIEx1ZG92aWMgQ291cnTDqHMgd3JvdGU6DQo+IEhp IQ0KPiANCj4gVGhhbmtzIGZvciB0aGlzIHdlbGNvbWUgYWRkaXRpb24hICBNb2R1bG8gdGhl IGNvc21ldGljIHN1Z2dlc3Rpb25zDQo+IGJlbG93LCBJIHRoaW5rIGl04oCZcyBmaW5lLg0K PiANCj4gTWFpbnRhaW5lcnMsIGlmIHlvdSBoYXZlIHNvbWV0aGluZyB0byBzYXkgb24gdGhl IGd1aWRlbGluZXMsIG5vd+KAmXMgdGhlDQo+IHRpbWUhDQo+IA0KPiAgICBodHRwczovL2lz c3Vlcy5ndWl4LmdudS5vcmcvNTc1OTgNCj4gDQo+IE1heGltZSBEZXZvcyA8bWF4aW1lZGV2 b3NAdGVsZW5ldC5iZT4gc2tyaWJpczoNCj4gDQo+PiAqIGRvYy9jb250cmlidXRpbmcudGV4 aSAoTW9kaWZ5aW5nIFNvdXJjZXMpOiBSZXBsYWNlZCB3aXRoIC4uLg0KPj4gKCJNb2RpZnlp bmcgU291cmNlcyIpOiAuLi4gdGhpcy4gIExpc3QgbW9yZSB1c2UgY2FzZXMgYW5kIHNvbWUg cHJpbmNpcGxlcy4NCj4+DQo+PiBUaGlzIHBhdGNoIGluY29ycG9yYXRlcyBzb21lIHRleHQg d3JpdHRlbiBieSBMaWxpYW5hIE1hcmllIFByaWtsZXIuICBUaGUNCj4+IHN0cnVjdHVyZSBp cyBiYXNlZCBvbiBhIHByb3Bvc2FsIGJ5IEp1bGllbiBMZXBpbGxlci4gIFRoZSB0ZXh0IGhh cyBiZWVuDQo+PiByZXZpc2VkIGJhc2VkIG9uIHJldmlld3MgYnkgRGF2aWQgTGFyc3NvbiBh bmQgYmxha2UuDQo+Pg0KPj4gKCEgcmVtb3ZlIGZvbGxvd2luZyB0ZXh0IGJlZm9yZSBjb21t aXR0aW5nICEpDQo+IA0KPiBZb3UgY2FuIHdyaXRlIGNvbW1lbnRzIGJlbG93IHRoZSAtLS0g YW5kIGRpZmZzdGF0cy4gIFRoYXQgd2F5LCDigJhnaXQgYW3igJkNCj4gd2lsbCBpZ25vcmUg dGhlbSB3aGVuIGFwcGx5aW5nIHRoZSBwYXRjaC4NCg0KSSBrbm93IG9mICctLS0nLCBidXQg QUZBSUNUIHRoaXMgaXMgdW5kb2N1bWVudGVkIGJlaGF2aW91ciwgc28gSSdtIA0KaGVzaXRh bnQgdG8gcmVseSBvbiB0aGF0Lg0KDQogPiBbLi4uXQ0KPiBDb3VsZCB5b3Ugc2VuZCBhbiB1 cGRhdGVkIHZlcnNpb24/DQoNCkkgaW50ZW5kIHRvIGRvIHNvIGFmdGVyIGJyaW5naW5nIGFu dGlveCB0byAxMDAlLg0KDQpHcmVldGluZ3MsDQpNYXhpbWUuDQo= --------------8v09X0mmvj1s6LeOTCnT0f91 Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc" Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2 ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc /gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4 LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0 k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D =3DOVqp -----END PGP PUBLIC KEY BLOCK----- --------------8v09X0mmvj1s6LeOTCnT0f91-- --------------zgJHLE0uRRZmtVO075t1fQ8n-- --------------6QnkPfuL5ILUpfCso4m5K8P9 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYzCXGwUDAAAAAAAKCRBJ4+4iGRcl7idc AQDyYd2N/m9nZVFDUTNqnqhjgE3wgfLoLrORdds23fg4XAD/dfvUg7nmZM8xLSztCuUAtrJ1DYVI wZ20bdiaFUEvWw0= =LaNJ -----END PGP SIGNATURE----- --------------6QnkPfuL5ILUpfCso4m5K8P9--
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.
Received: (at 57598) by debbugs.gnu.org; 24 Sep 2022 13:03:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 24 09:03:40 2022
Received: from localhost ([127.0.0.1]:42643 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oc4ol-0001KM-Nm
for submit <at> debbugs.gnu.org; Sat, 24 Sep 2022 09:03:40 -0400
Received: from eggs.gnu.org ([209.51.188.92]:55108)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <ludo@HIDDEN>) id 1oc4oj-0001K8-7a
for 57598 <at> debbugs.gnu.org; Sat, 24 Sep 2022 09:03:38 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:48228)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
id 1oc4od-00061E-2N; Sat, 24 Sep 2022 09:03:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To:
From; bh=AxObal4qm450UT8ANxsL5PWP3Hia809U6SipdDNiwh4=; b=BSso5tYjZxv1BuEETzpl
z9h01AsF1wkUr3HJZ/FoQXp2izxJIL4sWia3PnKrFPZBwz9/HTR9TclMhpYOX83yh9lQOSeRTDrVG
vjEelJ3376mWRCyXtsZyiXZP+tXhO9I4P6isMaNAUsmzrMqb93USuYes7tGAITHriLq1RVziEuMwO
jfB+TxqJkrmu+vmEf/dfTU+hcpORGfiSHTMnjLgQ86uaL4sqpF76ubzzw8GOKFNwd0JL41F/XrQKD
3+NVSG/aRMk0mk07H1xYLizkijkSTa7qqO3mpvOA6AKAFBO/kbuTcSLdp4WAfjJklsyQhqEDKAuQZ
I2ZQ0IcRvgFvlQ==;
Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201]:55887
helo=ribbon)
by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
id 1oc4oc-0003q9-E3; Sat, 24 Sep 2022 09:03:30 -0400
From: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@HIDDEN>
To: Maxime Devos <maximedevos@HIDDEN>
Subject: Re: bug#57598: [PATCH] doc: Update contribution guidelines on
patches, etc.
References: <20220905160048.18173-1-maximedevos@HIDDEN>
<20220909123051.15747-1-maximedevos@HIDDEN>
Date: Sat, 24 Sep 2022 15:03:27 +0200
In-Reply-To: <20220909123051.15747-1-maximedevos@HIDDEN> (Maxime Devos's
message of "Fri, 9 Sep 2022 14:30:51 +0200")
Message-ID: <87zgeoapr4.fsf_-_@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 57598
Cc: 57598 <at> debbugs.gnu.org, guix-maintainers@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Hi!
Thanks for this welcome addition! Modulo the cosmetic suggestions
below, I think it=E2=80=99s fine.
Maintainers, if you have something to say on the guidelines, now=E2=80=99s =
the
time!
https://issues.guix.gnu.org/57598
Maxime Devos <maximedevos@HIDDEN> skribis:
> * doc/contributing.texi (Modifying Sources): Replaced with ...
> ("Modifying Sources"): ... this. List more use cases and some principles.
>
> This patch incorporates some text written by Liliana Marie Prikler. The
> structure is based on a proposal by Julien Lepiller. The text has been
> revised based on reviews by David Larsson and blake.
>
> (! remove following text before committing !)
You can write comments below the --- and diffstats. That way, =E2=80=98git=
am=E2=80=99
will ignore them when applying the patch.
> +Guix has tree main ways of modifying the source code of a package, that
> +you as a packager may use. These are patches, snippets and phases.
^
=E2=80=9Cmay use: patches, snippets, and build phases.=E2=80=9D
> +Each one has its strengths and drawbacks. To decide between the three,
s/decide between the three/choose among these/
> +there are a few guiding principles to satisfy simultanuously where
> +possible:
> +
> +@itemize
> +@item
> +In principle, Guix only has free software; when the upstream source
s/In principle, Guix only has free software/Every package in Guix is
free software/g
> +community (i.e., patterns that appear throughout @code{gnu/packages/...})
Normally such parenthetical expressions go between em dashes:
community---i.e., patterns that appear throughout
@file{gnu/packages}---and =E2=80=A6
> +To make things more concrete and to resolve conflicts between the
> +principles, a few cases have been worked out:
> +
> +@subsubsection Removing non-free software
> +Non-free software has to be removed in snippets; the reason is that
> +patches or phases will not work.
You can=E2=80=99t have a colon between the section heading. Instead, you c=
an
write =E2=80=9Ca few cases have been worked out and will be illustrated in =
the
following sections.=E2=80=9D
Section titles should be capitalized.
Leave a blank line after the section title.
(Same comment for the sections that come after.)
Instead of =E2=80=9Cwill not work=E2=80=9D, which is vague, I=E2=80=99d sug=
gest more explicit
wording: =E2=80=9Cwould not be appropriate because they would expose the
offending code.=E2=80=9D
> +For patches, the problem is that a patch removing a non-free file
> +automatically contains the non-free file@footnote{It has been noted that
> +git patches support removing files without including the file in the
> +patch in
> +@url{https://yhetil.org/guix/8b13e899-eb60-490b-a268-639249698c81@@www.f=
astmail.com/}. If
> +it is verified that the @command{patch} utility supports such patches,
> +this method can be used and this policy adjusted appropriately.}, and we
> +do not want anything non-free in Guix even if only in its patches.
I=E2=80=99d drop the footnote, it=E2=80=99s already dense enough.
> +@code{delete-file-recursively}. There are a few benefits for snippets he=
re:
> +
> +When using snippets, the bundled library does not occur in the source
s/snippets here:/snippets here./
s/When using snippets/First, when using snippets/
> +As such, snippets are recommended here.
s/are recommended here/are the recommended way to delete non-free material/
> +@subsubsection Fixing technical issues (compilation errors, test failure=
s, other bugs ...)
In addition to capitalizing, please remove the parenthetical bit.
> +@subsubsection Adding new functionality
> +To add new functionality, a patch is almost always the most convenient
> +choice of the three -- patches are usually multi-line changes, which are
s/three -- patches/three---patches/
That=E2=80=99s all I have to say!
I think what the text says is fine. It=E2=80=99s dense and rather long tho=
ugh,
which means that people may overlook things. OTOH it=E2=80=99s structured =
so
it=E2=80=99s easier to skim through it, and I wouldn=E2=80=99t know what to=
remove.
Could you send an updated version?
Thanks,
Ludo=E2=80=99.
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.
Received: (at 57598) by debbugs.gnu.org; 9 Sep 2022 20:09:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 16:09:38 2022
Received: from localhost ([127.0.0.1]:35600 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oWkJl-0003Oj-I0
for submit <at> debbugs.gnu.org; Fri, 09 Sep 2022 16:09:38 -0400
Received: from mailrelay.tugraz.at ([129.27.2.202]:25110)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <liliana.prikler@HIDDEN>) id 1oWkJe-0003OU-KJ
for 57598 <at> debbugs.gnu.org; Fri, 09 Sep 2022 16:09:36 -0400
Received: from kagayaki.fritz.box (85-127-52-93.dsl.dynamic.surfer.at
[85.127.52.93])
by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4MPRsW2lFpz3wjx;
Fri, 9 Sep 2022 22:09:19 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at;
s=mailrelay; t=1662754159;
bh=1golxioZAdWYz7RxQ0+HVkei2WDNiGf923wwsuDeG10=;
h=Subject:From:To:Date:In-Reply-To:References;
b=se1boxWDEeglFEA/kPQ9t3ETNsicCoXp+wKvry4oqike6AAw/HSYGfzG1ZRhF8alf
1UF3yFwPfnUgOsGmpEYWfE1KL3kzuij3oZ0a4R+ejpCLFMgrsD+6NwxI1BgrbZUi/k
CwzTNCPOKPZ5q+IzY0Y+eS+jbtjzgztG+ODcARfM=
Message-ID: <4e167aa3c88bdbf86b65af118967bc3d1aeb26a4.camel@HIDDEN>
Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc.
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
To: Maxime Devos <maximedevos@HIDDEN>, 57598 <at> debbugs.gnu.org
Date: Fri, 09 Sep 2022 22:09:18 +0200
In-Reply-To: <e9162363-e67b-956e-6346-6a1a6e529abf@HIDDEN>
References: <20220905160048.18173-1-maximedevos@HIDDEN>
<0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
<d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
<44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
<b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN>
<1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN>
<a24e8c5c-a986-3f6f-15a4-03caeb801e6d@HIDDEN>
<b74c40c57dff2a0ac6eee2a7a2124d8ab2d6314e.camel@HIDDEN>
<e9162363-e67b-956e-6346-6a1a6e529abf@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ
X-Spam-Scanner: SpamAssassin 3.003001
X-Spam-Score-relay: -0.4
X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 57598
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Am Freitag, dem 09.09.2022 um 20:44 +0200 schrieb Maxime Devos:
> GNU project encourages reading source code, we put useful
> information in the source code (e.g. records on what non-free parts
> haven't been replaced yet).
You mean bundled parts not unbundled, right? IIUC, there should be no
non-free parts in a free software distribution.
> > You can, but it's still wiser to just keep the snippet short enough
> > so you don't have to.
>
> That's also the case for phases, though? Conciseness is both good
> for phases and snippets.
Intentionally or otherwise, you're talking past me.
> > > I would however very
> > > > much prefer a wording that points people toward this practice
> > > > existing,
> > > > even if they have to go look in the code for examples.
> > > > Alternatively,
> > > > a footnote for the most common case (search-input-file inputs
> > > > "bin/command") ought to suffice for the time being.
> > >
> > > Aside from the typo's and a few rephrasings, I'm done with the
> > > documentation. If someone wants to extend the section with such
> > > information, they can always do so later.
> > I haven't seen a v2 though. Am I correct in assuming that none of
> > the
> > points we discussed in the last few mails are going to be
> > addressed?
>
> I did sent a v2: <https://issues.guix.gnu.org/57598#8>.
> And most were addressed, even if only as me not considering it an
> issue.
Hmm, that was while I was still composing that message.
> > In that case, let me rephrase my criticism: "It passes the
> > guidelines" should not be part of the logical reasoning here.
> > Otherwise, why not have a guideline checklist at the end of each
> > subsection (which would be silly, obviously, but that's the point).
>
> Because, as you note, that's a silly structure, putting the premises
> (= guiding principles) after the conclusions (= worked-out cases) is
> an illogical structure, whereas putting the premises _before_ the
> conclusions is logical
And yet you're putting a premise after a conclusion here.
> > For the record, the exception is the "most convenient" bit you've
> > copied from my patch :)
>
> That guideline actually predates your patch, it's part of the
> original proposal (of which the wording changed later):
>
> >
> https://yhetil.org/guix/c4c0a071-2e03-d4d6-6718-05424d21d146@HIDDEN/
> > Sometimes, there remains more than one acceptable way to accomplish
> > the goal. In that case, choose whatever appears to be most
> > convenient.
Fair enough.
>
> > Note "should" rather than "shall" or "must", meaning that slightly
> > larger tarballs are still acceptable.
> OK. The criterium remains overly tight though -- by that criterium,
> slightly larger tarballs are considered undesirable, even when they
> have useful (and hence, desired) things:
Point taken, but...
> >
> > > * the source contains documentation that could be built and
> > > installed,
> > > but Guix doesn't do so yet. --> should be kept (unless non-
> > > free)
> > > * documentation that isn't meant to be built or installed
> > > (e.g. HACKING, PACKAGERS, ...) --> useful, shouldn't be
> > > removed.
> > > * .gitignore, .github, ... --> nothing wrong with removing those,
> > > but pointless, let's not waste our time with looking for
> > > those
> > > and removing them, even though doing so would make it
> > > smaller.
> > > * source files for platforms the upstream does not support
> > > yet/anymore
> > > (but with some volunteer effort (e.g. bugfixes), it might
> > > become
> > > a supported system again)
> > > --> removing them (e.g. as part of an overly-broad
> > > (delete-file-recursively
> > > "this-dir-has-bundling-albeit-not-all-of-it-is-bundling"))
> > > can be OK-ish, but removing them for 'minimality' is
> > > pointless.
>
> > I see you're nitpicking for the sake of the argument,
>
> I'm not. It's nitpicking for the sake of the four * examples above.
>
> > but none of the
> > examples you provide (safe for the bundling one) add much cost to
> > either packing or unpacking.
>
> Not the point, the point is that having to treat those examples
> seriously is a waste of time and even somewhat harmful (removing
> useful stuff).
>
> > Thus, I'm pretty sure we can ignore them
> > for practical purposes.
>
> As I've explained, this guideline is inconsistent with what is
> actually recommended. Here are some practical purposes:
>
> * minimal dissonance between 'appreciated by policy' and 'appreciated
> by
> reviewers, packagers, users'.
> * not having to review and accept pointless patches to Guix for
> deleting
> .github, .gitignore, uninstalled documentation that were written
> for the sake of minimality
> * not having to (in the sense of: it would be appreciated if you'd do
> that) write such patches
>
> That being said, if you have a better
> > formulation, please do tell.
>
> The four guiding principles.
That's an awful lot to write rather than "the package's source should
be the corresponding source minus the bits we don't like". Ludo’
already commented on the length of my patch (and yes, I'm aware that
both of our patches blow up the section by a factor of like 3 at
minimum), so I don't think you're doing anyone a service here by
expanding something into four guidelines that would take, like, a
simple sentence instead if carefully worded. Let's take the time to
write the shorter letter, shall we?
> By removing the information that 'patches are the most convenient
> choice' (by replacing it with ‘patches are the preferred choice’),
> the logical structure becomes weaker; a part of the explanation on
> the ‘why’ becomes missing.
I'm going to sound like a broken record, but conciseness is key:
"Patches are preferred when adding functionality to a package. They
can more easily be shared with upstreams and are easier to work with
when making multi-line changes. Next item."
> > > > [W]e barely have enough principles to allow the use of a
> > > > plural.
> Your argument is that ‘there aren't a sufficient amount of principles
> to allow the use of a plural’.
Don't put words into my mouth.
> 'Plural' is a concept of English grammar.
The concept of a plural is not unique to English grammar.
> As such, you have written an argument about English grammar.
You're failing to read between the lines and it's getting rather
exhausting.
> You appear to have meant some different argument, but all the
> arguments on ‘are they guiding principles or not’ I've read are based
> on the number of principles or on what 'guiding principle' means,
> which are issues of grammar and vocabulary respectively.
>
> I'm still not seeing how they aren't guiding principles. Maybe you
> have a different meaning of ‘guiding principles’ in mind? Or maybe
> you would like to name them 'guidelines' or 'general recommendations'
> instead.
Call it whatever you want, my point is twofold:
1. By proper counting and simplification, you will have at most two.
2. At least one of those two doesn't feel very "guiding" to me.
Further, I think you're doing a bad job of splitting mandatory and
optional "recommendations" by lumping them together.
> > >
> > > The introduction has a set of guiding principles, from with
> > > concrete cases are built. By adding another principle at the
> > > end, the cases cannot make use of the "use [...] convenient"
> > > principle.
> > >
> > > Additionally, now the user has to look at _two_ places to find
> > > the guiding principles -- at the beginning, and at the end.
> > > Worse, the beginning does not have a cross-reference to the end,
> > > so since the set at the beginning is presented as exhaustive, the
> > > user might not know there is another guiding principle.
> > >
> > > And even if they did read through the whole section (even though
> > > they should only have to read the introduction and the relevant
> > > worked-out case), assuming they read through it in a linear
> > > fashion, due to the new guiding principle that wasn't alluded to
> > > at the beginning, they have to redo their mental model of
> > > "Modifying Sources" as this principle could invalidate things.
> > This shows both a problem with your structure,
>
> I'm not seeing the problem. How does this show a problem?
You're writing three paragraphs to lament how necessary the principle
of "use whatever is convenient" – which mind you I believe should never
be used outside of resolving conflicts between otherwise equally
applicable choices – is to your reasoning.
> > but more importantly, a failure to understand what I meant when I
> > wrote "use whatever is convenient" in my own patch. This principle
> > *can* only work for cases in which there is *no clearly established
> > practice*, thus putting it at the end *after having enumerated all
> > practices* is the logical choice.
> > With your structure, you have to bend it sideways to shoehorn it in
> > with the other principles.
>
> You appear to have meant it as a kind of ‘fallback principle’, in
> which case putting it at the end does indeed make sense.
>
> In my patch, the principle works differently, it is also used for
> explaining already established practices, for the cases where there
> are multiple technically allowed [technique] but still often a single
> _recommended_ [technique]. E.g.:
>
> > Usually, a bug fix comes in the form of a patch copied from
> > upstream or another distribution. In that case, simply adding the
> > patch to the @code{patches} field is the most convenient and
> > usually does not cause any problems; there is no need to rewrite it
> > as a snippet or a phase.
> >
> > If no ready-made patch already exists, then ...]
>
> and
>
> > To add new functionality, a patch is almost always the most
> > convenient choice of the three
>
> .
>
> To go from the principle as used in your patch to the principle as
> used in my patch, perhaps in the process it is bent sideways and
> shoehorned.
> But after all the bending and shoehorning, it seems to fit well now
> in the beginning (and not well at all the end), so I'm not seeing any
> problems here.
And here I must disagree with the nature of your patch, because
elevating this into a guiding principle makes what feels most
convenient to you (or any other writer at the time of editing the
manual) most convenient to everyone. My patch allows for deliberation
by both the packager and reviewer, which might lead to some conflicts
of opinion, but unless either solution can be shown clearly superior by
appeal to *another reason*, which mind you is lacking here, both
solutions should be accepted.
>
> > in a way that might
> > inhibit natural information flow.
>
> I'm not seeing it. As I've explained previously, putting the
> premises (= guiding principles) before the conclusions (= worked out
> cases / solutions) is a logical (hence, natural) information flow,
> and introducing them on-the-way or implicitly is ad-hoc (unnatural).
> > I think we might be disagreeing about what constitutes "solving the
> > problem" here. Correct me if I'm wrong, but to me it seems any
> > scenario that is not covered by whatever patch is applied counts as
> > "not having solved the problem".
>
> It doesn't -- I consider the Shepherd problem to be solved by my
> patch (albeit rather weakly, see later), and the wider problem of
> unclear guidelines and policy on snippet/phase/patch to be, perhaps
> not really solved, but still much improved (this time not weakly).
>
> > I personally find this line of reasoning questionable, as there are
> > perfectly valid reasons why multiple tools could apply.
>
> See previous paragraph.
> > Take the problem of embedding a store path. You could for instance
> > replace all occurences of "sh" with /gnu/store/.../bin/sh, or you
> > could first replace them in a patch with "@sh@" and then replace
> > that with /gnu/store/.../bin/sh. Of course, you rarely have to do
> > the latter and the former is simpler, hence why you will often see
> > the former, but that doesn't mean the latter is invalid.
>
> It's contrary to 'It preferably should also work on non-Guix systems’
> --
> not invalid, but still usually (*) against (proposed) policy because
> a direct substitute* is at the same time more convenient and follows
> all the the principles.
>
> (*) sometimes, in case of shell scripts, a substitute* is fragile
> (substituting too much), in which case a "sh" -> "@sh@" becomes more
> convenient and hence the violation of the 'non-Guix system' rules
> becomes acceptable.
Fair enough, guess I'll have to update configure.ac in the same patch
to honour the guiding principles.
> > > > >
> > > In both patches, if the user only reads the
> > > introduction and conclusion (if any) and doesn't read the actual
> > > (relevant examples)/(explanation of patches, snippets, phases),
> > > then that's their problem.
> > I do think a table in the middle of the section is hard to ignore,
>
> I think so too, hence my previous response.
>
> > but suppose for the sake of argument that they do, [...]
>
> Given this response, I assume I've misinterpreted what you meant with
> ‘not having looked at the worked-out cases yet’.
I think you understood it elsewhere, see the fallback guiding
principle.
> > No particular order is problematic,
>
> I'm not seeing why.
Why have a structure, when you won't have a structure? Sounds a little
counterintuitive, does it not?
> but more importantly if a
> > technology appears more than once (guaranteed by the pigeonhole
> > principle), then either its properties get repeated (not good for
> > length) or scattered (not good for the flow you want). Again, a
> > structural problem.
>
> That's equally applies to your patch too, though? (Switching
> "technology" with "problem".)
Not really, since most problems that are to be uniquely solved with a
given tool can be uniquely named under that tool. I do expand a little
on using patches and phases in combination for a more complicated job,
but that use case is notably missing from your patch. I also repeat
shared characteristics of patches and snippets, which I could condense
to save some space, but in comparison to your patch, space is no issue.
> Also, I've re-read my patch, and I didn't find any repeated
> properties or scattering, except for a single property (patches are
> upstreamable):
>
> > First, when the fix is not Guix-specific, upstreaming the fix is
> > strongly desired to avoid the additional maintenance cost to Guix.
> > [...]
> > As such, patches are preferred. However, as with bug
> > fixes, upstreaming the new functionality is desired.
>
> As such, I'm not following your point here.
The trend of you not seeing continues. Look at your first two
subsubsections (both v1 and v2).
>
> > Point taken, but imho cross-references are nice for those who just
> > learned "okay, I now know I need to solve my technical problem with
> > a phase, how do I do that?"
>
> They are indeed. But I'm not following what you mean with "But"
> here. I didn't claim anything about cross-references there?
>
> Do you want me to add a few cross-references (for 'patch', 'snippet'
> and 'phases')?
I don't think you have a useful location to put them though, owing once
again to structure :)
>
> > I do get the impression that this patch simply codifies what you
> > feel is right based on the shepherd situation
>
> True, except for the 'simply'
Okay, I'll correct myself: This patch complicatedly codifies what you
feel is right based on the shepherd situation.
Jokes aside,
> I also considered several other situations (Removing bundled
> libraries, Removing non-free software, Adding new functionality). I
> do not see the problem with this -- the proposed policy was
> considered workable even if some would like it to be a little bit
> different, and if others feel strongly about they could, I don't,
> maybe set up a vote system or such.
I think this is not the place for the kind of democracy where you put
everything barely the half of people can agree is the worst tradeoff
into "law". Even worse if we had an anonymous online vote, because
those aren't susceptible to manipulation at all.
I think we should rather exercise caution and document what if not the
entire community then at least the reviewers can agree on.
> > rather than thinking about the general case,
>
> See: several other cases that should cover most situations
> encountered in practice, and for the parts of the general case that
> aren't worked-out yet, there are the guiding principles.
"guiding" principle"s"
> > which is why my patch makes weaker statements here. If
> > this issue could have been avoided with a #:make-flag, we would
> > have used that.
> >
> > More importantly, I fail to see the superiority of your patch here
> > > IIUC neither patch offers a unique solution to the shepherd
> > thing, so
> > the room for debate remains
>
> In my patch, multiple options remain, but there is no real room for
> debate. More concretely:
>
> > When there is more than one way to do something, choose whichever
> > method is the simplest. Sometimes this is subjective, which is
> > also fine.
> > What matters is that you use techniques that are common within the
> > community (i.e., patterns that appear throughout
> > @code{gnu/packages/...})
> > and are thus clearly legible for reviewers.
>
> it is considered subjective, having multiple options if fine! To
> correct a packaging following the other option (to help with
> following the policies), you don't have to debate on what's the
> proper option to get a fix in, as both are considered acceptable. In
> many cases, no need for debate, just pick one and move on. (Also the
> case for your patch IIUC.)
I do think elevating this into a guiding principle somewhat undermines
what you're stating here though.
> Things are also phrased reconciliatory, e;g.:
>
> > To make things more concrete and to resolve conflicts between the
> > principles, a few cases have been worked out:
>
> However, in your patch, there is more opportunity for conflicts.
> E.g.:
>
> > Each one has its strengths and drawbacks, along with intended
> > andhistorically derived use cases.
>
> By this line, arguments like 'X was historically the intended purpose
> of Y, using Y for Z is incorrect' become reasonable, which makes
> disagreements more difficult to resolve (as you know need to consult
> history and because history is fixed, so no improvements would be
> possible anymore in areas where there is a historically intended use
> case).
The intended and historically derived use cases are those that ought to
be explicitly named in the following. If it's not documented, there is
no historic precedent.
> > > > In particular, for review purposes, mine should be easier to
> > > > work with. For instance, the reviewer sees a hash embedded in
> > > > a snippet, sees in the snippet entry that you shouldn't do
> > > > that, and can thus say "nope, don't do a snippet here".
>
> That is also the case for problem->solution? A "sh" -> #$(file-
> append bash-minimal "/bin/sh") substitution can be recognised on
> sight as not possibly being anything else than a technical fix, and
> then the subsubsection on technical fixes mentions that those must be
> done in phases.
>
> Or, another explanation: reviewers usually have seen a lot of more
> packages than a new packager. Because of that, and because they have
> familiarised theirselves with policy, they have over time
> automatically built a mental 'reverse index' of solutions->problems.
I wouldn't put too much value in this experience. It can also blind
you to the point of producing old-style inputs, for example.
> >
> > > I think we should optimise for packagers before reviewers
> > Code is more often read than written, so optimising for the reader
> > is optimizing for the packager as well.
>
> While all reviewers are readers, not all readers are reviewers, and
> reviewing usually happens only once, maybe twice per patch.
That's not a problem, though? You can take my guidelines, apply it to
any random package in the Guix source and see whether things (still)
fit. That's more troublesome with the problem->solution style. In
other words, that the solution passes is apparent from the written form
rather than requiring the process of writing it.
> > > > Regardless of which patch we pick, it should not mandate a
> > > > particular solution in potentially contentious cases,
> > >
> > > Actually the whole point was to mandate a particular solution for
> > > the
> > > contentious cases, see Shepherd.
> > But I disagree.
> >
> > Memes aside, please refrain from the "I'm right, do this" style
> > (which is another problem with the "problem-centric" approach),
>
> Is this referring to the style of the documentation patch? If so: it
> does explain why the "do this" is right, so I don't see the problem.
> Do you have a particular point of the documentation in mind you
> consider wrong (*)?
>
> (*) points I know of:
> * keep lists / remove lists (for the footnote about not-yet-policy on
> removing things in patches)
> * the guiding principles aren't guiding principles
For one, you seriously erred on the test cases thing. I also wonder if
we're drawing the wrong conclusions for Makefiles from the Shepherd
incident. Historically, patching build files in a phase has been very
fine.
> > but rather focus on writing a patch that makes reviewers not
> > discard a patch due to formalities.
>
> I think the patch (v1 and v2) satisfies that.
I'm getting slightly different vibes, but sure.
Cheers
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.Received: (at 57598) by debbugs.gnu.org; 9 Sep 2022 18:44:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 14:44:27 2022 Received: from localhost ([127.0.0.1]:35456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oWizJ-0007O1-GS for submit <at> debbugs.gnu.org; Fri, 09 Sep 2022 14:44:27 -0400 Received: from andre.telenet-ops.be ([195.130.132.53]:58758) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <maximedevos@HIDDEN>) id 1oWizF-0007Nr-EG for 57598 <at> debbugs.gnu.org; Fri, 09 Sep 2022 14:44:24 -0400 Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16] ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]) by andre.telenet-ops.be with bizsmtp id HukH2800D20ykKC01ukHhx; Fri, 09 Sep 2022 20:44:18 +0200 Message-ID: <e9162363-e67b-956e-6346-6a1a6e529abf@HIDDEN> Date: Fri, 9 Sep 2022 20:44:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Content-Language: en-US To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 57598 <at> debbugs.gnu.org References: <20220905160048.18173-1-maximedevos@HIDDEN> <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN> <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN> <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN> <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN> <1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN> <a24e8c5c-a986-3f6f-15a4-03caeb801e6d@HIDDEN> <b74c40c57dff2a0ac6eee2a7a2124d8ab2d6314e.camel@HIDDEN> From: Maxime Devos <maximedevos@HIDDEN> Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc. In-Reply-To: <b74c40c57dff2a0ac6eee2a7a2124d8ab2d6314e.camel@HIDDEN> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------b304Y9bejnymBhUvwnTF0ap0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1662749058; bh=0aADSMKUBU0fzd5tekJnVsAmdaUV9xOfGxfaDG9HTMk=; h=Date:To:References:From:Subject:In-Reply-To; b=TvH5hWTI4Y0BceTANeve4Q2BypLqxRgPXGP4T/ITvlQPJPDslCbl6lw2P8VwYGAgp ogX5MGtvVBwARKhVnWxJ1tsjy04teNje65/oVRJ609OW2XY8eXjj8OlKSeSMvUPqk9 VMKsXnwtKYhSe6dmgiuh2bXzGpJYVheq+G6VQU5E5WIM9YVr38tZHxQvSNAnLRpkOj waJZNWIe8/9f3TjHiZzNEbIYB518W9mSpQ2uYPwyJPblG8aXFuZfo9NlMzH5NMBzlg FL4T9r0BjczBp3B54/TrZ3eFHBkDN1rOU1blOEocoihnbb5Uh/1m/Jn1sZcAkaRGWj iJXuzsuWpLOyg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 57598 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------b304Y9bejnymBhUvwnTF0ap0 Content-Type: multipart/mixed; boundary="------------A60oN2LySqwFEM12Dd7BpjjC"; protected-headers="v1" From: Maxime Devos <maximedevos@HIDDEN> To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 57598 <at> debbugs.gnu.org Message-ID: <e9162363-e67b-956e-6346-6a1a6e529abf@HIDDEN> Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc. References: <20220905160048.18173-1-maximedevos@HIDDEN> <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN> <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN> <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN> <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN> <1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN> <a24e8c5c-a986-3f6f-15a4-03caeb801e6d@HIDDEN> <b74c40c57dff2a0ac6eee2a7a2124d8ab2d6314e.camel@HIDDEN> In-Reply-To: <b74c40c57dff2a0ac6eee2a7a2124d8ab2d6314e.camel@HIDDEN> --------------A60oN2LySqwFEM12Dd7BpjjC Content-Type: multipart/mixed; boundary="------------RneJSr4rW60YFuWvSkivYcO6" --------------RneJSr4rW60YFuWvSkivYcO6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQoNCk9uIDA5LTA5LTIwMjIgMTU6MzIsIExpbGlhbmEgTWFyaWUgUHJpa2xlciB3cm90ZToN Cj4+IEFsc28sIHRoaXMgaXMgdGhlIHBhY2thZ2Ugc291cmNlIGZpZWxkLCBub3QgdGhlIGRl c2NyaXB0aW9uLCBJIGRvbid0DQo+PiBzZWUgaG93IHRoZSAiaGVscHMgc29mdHdhcmUgc3Rh bmQgb24gaXRzIG93biBtZXJpdHMiIGFwcGxpZXMgdG8NCj4+IHNuaXBwZXRzIG9mIHRoZSBw YWNrYWdlIHNvdXJjZS4NCj4gUG9pbnQgdGFrZW4sIGJ1dCBpbWhvIGl0IHN0aWxsIG1ha2Vz IHNlbnNlIHRvIHByZWZlciBrZWVwIGxpc3RzIG92ZXINCj4gcmVtb3ZlIGxpc3RzLiAgVGhl IEdOVSBwcm9qZWN0IGVuY291cmFnZXMgcGVvcGxlIHRvIHJlYWQgdGhlIHNvdXJjZXMNCj4g YWZ0ZXIgYWxsLg0KDQpJIGRvIG5vdCBzZWUgaG93IHRoZSBmb3JtZXIgZm9sbG93cyBmcm9t IHRoZSBsYXR0ZXIsIEkgd291bGQgZXhwZWN0IHRoZSANCm9wcG9zaXRlLiAgR05VIHByb2pl Y3QgZW5jb3VyYWdlcyByZWFkaW5nIHNvdXJjZSBjb2RlLCB3ZSBwdXQgdXNlZnVsIA0KaW5m b3JtYXRpb24gaW4gdGhlIHNvdXJjZSBjb2RlIChlLmcuIHJlY29yZHMgb24gd2hhdCBub24t ZnJlZSBwYXJ0cw0KaGF2ZW4ndCBiZWVuIHJlcGxhY2VkIHlldCkuDQoNCj4+Pj4NCj4+Pj4+ IFRoZXJlIHN0aWxsIGlzIHRoZSBkaWZmZXJlbmNlIHRoYXQgcGhhc2VzIGFyZSBjbGVhcmx5 IGRlbGltaXRlZA0KPj4+Pj4gd2hpbGUgc25pcHBldHMgYXJlIGEgYmxvY2sgb2YgY29kZSB0 aGF0IHNob3VsZG4ndCBnZXQgdG9vDQo+Pj4+PiBsYXJnZS4NCj4+Pj4gU25pcHBldHMgYXJl IGRlbGltaXRlZCBjbGVhcmx5IGFzIHdlbGwsIHRob3VnaCwgd2l0aCB0aGUNCj4+Pj4gJ3Nu aXBwZXQnIGZpZWxkPw0KPj4+PiBBbmQgdGhlIGxpbWl0YXRpb25zIG9mIHNuaXBwZXQgbGVu Z3RoIGFuZCBwaGFzZXMgbGVuZ3RoIGFyZSB0aGUNCj4+Pj4gc2FtZcKgLS0gbm8gbGltaXRz LCB0aG91Z2ggY29uY2lzZW5lc3MgaXMgYXBwcmVjaWF0ZSBhcyBhbHdheXMuDQo+Pj4gVHJ1 ZSwgYnV0IHBoYXNlcyBjYW4gYmUgbWFkZSB0byBkbyBqdXN0IG9uZSB0aGluZywgd2hlcmVh cyBzbmlwcGV0cw0KPj4+IGhhdmUgdG8gZml4IGV2ZXJ5dGhpbmcgdGhhdCdzIHdyb25nIGlu IG1vcmUgb3IgbGVzcyBvbmUgKGJlZ2luDQo+Pj4gLi4uKS4NCj4+PiBUaGlzIGlzIGEgbm90 aWNhYmxlIGRpc3RpbmN0aW9uLj4NCj4+DQo+PiBZb3UgY2FuIGRvIHRoYXQgaW4gc25pcHBl dHMgdG9vLCB3aXRoIGNvbW1lbnRzOg0KPj4NCj4+IChzbmlwcGV0DQo+PiAgwqDCoCAjfihi ZWdpbg0KPj4gIMKgwqDCoMKgwqDCoCA7OyBEbyB0aGUgZm9vIHRoaW5nDQo+PiAgwqDCoMKg wqDCoMKgIChmb28pDQo+PiAgwqDCoMKgwqDCoMKgIChmb28tMiBbLi4uXSkNCj4+ICDCoMKg wqDCoMKgwqAgWy4uLl0NCj4+ICDCoMKgwqDCoMKgwqAgOzsgRG8gdGhlIGJhciB0aGluZw0K Pj4gIMKgwqDCoMKgwqDCoCAoYmFyKQ0KPj4gIMKgwqDCoMKgwqDCoCAoYmFyLTIgWy4uLl0p DQo+PiAgwqDCoMKgwqDCoMKgIFsuLi5dKSkNCj4gWW91IGNhbiwgYnV0IGl0J3Mgc3RpbGwg d2lzZXIgdG8ganVzdCBrZWVwIHRoZSBzbmlwcGV0IHNob3J0IGVub3VnaCBzbw0KPiB5b3Ug ZG9uJ3QgaGF2ZSB0by4NCg0KVGhhdCdzIGFsc28gdGhlIGNhc2UgZm9yIHBoYXNlcywgdGhv dWdoPyAgQ29uY2lzZW5lc3MgaXMgYm90aCBnb29kIGZvciANCnBoYXNlcyBhbmQgc25pcHBl dHMuDQo+PiAgwqAgSSB3b3VsZCBob3dldmVyIHZlcnkNCj4+PiBtdWNoIHByZWZlciBhIHdv cmRpbmcgdGhhdCBwb2ludHMgcGVvcGxlIHRvd2FyZCB0aGlzIHByYWN0aWNlDQo+Pj4gZXhp c3RpbmcsDQo+Pj4gZXZlbiBpZiB0aGV5IGhhdmUgdG8gZ28gbG9vayBpbiB0aGUgY29kZSBm b3IgZXhhbXBsZXMuDQo+Pj4gQWx0ZXJuYXRpdmVseSwNCj4+PiBhIGZvb3Rub3RlIGZvciB0 aGUgbW9zdCBjb21tb24gY2FzZSAoc2VhcmNoLWlucHV0LWZpbGUgaW5wdXRzDQo+Pj4gImJp bi9jb21tYW5kIikgb3VnaHQgdG8gc3VmZmljZSBmb3IgdGhlIHRpbWUgYmVpbmcuDQo+Pg0K Pj4gQXNpZGUgZnJvbSB0aGUgdHlwbydzIGFuZCBhIGZldyByZXBocmFzaW5ncywgSSdtIGRv bmUgd2l0aCB0aGUNCj4+IGRvY3VtZW50YXRpb24uwqAgSWYgc29tZW9uZSB3YW50cyB0byBl eHRlbmQgdGhlIHNlY3Rpb24gd2l0aCBzdWNoDQo+PiBpbmZvcm1hdGlvbiwgdGhleSBjYW4g YWx3YXlzIGRvIHNvIGxhdGVyLg0KPiBJIGhhdmVuJ3Qgc2VlbiBhIHYyIHRob3VnaC4gIEFt IEkgY29ycmVjdCBpbiBhc3N1bWluZyB0aGF0IG5vbmUgb2YgdGhlDQo+IHBvaW50cyB3ZSBk aXNjdXNzZWQgaW4gdGhlIGxhc3QgZmV3IG1haWxzIGFyZSBnb2luZyB0byBiZSBhZGRyZXNz ZWQ/DQoNCkkgZGlkIHNlbnQgYSB2MjogPGh0dHBzOi8vaXNzdWVzLmd1aXguZ251Lm9yZy81 NzU5OCM4Pi4NCkFuZCBtb3N0IHdlcmUgYWRkcmVzc2VkLCBldmVuIGlmIG9ubHkgYXMgbWUg bm90IGNvbnNpZGVyaW5nIGl0IGFuIGlzc3VlLg0KDQo+Pj4NCj4+PiBJTUhPLCBJIHRoaW5r IGEgcmVhZGVyIHdobyByZW1lbWJlcnMgdGhlIGd1aWRpbmcgcHJpbmNpcGxlcyBzaG91bGQN Cj4+PiBzZWUgdGhhdCBpdCBhcHBsaWVzLg0KPj4NCj4+IExpa2VseS4gQnV0IHJlbW92aW5n IHRoZSBleHBsaWNpdCBtZW50aW9uIG9mIHRoZSBndWlkaW5nIHByaW5jaXBsZQ0KPj4gc3Rp bGwgbWFrZXMgdGhlIGxvZ2ljYWwgcmVhc29uaW5nIGluY29tcGxldGUsIHJlbWVtYmVyaW5n IGhhcyBub3RoaW5nDQo+PiB0byBkbyB3aXRoIGl0LsKgIEFzIEkndmUgd3JpdHRlbiBwcmV2 aW91c2x5OiDigJhUaGlzIGhhcyBub3RoaW5nIGRvIGRvDQo+PiB3aXRoIFsuLi5dIGFuZCBy ZW1lbWJlcmluZywgYnV0IHJhdGhlciB3aXRoIFsuLi5d4oCZLg0KPiBJbiB0aGF0IGNhc2Us IGxldCBtZSByZXBocmFzZSBteSBjcml0aWNpc206ICJJdCBwYXNzZXMgdGhlIGd1aWRlbGlu ZXMiDQo+IHNob3VsZCBub3QgYmUgcGFydCBvZiB0aGUgbG9naWNhbCByZWFzb25pbmcgaGVy ZS4gIE90aGVyd2lzZSwgd2h5IG5vdA0KPiBoYXZlIGEgZ3VpZGVsaW5lIGNoZWNrbGlzdCBh dCB0aGUgZW5kIG9mIGVhY2ggc3Vic2VjdGlvbiAod2hpY2ggd291bGQNCj4gYmUgc2lsbHks IG9idmlvdXNseSwgYnV0IHRoYXQncyB0aGUgcG9pbnQpLg0KDQpCZWNhdXNlLCBhcyB5b3Ug bm90ZSwgdGhhdCdzIGEgc2lsbHkgc3RydWN0dXJlLCBwdXR0aW5nIHRoZSBwcmVtaXNlcyAo PSANCmd1aWRpbmcgcHJpbmNpcGxlcykgYWZ0ZXIgdGhlIGNvbmNsdXNpb25zICg9IHdvcmtl ZC1vdXQgY2FzZXMpIGlzIGFuIA0KaWxsb2dpY2FsIHN0cnVjdHVyZSwgd2hlcmVhcyBwdXR0 aW5nIHRoZSBwcmVtaXNlcyBfYmVmb3JlXyB0aGUgDQpjb25jbHVzaW9ucyBpcyBsb2dpY2Fs DQoNCj4+Pj4NCj4+PiBBbHNvLCB5b3VyIGd1aWRpbmcgcHJpbmNpcGxlcyBhcmUgKHdpdGgg b25lIGV4Y2VwdGlvbikgcmVhbGx5IGp1c3QNCj4+PiBpbnZhcmlhbnRzIHRoYXQgb3VnaHQg dG8gaG9sZCBmb3IgdGhlIHNvdXJjZSBmaWVsZCBvZiBhIHBhY2thZ2UuDQo+Pg0KPj4gSSBk b24ndCBrbm93IGFib3V0IHRoZSBleGNlcHRpb25zIChJIGhhdmVuJ3QgY291bnRlZCB0aGVt KSwgYnV0IHllcywNCj4+IGluZGVlZC7CoCBJIGRvIG5vdCBzZWUgdGhlIHByb2JsZW0gb2Yg dGhpcy4NCj4gRm9yIHRoZSByZWNvcmQsIHRoZSBleGNlcHRpb24gaXMgdGhlICJtb3N0IGNv bnZlbmllbnQiIGJpdCB5b3UndmUNCj4gY29waWVkIGZyb20gbXkgcGF0Y2ggOikNCg0KVGhh dCBndWlkZWxpbmUgYWN0dWFsbHkgcHJlZGF0ZXMgeW91ciBwYXRjaCwgaXQncyBwYXJ0IG9m IHRoZSBvcmlnaW5hbCANCnByb3Bvc2FsIChvZiB3aGljaCB0aGUgd29yZGluZyBjaGFuZ2Vk IGxhdGVyKToNCg0KID4gaHR0cHM6Ly95aGV0aWwub3JnL2d1aXgvYzRjMGEwNzEtMmUwMy1k NGQ2LTY3MTgtMDU0MjRkMjFkMTQ2QHRlbGVuZXQuYmUvDQo+IFNvbWV0aW1lcywgdGhlcmUg cmVtYWlucyBtb3JlIHRoYW4gb25lIGFjY2VwdGFibGUgd2F5IHRvIGFjY29tcGxpc2ggdGhl IA0KPiBnb2FsLiBJbiB0aGF0IGNhc2UsIGNob29zZSB3aGF0ZXZlciBhcHBlYXJzIHRvIGJl IG1vc3QgY29udmVuaWVudC4NCg0KDQoNCg0KPj4+IEFzIHN1Y2gsIEkgdGhpbmsgaXQgd291 bGQgYmUgZWFzaWVyIHRvIHN0YXRlICJBIHBhY2thZ2UncyBzb3VyY2UNCj4+PiBzaG91bGQN Cj4+PiBiZSB0aGUgc21hbGxlc3QgY29ycmVzcG9uZGluZyBzb3VyY2UgaW4gdGVybXMgb2Yg dW5jb21wcmVzc2VkIGZpbGUNCj4+PiBzaXplLsKgIFRoaXMgY29ycmVzcG9uZGluZyBzb3Vy Y2UgbXVzdCBjb25zaXN0IG9ubHkgb2YgZnJlZSBzb2Z0d2FyZQ0KPj4+IChub3RlIEZyZWUg U29mdHdhcmUpIGFuZCBzaG91bGQgYnVpbGQgb24gYWxsIHBsYXRmb3JtcyBzdXBwb3J0ZWQg YnkNCj4+PiB1cHN0cmVhbS4iwqAgTm90ZSBob3cgc21hbGxlc3QgbmF0dXJhbGx5IGltcGxp ZXMgdW5idW5kbGluZyBidW5kbGVkDQo+Pj4gc291cmNlcy4NCj4+DQo+PiBUaGlzIGNyaXRl cml1bSBvbiBvdmVybHkgc21hbGwgc291cmNlcy7CoCBPZnRlbiwgYSBwYWNrYWdlJ3Mgc291 cmNlDQo+PiBjb250YWlucyB0aGluZ3MgdGhhdCBpcyBub3QgdXNlZCBmb3IgdGhlIGJ1aWxk IG9yIG91dHB1dHMgYW5kIGhlbmNlDQo+PiBpcyBub3QgcGFydCBvZiB0aGUgY29ycmVzcG9u ZGluZyBzb3VyY2UuwqAgRXhhbXBsZXM6DQo+IE5vdGUgInNob3VsZCIgcmF0aGVyIHRoYW4g InNoYWxsIiBvciAibXVzdCIsIG1lYW5pbmcgdGhhdCBzbGlnaHRseQ0KPiBsYXJnZXIgdGFy YmFsbHMgYXJlIHN0aWxsIGFjY2VwdGFibGUuDQpPSy4gIFRoZSBjcml0ZXJpdW0gcmVtYWlu cyBvdmVybHkgdGlnaHQgdGhvdWdoIC0tIGJ5IHRoYXQgY3JpdGVyaXVtLCANCnNsaWdodGx5 IGxhcmdlciB0YXJiYWxscyBhcmUgY29uc2lkZXJlZCB1bmRlc2lyYWJsZSwgZXZlbiB3aGVu IHRoZXkgaGF2ZSANCnVzZWZ1bCAoYW5kIGhlbmNlLCBkZXNpcmVkKSB0aGluZ3M6DQoNCj4g DQo+PiAqIHRoZSBzb3VyY2UgY29udGFpbnMgZG9jdW1lbnRhdGlvbiB0aGF0IGNvdWxkIGJl IGJ1aWx0IGFuZA0KPj4gaW5zdGFsbGVkLA0KPj4gIMKgwqAgYnV0IEd1aXggZG9lc24ndCBk byBzbyB5ZXQuwqAgLS0+IHNob3VsZCBiZSBrZXB0ICh1bmxlc3Mgbm9uLWZyZWUpDQo+PiAq IGRvY3VtZW50YXRpb24gdGhhdCBpc24ndCBtZWFudCB0byBiZSBidWlsdCBvciBpbnN0YWxs ZWQNCj4+ICDCoMKgIChlLmcuIEhBQ0tJTkcsIFBBQ0tBR0VSUywgLi4uKSAtLT4gdXNlZnVs LCBzaG91bGRuJ3QgYmUgcmVtb3ZlZC4NCj4+ICogLmdpdGlnbm9yZSwgLmdpdGh1YiwgLi4u IC0tPiBub3RoaW5nIHdyb25nIHdpdGggcmVtb3ZpbmcgdGhvc2UsDQo+PiAgwqDCoCBidXQg cG9pbnRsZXNzLCBsZXQncyBub3Qgd2FzdGUgb3VyIHRpbWUgd2l0aCBsb29raW5nIGZvciB0 aG9zZQ0KPj4gIMKgwqAgYW5kIHJlbW92aW5nIHRoZW0sIGV2ZW4gdGhvdWdoIGRvaW5nIHNv IHdvdWxkIG1ha2UgaXQgc21hbGxlci4NCj4+ICogc291cmNlIGZpbGVzIGZvciBwbGF0Zm9y bXMgdGhlIHVwc3RyZWFtIGRvZXMgbm90IHN1cHBvcnQNCj4+IHlldC9hbnltb3JlDQo+PiAg wqDCoCAoYnV0IHdpdGggc29tZSB2b2x1bnRlZXIgZWZmb3J0IChlLmcuIGJ1Z2ZpeGVzKSwg aXQgbWlnaHQgYmVjb21lDQo+PiAgwqDCoCBhIHN1cHBvcnRlZCBzeXN0ZW0gYWdhaW4pDQo+ PiAgwqDCoCAtLT4gcmVtb3ZpbmcgdGhlbSAoZS5nLiBhcyBwYXJ0IG9mIGFuIG92ZXJseS1i cm9hZA0KPj4gKGRlbGV0ZS1maWxlLXJlY3Vyc2l2ZWx5DQo+PiAidGhpcy1kaXItaGFzLWJ1 bmRsaW5nLWFsYmVpdC1ub3QtYWxsLW9mLWl0LWlzLWJ1bmRsaW5nIikpDQo+PiAgwqDCoMKg wqDCoMKgIGNhbiBiZSBPSy1pc2gsIGJ1dCByZW1vdmluZyB0aGVtIGZvciAnbWluaW1hbGl0 eScgaXMNCj4+IHBvaW50bGVzcy4NCg0KPiBJIHNlZSB5b3UncmUgbml0cGlja2luZyBmb3Ig dGhlIHNha2Ugb2YgdGhlIGFyZ3VtZW50LA0KDQpJJ20gbm90LiAgSXQncyBuaXRwaWNraW5n IGZvciB0aGUgc2FrZSBvZiB0aGUgZm91ciAqIGV4YW1wbGVzIGFib3ZlLg0KDQo+IGJ1dCBu b25lIG9mIHRoZQ0KPiBleGFtcGxlcyB5b3UgcHJvdmlkZSAoc2FmZSBmb3IgdGhlIGJ1bmRs aW5nIG9uZSkgYWRkIG11Y2ggY29zdCB0bw0KPiBlaXRoZXIgcGFja2luZyBvciB1bnBhY2tp bmcuDQoNCk5vdCB0aGUgcG9pbnQsIHRoZSBwb2ludCBpcyB0aGF0IGhhdmluZyB0byB0cmVh dCB0aG9zZSBleGFtcGxlcyANCnNlcmlvdXNseSAgaXMgYSB3YXN0ZSBvZiB0aW1lIGFuZCBl dmVuIHNvbWV3aGF0IGhhcm1mdWwgKHJlbW92aW5nIHVzZWZ1bCANCnN0dWZmKS4NCg0KPiBU aHVzLCBJJ20gcHJldHR5IHN1cmUgd2UgY2FuIGlnbm9yZSB0aGVtDQo+IGZvciBwcmFjdGlj YWwgcHVycG9zZXMuDQoNCkFzIEkndmUgZXhwbGFpbmVkLCB0aGlzIGd1aWRlbGluZSBpcyBp bmNvbnNpc3RlbnQgd2l0aCB3aGF0IGlzIGFjdHVhbGx5IA0KcmVjb21tZW5kZWQuICBIZXJl IGFyZSBzb21lIHByYWN0aWNhbCBwdXJwb3NlczoNCg0KKiBtaW5pbWFsIGRpc3NvbmFuY2Ug YmV0d2VlbiAnYXBwcmVjaWF0ZWQgYnkgcG9saWN5JyBhbmQgJ2FwcHJlY2lhdGVkIGJ5DQog ICByZXZpZXdlcnMsIHBhY2thZ2VycywgdXNlcnMnLg0KKiBub3QgaGF2aW5nIHRvIHJldmll dyBhbmQgYWNjZXB0IHBvaW50bGVzcyBwYXRjaGVzIHRvIEd1aXggZm9yIGRlbGV0aW5nDQog ICAuZ2l0aHViLCAuZ2l0aWdub3JlLCB1bmluc3RhbGxlZCBkb2N1bWVudGF0aW9uIHRoYXQg d2VyZSB3cml0dGVuDQogICBmb3IgdGhlIHNha2Ugb2YgbWluaW1hbGl0eQ0KKiBub3QgaGF2 aW5nIHRvIChpbiB0aGUgc2Vuc2Ugb2Y6IGl0IHdvdWxkIGJlIGFwcHJlY2lhdGVkIGlmIHlv dSdkIGRvDQogICB0aGF0KSB3cml0ZSBzdWNoIHBhdGNoZXMNCg0KICAgVGhhdCBiZWluZyBz YWlkLCBpZiB5b3UgaGF2ZSBhIGJldHRlcg0KPiBmb3JtdWxhdGlvbiwgcGxlYXNlIGRvIHRl bGwuDQoNClRoZSBmb3VyIGd1aWRpbmcgcHJpbmNpcGxlcy4NCg0KPiANCj4+DQo+Pj4+PiBJ IHN0aWxsIGZpbmQgdGhpcyB3b3JkaW5nIHZlcnkgY29uZnVzaW5nLiBQZXJoYXBzICJUbyBh ZGQgbmV3DQo+Pj4+PiBmdW5jdGlvbmFsaXR5LCBhIHBhdGNoIGlzIGFsbW9zdCBhbHdheXMg dGhlIGJlc3QgY2hvaWNlLiBGb3INCj4+Pj4+IG9uZSwNCj4+Pj4+IGl0IGlzIGxpa2VseSB0 aGF0IHRoZSBuZXcgZnVuY3Rpb25hbGl0eSByZXF1aXJlcyBjaGFuZ2luZw0KPj4+Pj4gbXVs dGlwbGUNCj4+Pj4+IGxpbmVzIG9mIHNvdXJjZSBjb2RlLCB3aGljaCBpcyBtb3JlIGNvbnZl bmllbnQgdG8gZG8gd2l0aCBhDQo+Pj4+PiBwYXRjaA0KPj4+Pj4gdGhhbiB3aXRoIGEgc25p cHBldC4gRnVydGhlciwgcGF0Y2hlcyBjYW4gYmUgdGFrZW4gZnJvbSBhbmQNCj4+Pj4+IHN1 Ym1pdHRlZCB0byB1cHN0cmVhbXMgbW9yZSBlYXNpbHkuIElmIHlvdXIgcGF0Y2ggaGFzIG5v dCBiZWVuDQo+Pj4+PiBzdWJtaXR0ZWQgdG8gdXBzdHJlYW0sIGNvbnNpZGVyIGRvaW5nIHNv LiINCj4+Pj4gSXQgbG9zZXMgc29tZSBpbmZvcm1hdGlvbiAodGhhdCBwYXRjaGVzIGFyZSBw cmVmZXJyZWQpIGFuZA0KPj4+PiAoYWZ0ZXIgcmUtYWRkaW5nIHRoZSBjb25jbHVzaW9uKSBp cyBtb3JlIHZlcmJvc2UsIHdoaWNoIGFwcGVhcnMNCj4+Pj4gdG8gYmUgY29uc2lkZXJlZCB2 ZXJ5IGltcG9ydGFudC4NCj4+PiBXaGljaCBjb25jbHVzaW9uIGlzIHRoZXJlIHRvIHJlLWFk ZD8NCj4+DQo+PiAicGF0Y2hlcyBhcmUgcHJlZmVycmVkIg0KPj4NCj4+ICDCoMKgIFRoZSBj b25jbHVzaW9uIGlzIGFscmVhZHkgc3RhdGVkDQo+Pj4gaW4gdGhlIGJlZ2lubmluZzogcGF0 Y2hlcyBhcmUgYWxtb3N0IGFsd2F5cyB0aGUgYmVzdCBjaG9pY2UuwqAgVGhlbg0KPj4+IHR3 bw0KPj4+IHJlYXNvbnMgYXMgZm9yIHdoeS7CoCBUaGUgcGFydCB3LnIudC4gdXBzdHJlYW1p bmcgY2hhbmdlcyBoYXMgYWxzbw0KPj4+IGJlZW4NCj4+PiBhZGRyZXNzZWQuDQo+Pg0KPj4g V2hpbGUgSSBjb25zaWRlciB0aGF0IHBvbGljaWVzIHNob3VsZCBoYXZlICJiZXN0IGNob2lj ZXMiIGNvaW5jaWRpbmcNCj4+IHdpdGggInByZWZlcnJlZCIgYW5kIHRoYXQgbm90IGRvaW5n IHNvIHdvdWxkIGJlIGlsbG9naWNhbCwgcGVvcGxlLA0KPj4gcHJvamVjdHMsIGRlY2lzaW9u cyAuLi4gYXJlIGZhciBmcm9tIGFsd2F5cyBsb2dpY2FsLg0KPj4NCj4+IEJlY2F1c2Ugb2Yg dGhpcywgcGVvcGxlIGNhbm5vdCBhc3N1bWUgdGhhdCB0aGUgJ2Jlc3QgY2hvaWNlcycgYXJl DQo+PiAncHJlZmVycmVkJywgc28gaXQgbmVlZHMgdG8gYmUgbWVudGlvbmVkIGV4cGxpY2l0 bHkgdGhhdCB0aGVzZSAnYmVzdA0KPj4gY2hvaWNlcycgYXJlIGFjdHVhbGx5ICdwcmVmZXJy ZWQnLg0KPiBJbiB0aGF0IGNhc2UsIHNpbXBseSB3cml0ZSBwcmVmZXJyZWQgY2hvaWNlPw0K DQpJdCBpcyBhbHJlYWR5IG1lbnRpb25lZCB0aGF0IHRoZXkgYXJlIHByZWZlcnJlZDoNCg0K PiDigJhBcyBzdWNoLCBwYXRjaGVzIGFyZSBwcmVmZXJyZWTigJkNCg0KQnkgcmVtb3Zpbmcg dGhlIGluZm9ybWF0aW9uIHRoYXQgJ3BhdGNoZXMgYXJlIHRoZSBtb3N0IGNvbnZlbmllbnQg DQpjaG9pY2UnIChieSByZXBsYWNpbmcgaXQgd2l0aCDigJhwYXRjaGVzIGFyZSB0aGUgcHJl ZmVycmVkIGNob2ljZeKAmSksIHRoZSANCmxvZ2ljYWwgc3RydWN0dXJlIGJlY29tZXMgd2Vh a2VyOyBhIHBhcnQgb2YgdGhlIGV4cGxhbmF0aW9uIG9uIHRoZSDigJh3aHnigJkgDQpiZWNv bWVzIG1pc3NpbmcuDQoNCj4gDQo+Pj4gSSdtIHVzaW5nIGVudW1lcmF0aW9uIGFzIGEgc3Vw ZXIgdGVybSBoZXJlLCB3aGljaCBjYW4gYmUNCj4+PiAoKHN1YilzdWIpc2VjdGlvbnMsIGNo YXB0ZXJzLCBsaXN0IGVsZW1lbnRzLCB3aGF0ZXZlciwgYW5kIG15IGNsYWltDQo+Pj4gaXMg dGhhdCB3ZSBiYXJlbHkgaGF2ZSBlbm91Z2ggcHJpbmNpcGxlcyB0byBhbGxvdyB0aGUgdXNl IG9mIGENCj4+PiBwbHVyYWwuDQo+Pg0KPj4gSW4gRW5nbGlzaCwgdGhpbmdzIGFyZSBlaXRo ZXIgcGx1cmFsIG9yIHNpbmd1bGFyLsKgIEV2ZXJ5dGhpbmcgPj0gMiBpcw0KPj4gcGx1cmFs LsKgIFRoZXJlIG51bWJlciBvZiBwcmluY2lwbGVzLCBob3dldmVyIHdlIGNvdW50IHRoZW0s IGlzLCBhdA0KPj4gbGVhc3QsIDIuwqAgQ29uc2VxdWVudGx5LCB0aGUgcHJpbmNpcGxlcyBh cmUgcGx1cmFsLCBub3Qgc2luZ3VsYXIuDQo+PiBUcmVhdGluZyB0aGUgcHJpbmNpcGxlcyBh cyBzaW5ndWxhciBpcyBzaW1wbHkgZ3JhbW1hdGljYWxseQ0KPj4gaW5jb3JyZWN0Lg0KPiBD b3JyZWN0aW9uOiBFdmVyeXRoaW5nIHRoYXQgaXNuJ3QgZXhhY3RseSAxIGlzIHBsdXJhbCBp biBFbmdsaXNoLA0KPiBpbmNsdWRpbmcgMCwgd2l0aCBwZXJoYXBzIHRoZSBleGNlcHRpb24g b2YgLTEgYWxzbyB1c2luZyBzaW5ndWxhci4NCj4gDQo+PiBNYXliZSBpdCBpcyBiYXJlbHkg YWxsb3dlZCB0byBiZSBwbHVyYWwsIGJ1dCBFbmdsaXNoIGdyYW1tYXIgZG9lc24ndA0KPj4g Y2FyZSBhYm91dCB0aGF0IC0tIGl0IGlzIGRlZmluaXRpdmVseSBkaXNhbGxvd2VkIHRvIGJl IHNpbmd1bGFyLCBvbmx5DQo+PiBwbHVyYWwgcmVtYWlucy4NCj4gTm90ZSB0aGF0IG15IGFy Z3VtZW50IGlzbid0IGFib3V0IEVuZ2xpc2ggZ3JhbW1hciwgaXQgdXNlcyBFbmdsaXNoDQo+ IGdyYW1tYXIuDQoNCllvdXIgYXJndW1lbnQgaXMgdGhhdCDigJh0aGVyZSBhcmVuJ3QgYSBz dWZmaWNpZW50IGFtb3VudCBvZiBwcmluY2lwbGVzIHRvIA0KYWxsb3cgdGhlIHVzZSBvZiBh IHBsdXJhbOKAmS4gICdQbHVyYWwnIGlzIGEgY29uY2VwdCBvZiBFbmdsaXNoIGdyYW1tYXIu DQpBcyBzdWNoLCB5b3UgaGF2ZSB3cml0dGVuIGFuIGFyZ3VtZW50IGFib3V0IEVuZ2xpc2gg Z3JhbW1hci4NCg0KWW91IGFwcGVhciB0byBoYXZlIG1lYW50IHNvbWUgZGlmZmVyZW50IGFy Z3VtZW50LCBidXQgYWxsIHRoZSBhcmd1bWVudHMgDQpvbiDigJhhcmUgdGhleSBndWlkaW5n IHByaW5jaXBsZXMgb3Igbm904oCZIEkndmUgcmVhZCBhcmUgYmFzZWQgb24gdGhlIA0KbnVt YmVyIG9mIHByaW5jaXBsZXMgb3Igb24gd2hhdCAnZ3VpZGluZyBwcmluY2lwbGUnIG1lYW5z LCB3aGljaCBhcmUgDQppc3N1ZXMgb2YgZ3JhbW1hciBhbmQgdm9jYWJ1bGFyeSByZXNwZWN0 aXZlbHkuDQoNCkknbSBzdGlsbCBub3Qgc2VlaW5nIGhvdyB0aGV5IGFyZW4ndCBndWlkaW5n IHByaW5jaXBsZXMuICBNYXliZSB5b3UgaGF2ZSANCmEgZGlmZmVyZW50IG1lYW5pbmcgb2Yg 4oCYZ3VpZGluZyBwcmluY2lwbGVz4oCZIGluIG1pbmQ/ICBPciBtYXliZSB5b3Ugd291bGQN Cmxpa2UgdG8gbmFtZSB0aGVtICdndWlkZWxpbmVzJyBvciAnZ2VuZXJhbCByZWNvbW1lbmRh dGlvbnMnIGluc3RlYWQuDQoNCj4+PiBBZGRpbmcgdG8gdGhhdCwgbm93IHRoYXQgSSB0aGlu ayBvZiBpdCwgSSBhbHNvIGRvdWJ0IHRoZWlyDQo+Pj4gdXNlZnVsbmVzcyBpbiBndWlkaW5n LsKgICJVc2Ugd2hhdGV2ZXIgZmVlbHMgY29udmVuaWVudCwgYnV0IG5vdGUNCj4+PiB0aGF0 IHRoYXQgbWlnaHQgYmUgc3ViamVjdGl2ZSIgaXMgbW9yZSB1c2VmdWwgYXQgdGhlIGVuZCBv ZiB0aGUNCj4+PiBzZWN0aW9uIHdoZW4gYSB1c2VyIGRpZG4ndCBmaW5kIHdoYXQgdGhleSB3 ZXJlIGxvb2tpbmcgZm9yIHRoYW4gYXQNCj4+PiB0aGUgc3RhcnQuDQo+Pg0KPj4gVGhlIGlu dHJvZHVjdGlvbiBoYXMgYSBzZXQgb2YgZ3VpZGluZyBwcmluY2lwbGVzLCBmcm9tIHdpdGgg Y29uY3JldGUNCj4+IGNhc2VzIGFyZSBidWlsdC7CoCBCeSBhZGRpbmcgYW5vdGhlciBwcmlu Y2lwbGUgYXQgdGhlIGVuZCwgdGhlIGNhc2VzDQo+PiBjYW5ub3QgbWFrZSB1c2Ugb2YgdGhl ICJ1c2UgWy4uLl0gY29udmVuaWVudCIgcHJpbmNpcGxlLg0KPj4NCj4+IEFkZGl0aW9uYWxs eSwgbm93IHRoZSB1c2VyIGhhcyB0byBsb29rIGF0IF90d29fIHBsYWNlcyB0byBmaW5kIHRo ZQ0KPj4gZ3VpZGluZyBwcmluY2lwbGVzIC0tIGF0IHRoZSBiZWdpbm5pbmcsIGFuZCBhdCB0 aGUgZW5kLsKgIFdvcnNlLA0KPj4gdGhlIGJlZ2lubmluZyBkb2VzIG5vdCBoYXZlIGEgY3Jv c3MtcmVmZXJlbmNlIHRvIHRoZSBlbmQsIHNvIHNpbmNlDQo+PiB0aGUgc2V0IGF0IHRoZSBi ZWdpbm5pbmcgaXMgcHJlc2VudGVkIGFzIGV4aGF1c3RpdmUsIHRoZSB1c2VyIG1pZ2h0DQo+ PiBub3Qga25vdyB0aGVyZSBpcyBhbm90aGVyIGd1aWRpbmcgcHJpbmNpcGxlLg0KPj4NCj4+ IEFuZCBldmVuIGlmIHRoZXkgZGlkIHJlYWQgdGhyb3VnaCB0aGUgd2hvbGUgc2VjdGlvbiAo ZXZlbiB0aG91Z2ggdGhleQ0KPj4gc2hvdWxkIG9ubHkgaGF2ZSB0byByZWFkIHRoZSBpbnRy b2R1Y3Rpb24gYW5kIHRoZSByZWxldmFudCB3b3JrZWQtb3V0DQo+PiBjYXNlKSwgYXNzdW1p bmcgdGhleSByZWFkIHRocm91Z2ggaXQgaW4gYSBsaW5lYXIgZmFzaGlvbiwgZHVlIHRvIHRo ZQ0KPj4gbmV3IGd1aWRpbmcgcHJpbmNpcGxlIHRoYXQgd2Fzbid0IGFsbHVkZWQgdG8gYXQg dGhlIGJlZ2lubmluZywgdGhleQ0KPj4gaGF2ZSB0byByZWRvIHRoZWlyIG1lbnRhbCBtb2Rl bCBvZiAiTW9kaWZ5aW5nIFNvdXJjZXMiIGFzIHRoaXMNCj4+IHByaW5jaXBsZSBjb3VsZCBp bnZhbGlkYXRlIHRoaW5ncy4NCj4gVGhpcyBzaG93cyBib3RoIGEgcHJvYmxlbSB3aXRoIHlv dXIgc3RydWN0dXJlLA0KDQpJJ20gbm90IHNlZWluZyB0aGUgcHJvYmxlbS4gIEhvdyBkb2Vz IHRoaXMgc2hvdyBhIHByb2JsZW0/DQoNCj4gYnV0IG1vcmUgaW1wb3J0YW50bHksIGENCj4g ZmFpbHVyZSB0byB1bmRlcnN0YW5kIHdoYXQgSSBtZWFudCB3aGVuIEkgd3JvdGUgInVzZSB3 aGF0ZXZlciBpcw0KPiBjb252ZW5pZW50IiBpbiBteSBvd24gcGF0Y2guICBUaGlzIHByaW5j aXBsZSAqY2FuKiBvbmx5IHdvcmsgZm9yIGNhc2VzDQo+IGluIHdoaWNoIHRoZXJlIGlzICpu byBjbGVhcmx5IGVzdGFibGlzaGVkIHByYWN0aWNlKiwgdGh1cyBwdXR0aW5nIGl0IGF0DQo+ IHRoZSBlbmQgKmFmdGVyIGhhdmluZyBlbnVtZXJhdGVkIGFsbCBwcmFjdGljZXMqIGlzIHRo ZSBsb2dpY2FsIGNob2ljZS4NCj4gV2l0aCB5b3VyIHN0cnVjdHVyZSwgeW91IGhhdmUgdG8g YmVuZCBpdCBzaWRld2F5cyB0byBzaG9laG9ybiBpdCBpbg0KPiB3aXRoIHRoZSBvdGhlciBw cmluY2lwbGVzLg0KDQpZb3UgYXBwZWFyIHRvIGhhdmUgbWVhbnQgaXQgYXMgYSBraW5kIG9m IOKAmGZhbGxiYWNrIHByaW5jaXBsZeKAmSwgaW4gd2hpY2ggDQpjYXNlIHB1dHRpbmcgaXQg YXQgdGhlIGVuZCBkb2VzIGluZGVlZCBtYWtlIHNlbnNlLg0KDQpJbiBteSBwYXRjaCwgdGhl IHByaW5jaXBsZSB3b3JrcyBkaWZmZXJlbnRseSwgaXQgaXMgYWxzbyB1c2VkIGZvciANCmV4 cGxhaW5pbmcgYWxyZWFkeSBlc3RhYmxpc2hlZCBwcmFjdGljZXMsIGZvciB0aGUgY2FzZXMg d2hlcmUgdGhlcmUgYXJlIA0KbXVsdGlwbGUgdGVjaG5pY2FsbHkgYWxsb3dlZCBwcmluY2lw bGVzIGJ1dCBzdGlsbCBvZnRlbiBhIHNpbmdsZSANCl9yZWNvbW1lbmRlZF8gcHJpbmNpcGxl LiAgRS5nLjoNCg0KPiBVc3VhbGx5LCBhIGJ1ZyBmaXggY29tZXMgaW4gdGhlIGZvcm0gb2Yg YSBwYXRjaCBjb3BpZWQgZnJvbSB1cHN0cmVhbSBvcg0KPiBhbm90aGVyIGRpc3RyaWJ1dGlv bi4gIEluIHRoYXQgY2FzZSwgc2ltcGx5IGFkZGluZyB0aGUgcGF0Y2ggdG8gdGhlDQo+IEBj b2Rle3BhdGNoZXN9IGZpZWxkIGlzIHRoZSBtb3N0IGNvbnZlbmllbnQgYW5kIHVzdWFsbHkg ZG9lcyBub3QgY2F1c2UNCj4gYW55IHByb2JsZW1zOyB0aGVyZSBpcyBubyBuZWVkIHRvIHJl d3JpdGUgaXQgYXMgYSBzbmlwcGV0IG9yIGEgcGhhc2UuDQo+IA0KPiBJZiBubyByZWFkeS1t YWRlIHBhdGNoIGFscmVhZHkgZXhpc3RzLCB0aGVuIC4uLl0NCg0KYW5kDQoNCj4gVG8gYWRk IG5ldyBmdW5jdGlvbmFsaXR5LCBhIHBhdGNoIGlzIGFsbW9zdCBhbHdheXMgdGhlIG1vc3Qg Y29udmVuaWVudA0KPiBjaG9pY2Ugb2YgdGhlIHRocmVlIA0KDQouDQoNClRvIGdvIGZyb20g dGhlIHByaW5jaXBsZSBhcyB1c2VkIGluIHlvdXIgcGF0Y2ggdG8gdGhlIHByaW5jaXBsZSBh cyB1c2VkIA0KaW4gbXkgcGF0Y2gsIHBlcmhhcHMgaW4gdGhlIHByb2Nlc3MgaXQgaXMgYmVu dCBzaWRld2F5cyBhbmQgc2hvZWhvcm5lZC4NCkJ1dCBhZnRlciBhbGwgdGhlIGJlbmRpbmcg YW5kIHNob2Vob3JuaW5nLCBpdCBzZWVtcyB0byBmaXQgd2VsbCBub3cgaW4gDQp0aGUgYmVn aW5uaW5nIChhbmQgbm90IHdlbGwgYXQgYWxsIHRoZSBlbmQpLCBzbyBJJ20gbm90IHNlZWlu ZyBhbnkgDQpwcm9ibGVtcyBoZXJlLg0KDQo+IA0KPj4+IEF0IHRoZSByaXNrIG9mIHJlc3Bv bmRpbmcgam9raW5nbHkgdG8gd2hhdCB3YXMgbWVhbnQgc2VyaW91czogSQ0KPj4+IGRpZG4n dCBrbm93IHdlIHN1ZGRlbmx5IGdhaW5lZCAyMCBndWlkaW5nIHByaW5jaXBsZXMuDQo+Pg0K Pj4gMjUgbGluZXMgYXJlIGZvciB0aGUgZ3VpZGluZyBwcmluY2lwbGVzIChzb21ldGltZXMg cmVmZXJyaW5nIHRvIGENCj4+IHByaW5jaXBsZSBvZiBlbHNld2hlcmUgaW4gR3VpeCwgc29t ZXRpbWVzIGEgbmV3IHByaW5jaXBsZSBmb3INCj4+ICJNb2RpZnlpbmcgU291cmNlcyIpLsKg IFlvdSBwcm9wb3NlZCB0byAnY2FjaGUnIHRoZW0gc29tZWhvdy7CoCBJbg0KPj4gR3VpbGUs IHRvIGNhY2hlIHNvbWV0aGluZywgeW91IGNhbiB1c2UgJ2RlbGF5L2ZvcmNlJy7CoCBCdXQg dGhpcw0KPj4gaW5jcmVhc2VzIHRoZSBhbW91bnQgb2YgY29kZSAoZHVlIHRvIHRoZSBhZGRp dGlvbmFsIHVzZSBvZiAnZGVsYXknKSwNCj4+IGluc3RlYWQgb2YgZGVjcmVhc2luZy4NCj4+ DQo+PiBUaGUgZG9jdW1lbnRhdGlvbiBlcXVpdmFsZW50ICh3aGF0ZXZlciB0aGF0IG1pZ2h0 IGJlLCBJIGFtIG5vdCBzZWVpbmcNCj4+IG9uZSBteXNlbGYpIHdvdWxkIHRoZW4gYWxzbyBi ZSBhdCBsZWFzdCBhcyBsb25nLCBtYXliZSBldmVuIGEgbGl0dGxlDQo+PiBsb25nZXIgZHVl IHRvIHRoZSB1c2Ugb2YgJ2RlbGF5Jy4NCj4gT2theSwgc28gSSBkaWQgbWlzdW5kZXJzdGFu ZCB0aG9zZSAyNSBsaW5lcyBhcyAyNSBsaW5lcyB3aXRoaW4gdGhlIHRleHQNCj4gY2FsbGlu ZyBiYWNrIHRvIHRob3NlIGd1aWRpbmcgcHJpbmNpcGxlcyByYXRoZXIgdGhhbiAyNSBsaW5l cyBmb3IgdGhlDQo+IGd1aWRpbmcgcHJpbmNpcGxlcyB0aGVtc2VsdmVzLiAgU3RpbGwsIDI1 IGxpbmVzIGFyZSBhIGxpdHRsZSBtdWNoLA0KPiBlc3BlY2lhbGx5IGdpdmVuIHRoYXQgdGhl IGJ1bGsgb2YgaXQgZXhwbGFpbnMgdGhlIHNlbWFudGljcyBvZiB0aGUNCj4gcGFja2FnZXMn IHNvdXJjZSBmaWVsZC4NCg0KSSB0aGluayB3ZSdsbCBoYXZlIHRvIGFncmVlIHRvIGRpc2Fn cmVlIG9uIHRoYXQuDQoNCj4gDQo+Pj4+IEkgc3VwcG9zZSB0YWJsZSBpdGVtcyBtaWdodCB0 YWtlIHR3byBsZXNzIGxpbmUgb3Igc28gbGVzcyB0aGFuDQo+Pj4+IHN1YnN1YnNlY3Rpb25z LCBidXQgSSBkb24ndCB0aGluayB0aGF0J3Mgc3VmZmljaWVudCByZWFzb24gdG8NCj4+Pj4g c3RlcCBhd2F5IGZyb20gYSBuaWNlIHNlY3Rpb24gc3RydWN0dXJlLg0KPj4+IEFub3RoZXIg cmVhc29uIGlzIHRoYXQgeW91IGNhbiBlbmQgYSB0YWJsZSBpbiB0aGUgbWlkZGxlIG9mIGEN Cj4+PiBzZWN0aW9uLCB3aGljaCB5b3UgY2FuJ3QgZG8gd2l0aCBzdWJzZWN0aW9ucy7CoCBI ZW5jZSB3aHkgSSdtIGFibGUNCj4+PiB0byBwdXQgYSByZW1hcmsgYXQgdGhlIGJvdHRvbSwg d2hpY2ggeW91IGhhdmUgdG8gY2x1bXNpbHkgZml0IGludG8NCj4+PiB0aGUgdG9wLg0KPj4N Cj4+IEkgY2FuLCBpbmRlZWQsIG5vdCBwdXQgdGhlICdjb252ZW5pZW5jZSBwcmluY2lwbGUn IGF0IHRoZSBib3R0b20sDQo+PiBleGNlcHQgcGVyaGFwcyBieSBhZGRpbmcgYSBuZXcgc3Vi c3Vic2VjdGlvbiwgYW5kIGZvciB0YWJsZXMgYWRkaW5nDQo+PiBzdWNoIGEgcmVtYXJrIGF0 IHRoZSBib3R0b20gaXMgaW5kZWVkIG1vcmUgY29udmVuaWVudC4NCj4+DQo+PiBIb3dldmVy LCBJIGRvbid0IHNlZSB0aGUgJ2hhdmUgdG8gY2x1bXNpbHknIGhlcmUgLS0gYXMgZXhwbGFp bmVkDQo+PiBlbHNld2hlcmUsIEkgYmVsaWV2ZSB0aGF0IHRoZSAnY29udmVuaWVuY2UgcHJp bmNpcGxlJyBzaG91bGRuJ3QgYmUNCj4+IHNlcGFyYXRlZCBmcm9tIHRoZSBvdGhlciBwcmlu Y2lwbGVzIGFuZCB0aGF0IGl0IGZpdHMgbmljZWx5IG5leHQgdG8NCj4+IHRoZSB0aGUgcHJp bmNpcGxlcyAtLS0gdGhlcmUgaXMgbm8gJ2hhdmUgdG8nLCBiZWNhdXNlIEkgY2hvb3NlIGZv cg0KPj4gdGhpcywgYW5kIEkgYW0gbm90IHNlZWluZyBhbnkgJ2NsdW1zaW5lc3MnIGhlcmUu DQo+IEkgdGhpbmsgd2UnZCBoYXZlIHRvIGRlYmF0ZSBjaG9pY2UgdnMuIGZvcmNlIGhlcmUg d2hpY2ggd291bGQgYmUgYQ0KPiByYXRoZXIgbG9uZyBhc2lkZSwgYnV0IHRvIG1ha2UgbXkg YXJndW1lbnQgc2hvcnQsIHlvdXIgY2hvaWNlIG9mIGhvdyB0bw0KPiBzdHJ1Y3R1cmUgdGhp cyBzZWN0aW9uICh0YWJsZSB2cyBzdWJzZWN0aW9ucykgZGlyZWN0bHkgaW5mbHVlbmNlcyB5 b3VyDQo+ICJjaG9pY2UiIHdoZXJlIHRvIHBsYWNlIHBhcnRpY3VsYXIgaW5mb3JtYXRpb24N Cg0KU3VyZS4NCg0KPiBpbiBhIHdheSB0aGF0IG1pZ2h0DQo+IGluaGliaXQgbmF0dXJhbCBp bmZvcm1hdGlvbiBmbG93Lg0KDQpJJ20gbm90IHNlZWluZyBpdC4gIEFzIEkndmUgZXhwbGFp bmVkIHByZXZpb3VzbHksIHB1dHRpbmcgdGhlIHByZW1pc2VzIA0KKD0gZ3VpZGluZyBwcmlu Y2lwbGVzKSBiZWZvcmUgdGhlIGNvbmNsdXNpb25zICg9IHdvcmtlZCBvdXQgY2FzZXMgLyAN CnNvbHV0aW9ucykgaXMgYSBsb2dpY2FsIChoZW5jZSwgbmF0dXJhbCkgaW5mb3JtYXRpb24g ZmxvdywgYW5kIA0KaW50cm9kdWNpbmcgdGhlbSBvbi10aGUtd2F5IG9yIGltcGxpY2l0bHkg aXMgYWQtaG9jICh1bm5hdHVyYWwpLg0KPj4+PiBUaGUgcGF0Y2ggZG9lcyB0aGlzLCBjdXJy ZW50bHkuwqAgSXQgYWxyZWFkeSBwcm9wb3NlcyBhIG51bWJlciBvZg0KPj4+PiBoYW1tZXJz IChwYXRjaGVzLCBzbmlwcGV0cyBhbmQgcGhhc2VzKSBhbmQgcHVycG9zZXMgKGFkZGluZyBu ZXcNCj4+Pj4gZnVuY3Rpb25hbGl0eSwgZml4aW5nIHRlY2huaWNhbCBpc3N1ZXMsIHVuYnVu ZGxpbmcsIC4uLikuDQo+Pj4+IEFsc28sIHRoZSBzY2VuYXJpbyAib2ggbm8sIGhvd2V2ZXIg d2lsbCBJIHB1dCB0aGlzIG5haWwgaW50byBhDQo+Pj4+IHdhbGwiDQo+Pj4+IGFjdHVhbGx5 IGhhcHBlbmVkIC0tIHNlZSB0aGUgU2hlcGhlcmQgZGlzY3Vzc2lvbiwgd2hlcmUgdGhlcmUg d2FzDQo+Pj4+IGEgbG90IG9mIGRpc2FncmVlbWVudCBvbiBob3cgbmFpbHMgKD0gc21hbGwg d29yay1hcm91bmQgaW4gdGhlDQo+Pj4+IE1ha2VmaWxlKSBzaG91bGQgYmUgcHV0IGluIHdh bGxzICg9IHBhdGNoZXMsIHNuaXBwZXQsIHBoYXNlPykuDQo+Pj4+IEl0DQo+Pj4+IHdhcyB0 aGUgd2hvbGXCoHJlYXNvbiB0byBzdGFydCB3cml0aW5nIGEgZG9jdW1lbnRhdGlvbiBwYXRj aC4NCj4+PiBZb3UgbWlnaHQgd2FudCB0byBhZGQgYSBsaW5rIGhlcmUgaWYgaXQgc3VwcG9y dHMgeW91ciBhcmd1bWVudCwgYnV0DQo+Pj4gd2l0aG91dCBsb29raW5nIGF0IHRoZSBkaXNj dXNzaW9uIHRoaXMgcmF0aGVyIHNvdW5kcyBsaWtlICJvaCBubywgSQ0KPj4+IGhhdmUgdGhy ZWUgaGFtbWVycywgd2hpY2ggb25lIGRvIEkgcGljaz8iIOKAkyB3aGljaCwgZmFpciBlbm91 Z2gsIGlzDQo+Pj4gc3RpbGwgYSBwcm9ibGVtLCBidXQgb25lIHRoYXQgbmVpdGhlciBvZiBv dXIgcGF0Y2hlcyB3b3VsZCBjYXVzZQ0KPj4+IGltaG8uDQo+Pg0KPj4gQXMgSSB0aGluayBJ J3ZlIHdyaXR0ZW4gcHJldmlvdXNseSwgdGhlIHdob2xlIHBvaW50IHdhcyB0byBzb2x2ZSB0 aGF0DQo+PiBwcm9ibGVtLiBGb3IgdGhlIGRpc2N1c3Npb24sIHNlZToNCj4+DQo+PiAqIGh0 dHBzOi8vaXNzdWVzLmd1aXguZ251Lm9yZy81NDIxNg0KPj4gKg0KPj4gaHR0cHM6Ly95aGV0 aWwub3JnL2d1aXgvYzRjMGEwNzEtMmUwMy1kNGQ2LTY3MTgtMDU0MjRkMjFkMTQ2QHRlbGVu ZXQuYmUvDQo+PiAqDQo+PiBodHRwczovL3loZXRpbC5vcmcvZ3VpeC1kZXZlbC84NGUxM2Vm N2Q0MzcwNjJkZjVjY2E1MWExMmU2ZGE1NDkyOWUwMTc2LmNhbWVsQHRlbGVuZXQuYmUvDQo+ Pg0KPj4gTm90IHNvbHZpbmcgdGhlIHByb2JsZW0gZGVmZWF0cyB0aGUgd2hvbGUgcG9pbnQs IGFzIHRoZSBwdXJwb3NlIGlzIHRvDQo+PiBzb2x2ZSB0aGF0IHByb2JsZW0uDQo+IEkgdGhp bmsgd2UgbWlnaHQgYmUgZGlzYWdyZWVpbmcgYWJvdXQgd2hhdCBjb25zdGl0dXRlcyAic29s dmluZyB0aGUNCj4gcHJvYmxlbSIgaGVyZS4gIENvcnJlY3QgbWUgaWYgSSdtIHdyb25nLCBi dXQgdG8gbWUgaXQgc2VlbXMgYW55DQo+IHNjZW5hcmlvIHRoYXQgaXMgbm90IGNvdmVyZWQg Ynkgd2hhdGV2ZXIgcGF0Y2ggaXMgYXBwbGllZCBjb3VudHMgYXMNCj4gIm5vdCBoYXZpbmcg c29sdmVkIHRoZSBwcm9ibGVtIi4NCg0KSXQgZG9lc24ndCAtLSBJIGNvbnNpZGVyIHRoZSBT aGVwaGVyZCBwcm9ibGVtIHRvIGJlIHNvbHZlZCBieSBteSBwYXRjaCANCihhbGJlaXQgcmF0 aGVyIHdlYWtseSwgc2VlIGxhdGVyKSwgYW5kIHRoZSB3aWRlciBwcm9ibGVtIG9mIHVuY2xl YXIgDQpndWlkZWxpbmVzIGFuZCBwb2xpY3kgb24gc25pcHBldC9waGFzZS9wYXRjaCB0byBi ZSwgcGVyaGFwcyBub3QgcmVhbGx5IA0Kc29sdmVkLCBidXQgc3RpbGwgbXVjaCBpbXByb3Zl ZCAodGhpcyB0aW1lIG5vdCB3ZWFrbHkpLg0KDQo+IEkgcGVyc29uYWxseSBmaW5kIHRoaXMg bGluZSBvZg0KPiByZWFzb25pbmcgcXVlc3Rpb25hYmxlLCBhcyB0aGVyZSBhcmUgcGVyZmVj dGx5IHZhbGlkIHJlYXNvbnMgd2h5DQo+IG11bHRpcGxlIHRvb2xzIGNvdWxkIGFwcGx5Lg0K DQpTZWUgcHJldmlvdXMgcGFyYWdyYXBoLg0KDQo+IFRha2UgdGhlIHByb2JsZW0gb2YgZW1i ZWRkaW5nIGEgc3RvcmUgcGF0aC4gIFlvdSBjb3VsZCBmb3IgaW5zdGFuY2UNCj4gcmVwbGFj ZSBhbGwgb2NjdXJlbmNlcyBvZiAic2giIHdpdGggL2dudS9zdG9yZS8uLi4vYmluL3NoLCBv ciB5b3UgY291bGQNCj4gZmlyc3QgcmVwbGFjZSB0aGVtIGluIGEgcGF0Y2ggd2l0aCAiQHNo QCIgYW5kIHRoZW4gcmVwbGFjZSB0aGF0IHdpdGgNCj4gL2dudS9zdG9yZS8uLi4vYmluL3No LiAgT2YgY291cnNlLCB5b3UgcmFyZWx5IGhhdmUgdG8gZG8gdGhlIGxhdHRlciBhbmQNCj4g dGhlIGZvcm1lciBpcyBzaW1wbGVyLCBoZW5jZSB3aHkgeW91IHdpbGwgb2Z0ZW4gc2VlIHRo ZSBmb3JtZXIsIGJ1dA0KPiB0aGF0IGRvZXNuJ3QgbWVhbiB0aGUgbGF0dGVyIGlzIGludmFs aWQuDQoNCkl0J3MgY29udHJhcnkgdG8gJ0l0IHByZWZlcmFibHkgc2hvdWxkIGFsc28gd29y ayBvbiBub24tR3VpeCBzeXN0ZW1z4oCZIC0tIA0Kbm90IGludmFsaWQsIGJ1dCBzdGlsbCB1 c3VhbGx5ICgqKSBhZ2FpbnN0IChwcm9wb3NlZCkgcG9saWN5IGJlY2F1c2UgYSANCmRpcmVj dCBzdWJzdGl0dXRlKiBpcyBhdCB0aGUgc2FtZSB0aW1lIG1vcmUgY29udmVuaWVudCBhbmQg Zm9sbG93cyBhbGwgDQp0aGUgdGhlIHByaW5jaXBsZXMuDQoNCigqKSBzb21ldGltZXMsIGlu IGNhc2Ugb2Ygc2hlbGwgc2NyaXB0cywgYSBzdWJzdGl0dXRlKiBpcyBmcmFnaWxlIA0KKHN1 YnN0aXR1dGluZyB0b28gbXVjaCksIGluIHdoaWNoIGNhc2UgYSAic2giIC0+ICJAc2hAIiBi ZWNvbWVzIG1vcmUgDQpjb252ZW5pZW50IGFuZCBoZW5jZSB0aGUgdmlvbGF0aW9uIG9mIHRo ZSAnbm9uLUd1aXggc3lzdGVtJyBydWxlcyANCmJlY29tZXMgYWNjZXB0YWJsZS4NCg0KPj4+ Pj4gQW5kIGlmIHRoZXkgZG9uJ3QgZmluZCBhbnl0aGluZywgdGhleSBzZWUgdGhlIGhhbmR5 IGxpdHRsZSBsaW5lDQo+Pj4+PiBhdCB0aGUgYm90dG9tIHNheWluZyAidXNlIHdoYXRldmVy IHlvdSB0aGluayBpcyBjb252ZW5pZW50Ii4NCj4+Pj4gTm93aGVyZSBkaWQgdGhlIHBhdGNo IGltcGx5IHRoYXQgdGhlIGxpc3RlZCBjYXNlcyB3ZXJlIGFsbCBjYXNlcy4NCj4+Pj4gSW4g ZmFjdCwgaW4gdHdvIHBsYWNlcyBpbiB0aGUgaW50cm9kdWN0aW9uIGl0IGlzIGltcGxpZWQg dGhhdCB0aGUNCj4+Pj4gZXhhbXBsZXMgYXJlIG5vdCBleGhhdXN0aXZlLCBhbmQgdGhhdCB0 aGV5IGNhbiBjaG9vc2UgYWNjb3JkaW5nDQo+Pj4+IHRvIGNvbnZlbmllbmNlwqAgWy4uLl0N Cj4+PiBFbXBoYXNpcyBvbiBoYW5keSBsaXR0bGUgbGluZSByYXRoZXIgdGhhbiBuZWVkaW5n IHRvIGJlIHRvbGQgdHdpY2UNCj4+PiAocGFydGljdWxhcmx5IGlmIHBlb3BsZSBoYXZlIG5v IGlkZWEgd2hhdCB0byBleHBlY3QgZHVlIHRvIG5vdA0KPj4+IGhhdmluZyBsb29rZWQgYXQg dGhlIHdvcmtlZC1vdXQgY2FzZXMgeWV0KS4NCj4+DQo+PiBUaGV5IGRvbid0IG5lZWQgdG8g YmUgdG9sZCB0d2ljZS7CoCBBbHNvLCBteSBwYXRjaCBhbHNvIGhhcyB0aGF0IGhhbmR5DQo+ PiBsaXR0bGUgbGluZSAoYWxiZWl0IGRpZmZlcmVudGx5IHdvcmRlZCksIHNlZSB0aGUgJ2d1 aWRpbmcNCj4+IHByaW5jaXBsZXMnLg0KPj4NCj4+IEFsc28sIG9uIHRoZSAnbm8gaWRlYSB3 aGF0IHRvIGV4cGVjdCcgLS0gdGhpcyBpcyBleGFjdGx5IHRoZSBzYW1lIGZvcg0KPj4geW91 ciBwYXRjaCB0b28/wqAgSW4gYm90aCBwYXRjaGVzLCBpZiB0aGUgdXNlciBvbmx5IHJlYWRz IHRoZQ0KPj4gaW50cm9kdWN0aW9uIGFuZCBjb25jbHVzaW9uIChpZiBhbnkpIGFuZCBkb2Vz bid0IHJlYWQgdGhlIGFjdHVhbA0KPj4gKHJlbGV2YW50IGV4YW1wbGVzKS8oZXhwbGFuYXRp b24gb2YgcGF0Y2hlcywgc25pcHBldHMsIHBoYXNlcyksIHRoZW4NCj4+IHRoYXQncyB0aGVp ciBwcm9ibGVtLg0KPiBJIGRvIHRoaW5rIGEgdGFibGUgaW4gdGhlIG1pZGRsZSBvZiB0aGUg c2VjdGlvbiBpcyBoYXJkIHRvIGlnbm9yZSwNCg0KSSB0aGluayBzbyB0b28sIGhlbmNlIG15 IHByZXZpb3VzIHJlc3BvbnNlLg0KDQo+IGJ1dCBzdXBwb3NlIGZvciB0aGUgc2FrZSBvZiBh cmd1bWVudCB0aGF0IHRoZXkgZG8sIFsuLi5dDQoNCkdpdmVuIHRoaXMgcmVzcG9uc2UsIEkg YXNzdW1lIEkndmUgbWlzaW50ZXJwcmV0ZWQgd2hhdCB5b3UgbWVhbnQgd2l0aCANCuKAmG5v dCBoYXZpbmcgbG9va2VkIGF0IHRoZSB3b3JrZWQtb3V0IGNhc2VzIHlldOKAmS4NCg0KPj4+ Pg0KPj4+Pj4gSSBhbHNvIGV4cGFuZCBhIGxpdHRsZSBvbiB0aGUgYmVuZWZpdHMgYW5kIGRy YXdiYWNrcyBvZg0KPj4+Pj4gdGhlc2UgYXBwcm9hY2hlcyBhcyB5b3Ugd291bGQgd2hlbiBk ZXNjcmliaW5nIGRlc2lnbiBwYXR0ZXJucy4NCj4+Pj4gVGhpcyBpcyBhbHNvIGRvbmUgaW4g bXkgcGF0Y2guIFsuLi5dDQo+Pj4gVGhpcyBpcyBub3QgYWJvdXQgdGhlIGNvbnRhaW5lZCBp bmZvcm1hdGlvbiwgYnV0IHRoZSBzdHJ1Y3R1cmUgb2YNCj4+PiB0aGUgY29udGFpbmVkIGlu Zm9ybWF0aW9uLg0KPj4+DQo+Pj4gTXkgc29sdXRpb24tPnByb2JsZW0gc3R5bGUgZm9sbG93 cyByb3VnaGx5IHRoaXMgc3R5bGU6DQo+Pj4gMS4gc29sdXRpb24NCj4+PiAyLiBwcm9ibGVt cyBpdCBpcyBrbm93biB0byBzb2x2ZQ0KPj4+IDMuIGhvdyB0byB1c2UNCj4+PiA0LiBwcm9w ZXJ0aWVzLCBjYXZlYXRzLCBldGMuDQo+Pj4NCj4+PiBZb3VyIHByb2JsZW0tPnNvbHV0aW9u IHN0eWxlIHJvdWdobHkgaGFzIHRoZSBmb2xsb3dpbmc6DQo+Pj4gMS4gcHJvYmxlbQ0KPj4+ IDIuIChzZXQgb2YpIHNvbHV0aW9uKHMpDQo+Pj4gMy4gaWYgbW9yZSB0aGFuIG9uZSBzb2x1 dGlvbiwgbWF5YmUgYSBoZWxwIHRvIHNlbGVjdA0KPj4NCj4+IEFsc28sIGluIG5vIHBhcnRp Y3VsYXIgb3JkZXINCj4+DQo+PiAgwqDCoCA0LjogaG93IHRvIHVzZQ0KPj4gIMKgwqAgNS46 IGV4cGxhbmF0aW9uIHdoeSBpdCBpcyBwcmVmZXJyZWQgKHByb3BlcnRpZXMsIGNhdmVhdHM/ KQ0KPiBObyBwYXJ0aWN1bGFyIG9yZGVyIGlzIHByb2JsZW1hdGljLA0KDQpJJ20gbm90IHNl ZWluZyB3aHkuDQoNCiAgYnV0IG1vcmUgaW1wb3J0YW50bHkgaWYgYQ0KPiB0ZWNobm9sb2d5 IGFwcGVhcnMgbW9yZSB0aGFuIG9uY2UgKGd1YXJhbnRlZWQgYnkgdGhlIHBpZ2VvbmhvbGUN Cj4gcHJpbmNpcGxlKSwgdGhlbiBlaXRoZXIgaXRzIHByb3BlcnRpZXMgZ2V0IHJlcGVhdGVk IChub3QgZ29vZCBmb3INCj4gbGVuZ3RoKSBvciBzY2F0dGVyZWQgKG5vdCBnb29kIGZvciB0 aGUgZmxvdyB5b3Ugd2FudCkuICBBZ2FpbiwgYQ0KPiBzdHJ1Y3R1cmFsIHByb2JsZW0uDQoN ClRoYXQncyBlcXVhbGx5IGFwcGxpZXMgdG8geW91ciBwYXRjaCB0b28sIHRob3VnaD8gIChT d2l0Y2hpbmcgDQoidGVjaG5vbG9neSIgd2l0aCAicHJvYmxlbSIuKQ0KDQpBbHNvLCBJJ3Zl IHJlLXJlYWQgbXkgcGF0Y2gsIGFuZCBJIGRpZG4ndCBmaW5kIGFueSByZXBlYXRlZCBwcm9w ZXJ0aWVzIA0Kb3Igc2NhdHRlcmluZywgZXhjZXB0IGZvciBhIHNpbmdsZSBwcm9wZXJ0eSAo cGF0Y2hlcyBhcmUgdXBzdHJlYW1hYmxlKToNCg0KID4gRmlyc3QsIHdoZW4gdGhlIGZpeCBp cyBub3QgR3VpeC1zcGVjaWZpYywgdXBzdHJlYW1pbmcgdGhlIGZpeCBpcw0KID4gc3Ryb25n bHkgZGVzaXJlZCB0byBhdm9pZCB0aGUgYWRkaXRpb25hbCBtYWludGVuYW5jZSBjb3N0IHRv IEd1aXguDQogPiBbLi4uXQ0KPiBBcyBzdWNoLCBwYXRjaGVzIGFyZSBwcmVmZXJyZWQuICBI b3dldmVyLCBhcyB3aXRoIGJ1Zw0KPiBmaXhlcywgdXBzdHJlYW1pbmcgdGhlIG5ldyBmdW5j dGlvbmFsaXR5IGlzIGRlc2lyZWQuDQoNCkFzIHN1Y2gsIEknbSBub3QgZm9sbG93aW5nIHlv dXIgcG9pbnQgaGVyZS4NCg0KPj4+IFRoaXMgbWFrZXMgaXQgc28gdGhhdCBwZW9wbGUgbWln aHQgaGF2ZSB0byBnbyB0byBhIGRpZmZlcmVudA0KPj4+IHN1YnNlY3Rpb24gdGhhbiB0aGUg b25lIHRoZXkgcmVhZCBmb3IgdGhlaXIgc29sdXRpb24gdG8gZmluZCBvdXQNCj4+PiBhYm91 dCBwb3RlbnRpYWwgY2F2ZWF0cywgZS5nLiBub3QgZW1iZWRkaW5nIHN0b3JlIHBhdGhzIGlu IGENCj4+PiBzbmlwcGV0Lg0KPj4NCj4+IEkgYXNzdW1lIHRoZWlyIHByb2JsZW0gd2FzICJY IGRvZXNuJ3QgZmluZCBZIi7CoCBUaGlzIGJlaW5nIGENCj4+IHRlY2huaWNhbCBpc3N1ZSwg dGhleSBnbyB0byAiRml4aW5nIHRlY2huaWNhbCBpc3N1ZXMiLsKgIEluIHRoYXQNCj4+IHN1 YnN1YnNlY3Rpb24sICB0aGVyZSBhcmUgdGhlIHdvcmRzOg0KPj4NCj4+PiBTZWNvbmRseSwg aWYgdGhlIGZpeCBvZiBhIHRlY2huaWNhbCBpc3N1ZSBlbWJlZHMgYSBzdG9yZSBmaWxlIG5h bWUsDQo+Pj4gdGhlbiBpdCBoYXMgdG8gYmUgYSBwaGFzZS7CoCBPdGhlcndpc2UsIGlmIHRo ZSBzdG9yZSBmaWxlIG5hbWUgd2VyZQ0KPj4+IGVtYmVkZGVkIGluIHRoZSBzb3VyY2UsIHRo ZSByZXN1bHQgb2YgQGNvbW1hbmR7Z3VpeCBidWlsZCAtLXNvdXJjZX0NCj4+PiB3b3VsZCBi ZSB1bnVzYWJsZSBvbiBub24tR3VpeCBzeXN0ZW1zIGFuZCBhbHNvIGxpa2VseSB1bnVzYWJs ZSBvbg0KPj4+IEd1aXggc3lzdGVtcyBvZiBhbm90aGVyIGFyY2hpdGVjdHVyZS4NCj4+DQo+ PiBzbyB0aGV5IGFjdHVhbGx5IGRvIGtub3cgb2YgdGhlIGNhdmVhdCAnZG9uJ3QgZW1iZWQg c3RvcmUgcGF0aHMgaW4gYQ0KPj4gc25pcHBldCwgZG8gaXQgaW4gYSBwaGFzZSBpbnN0ZWFk JywgYW5kIHRoZXkgZGlkIG5vdCBuZWVkIHRvIGdvIHRvIGENCj4+IGRpZmZlcmVudCBzdWJz dWJzZWN0aW9uLg0KPiBUeXBpY2FsIGhhcHB5IHBhdGguDQoNCkluZGVlZCwgaXQncyBhIGhh cHB5IHBhdGghDQoNCj4+Pj4NCj4+Pj4+IFlvdXIgcHJvYmxlbS0+c29sdXRpb24gYXBwcm9h Y2ggaW5zdGVhZCBsZWF2ZXMgcGVvcGxlIHdvbmRlcmluZw0KPj4+Pj4gd2hlbiB0aGVpciBw YXJ0aWN1bGFyIHVzZSBjYXNlIGhhcyBub3QgYmVlbiBkZXNjcmliZWQuDQo+Pj4+IFNlZSBt eSByZXBseSB0byDigJhBbmQgaWYgdGhleSBkb24ndCBmaW5kIGFueXRoaW5nLCB0aGV5IHNl ZSB0aGUNCj4+Pj4gaGFuZHkgbGl0dGxlIGxpbmUgYXQgdGhlIGJvdHRvbSBzYXlpbmcgInVz ZSB3aGF0ZXZlciB5b3UgdGhpbmsgaXMNCj4+Pj4gY29udmVuaWVudOKAmS4NCj4+Pj4+IEl0 IGdpdmVzIHRoZW0gYSBzb2x1dGlvbiByYXRoZXIgdGhhbiB0aGUgdG9vbHMgdG8gYnVpbGQN Cj4+Pj4+IHNvbHV0aW9ucyB3aXRoLg0KPj4+PiBJdCBkb2VzIGdpdmUgdGhlIHRvb2xzOiBz bmlwcGV0cywgcGF0Y2hlcyBhbmQgcGhhc2VzLg0KPj4+IEFzIGZhciBhcyBJIHJlYWQsIGl0 IGRlc2NyaWJlcyBub25lIG9mIHRob3NlLsKgIEl0IHB1dHMgb3V0IGd1aWRpbmcNCj4+PiBw cmluY2lwbGVzIGFuZCBzb21lIGFscmVhZHkgd29ya2VkLW91dCBjYXNlcy4NCj4+IEhlcmUg YXJlIHRoZSBkZXNjcmlwdGlvbnM6DQo+Pg0KPj4+IEd1aXggaGFzIHRyZWUgbWFpbiB3YXlz IG9mIG1vZGlmeWluZyB0aGUgc291cmNlIGNvZGUgb2YgYSBwYWNrYWdlLA0KPj4+IHRoYXQg eW91IGFzIGEgcGFja2FnZXIgbWF5IHVzZS7CoCBUaGVzZSBhcmUgcGF0Y2hlcywgc25pcHBl dHMgYW5kDQo+Pj4gcGhhc2VzDQo+Pg0KPj4gT25jZSB0aGUgdXNlciBrbm93cyBfd2hpY2hf IG9mIHRoZSB0aHJlZSB0aGV5IHNob3VsZCB1c2UgKGJ5DQo+PiBjb25zdWx0aW5nIHRoZSBm b2xsb3dpbmcgc3Vic3Vic2VjdGlvbnMpLCB0aGV5IGNhbiB0aGVuIHNlYXJjaCBmb3INCj4+ ICdwYXRjaCcsICdzbmlwcGV0JyBhbmQgJ3BoYXNlcycgaW4gdGhlIG1hbnVhbCBmb3IgbW9y ZSBpbmZvcm1hdGlvbiwNCj4+IG5vIG5lZWQgdG8gZHVwbGljYXRlIHRoYXQgaW5mb3JtYXRp b24uDQo+IFBvaW50IHRha2VuLCBidXQgaW1obyBjcm9zcy1yZWZlcmVuY2VzIGFyZSBuaWNl IGZvciB0aG9zZSB3aG8ganVzdA0KPiBsZWFybmVkICJva2F5LCBJIG5vdyBrbm93IEkgbmVl ZCB0byBzb2x2ZSBteSB0ZWNobmljYWwgcHJvYmxlbSB3aXRoIGENCj4gcGhhc2UsIGhvdyBk byBJIGRvIHRoYXQ/Ig0KDQpUaGV5IGFyZSBpbmRlZWQuICBCdXQgSSdtIG5vdCBmb2xsb3dp bmcgd2hhdCB5b3UgbWVhbiB3aXRoICJCdXQiIGhlcmUuDQpJIGRpZG4ndCBjbGFpbSBhbnl0 aGluZyBhYm91dCBjcm9zcy1yZWZlcmVuY2VzIHRoZXJlPw0KDQpEbyB5b3Ugd2FudCBtZSB0 byBhZGQgYSBmZXcgY3Jvc3MtcmVmZXJlbmNlcyAoZm9yICdwYXRjaCcsICdzbmlwcGV0JyBh bmQgDQoncGhhc2VzJyk/DQoNCj4+Pj4gQWxzbywgImdpdmluZyB0aGUgdG9vbHMgdG8gYnVp bGQgc29sdXRpb25zIHdpdGgiIGRvZXMgbm90IGhlbHANCj4+Pj4gd2l0aCB0aGXCoHByb2Js ZW0gdGhhdCBJIGFpbWVkIHRvIHNvbHZlIC0tIHRoZXJlIHdhcyBkaXNhZ3JlZW1lbnQNCj4+ Pj4gb24gd2hhdCB0aGXCoGFwcHJvcHJpYXRlIHRvb2xzIGFyZSAoc2VlOiBTaGVwaGVyZCks IHNvIGl0IG5vdCBqdXN0DQo+Pj4+IG5lZWRzIHRvIGdpdmUgdGhlwqB0b29scywgYnV0IGFs c28gdGhlIHNvbHV0aW9ucy4NCj4+PiBJIGRvbid0IHNlZSBob3cgbXkgcGF0Y2ggbGFja3Mg dGhpcyBpbmZvcm1hdGlvbiBob3dldmVyLg0KPj4NCj4+IElJVUMsIHRoZSByYXcgaW5mb3Jt YXRpb24gc2hvdWxkIHVzdWFsbHkgYmUgaW5kZWVkIGFsbCB0aGVyZSwgYnV0IHRoZQ0KPj4g dXNlciBoYXMgdG8gY29uc3VsdCBfYWxsXyBvZiB0aGUgc2VjdGlvbnMgdG8gZGV0ZXJtaW5l IHdoaWNoIG9wdGlvbg0KPj4gKHBhdGNoLCBzbmlwcGV0LCBwaGFzZSkgaXMgYXBwcm9wcmlh dGUsIGhhdmluZyB0byBhc3NlbWJsZSBhbGwgdGhlDQo+PiBpbmZvcm1hdGlvbiBpcyAoYSkg YSB3YXN0ZSBvZiB0aW1lIGFuZCAoYikgY2FuIGxlYWQgdG8gZGlmZmVyZW50DQo+PiBpbnRl cnByZXRhdGlvbnMgYW5kIGNvbmNsdXNpb25zIChzZWU6IFNoZXBoZXJkKS4NCj4+DQo+PiBN b3JlIGNvbmNyZXRlbHksIEkgY2Fubm90IHVzZSB5b3VyIHBhdGNoIHRvIGRlY2lkZSBiZXR3 ZWVuIHBoYXNlcywNCj4+IHNuaXBwZXRzIGFuZCBwYXRjaGVzIGZvciB0aGUgU2hlcGhlcmQg aXNzdWU6DQo+Pg0KPj4gKiBub25lIG9mIHRocmVlIGFwcGVhciB0byBiZSBmb3JiaWRkZW4g YnkgeW91ciBkb2N1bWVudGF0aW9uDQo+PiAqIHRoZXJlIGlzIG5vIHJlY29tbWVuZGF0aW9u IGZvciAncGF0Y2hlcycgKElJUkMgaXQgd2Fzbid0IGFjY2VwdGVkDQo+PiB1cHN0cmVhbSBh bmQgdGhlcmUgd2FzIG5vIGludGVudCB0byBzdWJtaXQgaXQgdXBzdHJlYW0sIGl0IGJlaW5n DQo+PiByZWFsbHkgYSBHdWlsZSBidWcsIG5vdCBhIFNoZXBoZXJkIGJ1ZykNCj4+ICogdGhl cmUgaXMgbm8gcmVjb21tZW5kYXRpb24gZm9yIHNuaXBwZXRzIChpdCdzIGFsbCBmcmVlLCBu bw0KPj4gYnVuZGxpbmcpDQo+PiAqIGJ1aWxkIHBoYXNlcyBhcmUgJ3RvIGJlIGF2b2lkZWQn IChidXQgbm90IGZvcmJpZGRlbiksIGFzIGl0DQo+PiByZXN1bHRlZA0KPj4gIMKgwqAgaW4g b2JzZXJ2YWJseSBkaWZmZXJlbnQgcnVudGltZSBiZWhhdmlvdXIgKGJlaW5nIGEgYnVnIGZp eCkNCj4+DQo+PiAtLSB0aHJlZSAob3IgYXQgYmVzdCwgdHdvLCBpZiBidWlsZCBwaGFzZXMg YXJlIGRpc2NvdW50ZWQpIG9wdGlvbnMNCj4+IHJlbWFpbi7CoCBNeXNlbGYsIEkgd291bGQg dGhlbiBjb25zaWRlciAnc25pcHBldHMnIHRvIGJlIHRoZSBtb3N0DQo+PiBjb252ZW5pZW50 LCBidXQgc29tZSBvdGhlcnMgKHNlZTogU2hlcGhlcmQsIElJUkMpIHdvdWxkIHJlYWxseSB3 YW50IGENCj4+IHBhdGNoIGluc3RlYWQsIGJlY2F1c2UgJ3BhdGNoZXMgY2FuIGJlIHJldmVy dGVkJyBvciBzb21ldGhpbmcgbGlrZQ0KPj4gdGhhdC4NCj4+DQo+PiBBcyBzdWNoLCB5b3Ug YXJlIGdpdmluZyB0aGUgdG9vbHMgKHNuaXBwZXRzIC8gcGF0Y2hlcyAvIHBoYXNlcywgc29t ZQ0KPj4gZG93bnNpZGVzIGFuZCB1cHNpZGVzKSwgYnV0IGRpZmZlcmVudCBwZW9wbGUgY2Fu IGNvbnN0cnVjdCBkaWZmZXJlbnQNCj4+IHNvbHV0aW9ucyBmcm9tIHRob3NlIHRvb2xzIGV2 ZW4gaW4gdGhlIHNhbWUgc2l0dWF0aW9uLCBsZWFkaW5nIHRvDQo+PiBjb25mbGljdHMuDQo+ Pg0KPj4gSWYgSSB1c2UgbXkgcGF0Y2ggaW5zdGVhZCwgSSBnbyB0byAiZml4aW5nIHRlY2hu aWNhbCBpc3N1ZXMiLiBUaGlzDQo+PiBzZWN0aW9uIHRlbGxzIG1lIHRvIHVzZSBhIHBhdGNo IG9yIGEgc25pcHBldC7CoCBBcyB0aGUgZml4IGlzIG5vdA0KPj4gR3VpeC1zcGVjaWZpYywg aXQgcmVjb21tZW5kcyBhIHBhdGNoIHRvIHNhdmUgdGltZSB3aGVuIHVwc3RyZWFtaW5nLg0K Pj4gQ29uY2x1c2lvbjogd3JpdGUgYSBwYXRjaC7CoCBJdCB3YXMgYSBHdWlsZSBidWcsIHNv IHRoZSBmaXggd2FzIGENCj4+IHBhdGNoIHRvIEd1aWxlLsKgIEJ1dCB0aGF0IHdvdWxkIHRh a2UgdGltZSBhbmQgdXBzdHJlYW0gdG9vayB0aGUNCj4+IHJlc3BvbnNpYmlsaXR5IGZvciBh IGZpeCwgc28gdGhlICdlZmZpY2llbnQgdGltZSB0aGluZycgZG9lc24ndA0KPj4gcmVhbGx5 IGFwcGx5IGFuZCBhIHNtYWxsIHdvcmstYXJvdW5kIChzZXR0aW5nIG9wdGltaXNhdGlvbiBm bGFncykNCj4+IHN1ZmZpY2VzLg0KPj4NCj4+IEluIHRoaXMgc2l0dWF0aW9uLCB0aGUgc3Vi c3Vic2VjdGlvbiBkb2Vzbid0IGNhcmUgYXQgYWxsIGlmIHlvdSBnbw0KPj4gZm9yIGEgc25p cHBldCwgc28gYXBwbHkgdGhlIGxhc3QgZ3VpZGluZyBwcmluY2lwbGU6IGdvIGZvciB0aGUN Cj4+IHNpbXBsZXN0IHRoaW5nOiBhIHNuaXBwZXQuIChVbmxlc3MgeW91IGFscmVhZHkgaGF2 ZSBhIHBhdGNoLCB0aGVuIGENCj4+IHBhdGNoIGlzIHNpbXBsZXN0LikNCj4+IERvZXMgc29t ZW9uZSBlbHNlIGhhdmUgYSBkaWZmZXJlbnQgaWRlYSBvbiB3aGF0J3Mgc2ltcGxlc3Q/wqAg RG9lc24ndA0KPj4gcmVhbGx5IG1hdHRlciwg4oCYU29tZXRpbWVzIHRoaXMgaXMgc3ViamVj dGl2ZSwgd2hpY2ggaXMgYWxzbyBmaW5l4oCZLg0KPiBJIGRvIGdldCB0aGUgaW1wcmVzc2lv biB0aGF0IHRoaXMgcGF0Y2ggc2ltcGx5IGNvZGlmaWVzIHdoYXQgeW91IGZlZWwNCj4gaXMg cmlnaHQgYmFzZWQgb24gdGhlIHNoZXBoZXJkIHNpdHVhdGlvbg0KDQpUcnVlLCBleGNlcHQg Zm9yIHRoZSAnc2ltcGx5JywgYXMgSSBhbHNvIGNvbnNpZGVyZWQgc2V2ZXJhbCBvdGhlciAN CnNpdHVhdGlvbnMgKFJlbW92aW5nIGJ1bmRsZWQgbGlicmFyaWVzLCBSZW1vdmluZyBub24t ZnJlZSBzb2Z0d2FyZSwgDQpBZGRpbmcgbmV3IGZ1bmN0aW9uYWxpdHkpLiAgSSBkbyBub3Qg c2VlIHRoZSBwcm9ibGVtIHdpdGggdGhpcyAtLSB0aGUgDQpwcm9wb3NlZCBwb2xpY3kgd2Fz IGNvbnNpZGVyZWQgd29ya2FibGUgZXZlbiBpZiBzb21lIHdvdWxkIGxpa2UgaXQgdG8gYmUg DQphIGxpdHRsZSBiaXQgZGlmZmVyZW50LCBhbmQgaWYgb3RoZXJzIGZlZWwgc3Ryb25nbHkg YWJvdXQgdGhleSBjb3VsZCwgSSANCmRvbid0LCBtYXliZSBzZXQgdXAgYSB2b3RlIHN5c3Rl bSBvciBzdWNoLg0KDQo+IHJhdGhlciB0aGFuIHRoaW5raW5nIGFib3V0IHRoZSBnZW5lcmFs IGNhc2UsDQoNClNlZTogc2V2ZXJhbCBvdGhlciBjYXNlcyB0aGF0IHNob3VsZCBjb3ZlciBt b3N0IHNpdHVhdGlvbnMgZW5jb3VudGVyZWQgDQppbiBwcmFjdGljZSwgYW5kIGZvciB0aGUg cGFydHMgb2YgdGhlIGdlbmVyYWwgY2FzZSB0aGF0IGFyZW4ndCANCndvcmtlZC1vdXQgeWV0 LCB0aGVyZSBhcmUgdGhlIGd1aWRpbmcgcHJpbmNpcGxlcy4NCg0KPiB3aGljaCBpcyB3aHkg bXkgcGF0Y2ggbWFrZXMgd2Vha2VyIHN0YXRlbWVudHMgaGVyZS4gIElmDQo+IHRoaXMgaXNz dWUgY291bGQgaGF2ZSBiZWVuIGF2b2lkZWQgd2l0aCBhICM6bWFrZS1mbGFnLCB3ZSB3b3Vs ZCBoYXZlDQo+IHVzZWQgdGhhdC4NCj4gDQo+IE1vcmUgaW1wb3J0YW50bHksIEkgZmFpbCB0 byBzZWUgdGhlIHN1cGVyaW9yaXR5IG9mIHlvdXIgcGF0Y2ggaGVyZSA+IElJVUMgbmVpdGhl ciBwYXRjaCBvZmZlcnMgYSB1bmlxdWUgc29sdXRpb24gdG8gdGhlIHNoZXBoZXJkIHRoaW5n LCBzbw0KPiB0aGUgcm9vbSBmb3IgZGViYXRlIHJlbWFpbnMNCg0KSW4gbXkgcGF0Y2gsIG11 bHRpcGxlIG9wdGlvbnMgcmVtYWluLCBidXQgdGhlcmUgaXMgbm8gcmVhbCByb29tIGZvciAN CmRlYmF0ZS4gIE1vcmUgY29uY3JldGVseToNCg0KPiBXaGVuIHRoZXJlIGlzIG1vcmUgdGhh biBvbmUgd2F5IHRvIGRvIHNvbWV0aGluZywgY2hvb3NlIHdoaWNoZXZlciBtZXRob2QNCj4g aXMgdGhlIHNpbXBsZXN0LiAgU29tZXRpbWVzIHRoaXMgaXMgc3ViamVjdGl2ZSwgd2hpY2gg aXMgYWxzbyBmaW5lLg0KPiBXaGF0IG1hdHRlcnMgaXMgdGhhdCB5b3UgdXNlIHRlY2huaXF1 ZXMgdGhhdCBhcmUgY29tbW9uIHdpdGhpbiB0aGUNCj4gY29tbXVuaXR5IChpLmUuLCBwYXR0 ZXJucyB0aGF0IGFwcGVhciB0aHJvdWdob3V0IEBjb2Rle2dudS9wYWNrYWdlcy8uLi59KQ0K PiBhbmQgYXJlIHRodXMgY2xlYXJseSBsZWdpYmxlIGZvciByZXZpZXdlcnMuDQoNCml0IGlz IGNvbnNpZGVyZWQgc3ViamVjdGl2ZSwgaGF2aW5nIG11bHRpcGxlIG9wdGlvbnMgaWYgZmlu ZSEgIFRvIA0KY29ycmVjdCBhIHBhY2thZ2luZyBmb2xsb3dpbmcgdGhlIG90aGVyIG9wdGlv biAodG8gaGVscCB3aXRoIGZvbGxvd2luZyANCnRoZSBwb2xpY2llcyksIHlvdSBkb24ndCBo YXZlIHRvIGRlYmF0ZSBvbiB3aGF0J3MgdGhlIHByb3BlciBvcHRpb24gdG8gDQpnZXQgYSBm aXggaW4sIGFzIGJvdGggYXJlIGNvbnNpZGVyZWQgYWNjZXB0YWJsZS4gIEluIG1hbnkgY2Fz ZXMsIG5vIG5lZWQgDQpmb3IgZGViYXRlLCBqdXN0IHBpY2sgb25lIGFuZCBtb3ZlIG9uLiAg KEFsc28gdGhlIGNhc2UgZm9yIHlvdXIgcGF0Y2ggSUlVQy4pDQoNClRoaW5ncyBhcmUgYWxz byBwaHJhc2VkIHJlY29uY2lsaWF0b3J5LCBlO2cuOg0KDQo+IFRvIG1ha2UgdGhpbmdzIG1v cmUgY29uY3JldGUgYW5kIHRvIHJlc29sdmUgY29uZmxpY3RzIGJldHdlZW4gdGhlDQo+IHBy aW5jaXBsZXMsIGEgZmV3IGNhc2VzIGhhdmUgYmVlbiB3b3JrZWQgb3V0Og0KDQpIb3dldmVy LCBpbiB5b3VyIHBhdGNoLCB0aGVyZSBpcyBtb3JlIG9wcG9ydHVuaXR5IGZvciBjb25mbGlj dHMuIEUuZy46DQoNCj4gRWFjaCBvbmUgaGFzIGl0cyBzdHJlbmd0aHMgYW5kIGRyYXdiYWNr cywgYWxvbmcgd2l0aCBpbnRlbmRlZCBhbmRoaXN0b3JpY2FsbHkgZGVyaXZlZCB1c2UgY2Fz ZXMuDQoNCkJ5IHRoaXMgbGluZSwgYXJndW1lbnRzIGxpa2UgJ1ggd2FzIGhpc3RvcmljYWxs eSB0aGUgaW50ZW5kZWQgcHVycG9zZSBvZiANClksIHVzaW5nIFkgZm9yIFogaXMgaW5jb3Jy ZWN0JyBiZWNvbWUgcmVhc29uYWJsZSwgd2hpY2ggbWFrZXMgDQpkaXNhZ3JlZW1lbnRzIG1v cmUgZGlmZmljdWx0IHRvIHJlc29sdmUgKGFzIHlvdSBrbm93IG5lZWQgdG8gY29uc3VsdCAN Cmhpc3RvcnkgYW5kIGJlY2F1c2UgaGlzdG9yeSBpcyBmaXhlZCwgc28gbm8gaW1wcm92ZW1l bnRzIHdvdWxkIGJlIA0KcG9zc2libGUgYW55bW9yZSBpbiBhcmVhcyB3aGVyZSB0aGVyZSBp cyBhIGhpc3RvcmljYWxseSBpbnRlbmRlZCB1c2UgY2FzZSkuDQoNCj4gWW91IGNvdWxkIGNs YWltIHRoYXQgbXkgcGF0Y2ggb2ZmZXJzIG1vcmUNCj4gcm9vbSwgd2hpY2ggZmFpciBlbm91 Z2gsIGl0IGRvZXMsIGJ1dCBvbiB0aGUgc2FtZSB0b2tlbiBpdCBhbGxvd3MNCj4gcGVvcGxl IHRvIHNlZSB0aGF0IHRoZSBndWlkZWxpbmVzIGhhdmUgYmVlbiBmb2xsb3dlZCBhbmQgdGhl IHBhdGNoIGNhbg0KPiBiZSBhcHBsaWVkLg0KPiANCj4+PiBJbiBwYXJ0aWN1bGFyLCBmb3Ig cmV2aWV3IHB1cnBvc2VzLCBtaW5lIHNob3VsZCBiZSBlYXNpZXIgdG8gd29yaw0KPj4+IHdp dGguICBGb3IgaW5zdGFuY2UsIHRoZSByZXZpZXdlciBzZWVzIGEgaGFzaCBlbWJlZGRlZCBp biBhDQo+Pj4gc25pcHBldCwgc2VlcyBpbiB0aGUgc25pcHBldCBlbnRyeSB0aGF0IHlvdSBz aG91bGRuJ3QgZG8gdGhhdCwgYW5kDQo+Pj4gY2FuIHRodXMgc2F5ICJub3BlLCBkb24ndCBk byBhIHNuaXBwZXQgaGVyZSIuDQoNClRoYXQgaXMgYWxzbyB0aGUgY2FzZSBmb3IgcHJvYmxl bS0+c29sdXRpb24/ICBBICJzaCIgLT4gIyQoZmlsZS1hcHBlbmQgDQpiYXNoLW1pbmltYWwg Ii9iaW4vc2giKSBzdWJzdGl0dXRpb24gY2FuIGJlIHJlY29nbmlzZWQgb24gc2lnaHQgYXMg bm90IA0KcG9zc2libHkgYmVpbmcgYW55dGhpbmcgZWxzZSB0aGFuIGEgdGVjaG5pY2FsIGZp eCwgYW5kIHRoZW4gdGhlIA0Kc3Vic3Vic2VjdGlvbiBvbiB0ZWNobmljYWwgZml4ZXMgbWVu dGlvbnMgdGhhdCB0aG9zZSBtdXN0IGJlIGRvbmUgaW4gcGhhc2VzLg0KDQpPciwgYW5vdGhl ciBleHBsYW5hdGlvbjogcmV2aWV3ZXJzIHVzdWFsbHkgaGF2ZSBzZWVuIGEgbG90IG9mIG1v cmUgDQpwYWNrYWdlcyB0aGFuIGEgbmV3IHBhY2thZ2VyLiAgQmVjYXVzZSBvZiB0aGF0LCBh bmQgYmVjYXVzZSB0aGV5IGhhdmUgDQpmYW1pbGlhcmlzZWQgdGhlaXJzZWx2ZXMgd2l0aCBw b2xpY3ksIHRoZXkgaGF2ZSBvdmVyIHRpbWUgYXV0b21hdGljYWxseSANCmJ1aWx0IGEgbWVu dGFsICdyZXZlcnNlIGluZGV4JyBvZiBzb2x1dGlvbnMtPnByb2JsZW1zLg0KPj4gSSB0aGlu ayB3ZSBzaG91bGQgb3B0aW1pc2UgZm9yIHBhY2thZ2VycyBiZWZvcmUgcmV2aWV3ZXJzDQo+ IENvZGUgaXMgbW9yZSBvZnRlbiByZWFkIHRoYW4gd3JpdHRlbiwgc28gb3B0aW1pc2luZyBm b3IgdGhlIHJlYWRlciBpcw0KPiBvcHRpbWl6aW5nIGZvciB0aGUgcGFja2FnZXIgYXMgd2Vs bC4NCg0KV2hpbGUgYWxsIHJldmlld2VycyBhcmUgcmVhZGVycywgbm90IGFsbCByZWFkZXJz IGFyZSByZXZpZXdlcnMsIGFuZCANCnJldmlld2luZyB1c3VhbGx5IGhhcHBlbnMgb25seSBv bmNlLCBtYXliZSB0d2ljZSBwZXIgcGF0Y2guDQoNCj4+PiBSZWdhcmRsZXNzIG9mIHdoaWNo IHBhdGNoIHdlIHBpY2ssIGl0IHNob3VsZCBub3QgbWFuZGF0ZSBhDQo+Pj4gcGFydGljdWxh ciBzb2x1dGlvbiBpbiBwb3RlbnRpYWxseSBjb250ZW50aW91cyBjYXNlcywNCj4+DQo+PiBB Y3R1YWxseSB0aGUgd2hvbGUgcG9pbnQgd2FzIHRvIG1hbmRhdGUgYSBwYXJ0aWN1bGFyIHNv bHV0aW9uIGZvciB0aGUNCj4+IGNvbnRlbnRpb3VzIGNhc2VzLCBzZWUgU2hlcGhlcmQuDQo+ IEJ1dCBJIGRpc2FncmVlLg0KPiANCj4gTWVtZXMgYXNpZGUsIHBsZWFzZSByZWZyYWluIGZy b20gdGhlICJJJ20gcmlnaHQsIGRvIHRoaXMiIHN0eWxlICh3aGljaA0KPiBpcyBhbm90aGVy IHByb2JsZW0gd2l0aCB0aGUgInByb2JsZW0tY2VudHJpYyIgYXBwcm9hY2gpLA0KDQpJcyB0 aGlzIHJlZmVycmluZyB0byB0aGUgc3R5bGUgb2YgdGhlIGRvY3VtZW50YXRpb24gcGF0Y2g/ ICBJZiBzbzogaXQgDQpkb2VzIGV4cGxhaW4gd2h5IHRoZSAiZG8gdGhpcyIgaXMgcmlnaHQs IHNvIEkgZG9uJ3Qgc2VlIHRoZSBwcm9ibGVtLiAgRG8gDQp5b3UgaGF2ZSBhIHBhcnRpY3Vs YXIgcG9pbnQgb2YgdGhlIGRvY3VtZW50YXRpb24gaW4gbWluZCB5b3UgY29uc2lkZXIgDQp3 cm9uZyAoKik/DQoNCigqKSBwb2ludHMgSSBrbm93IG9mOg0KKiBrZWVwIGxpc3RzIC8gcmVt b3ZlIGxpc3RzIChmb3IgdGhlIGZvb3Rub3RlIGFib3V0IG5vdC15ZXQtcG9saWN5IG9uIA0K cmVtb3ZpbmcgdGhpbmdzIGluIHBhdGNoZXMpDQoqIHRoZSBndWlkaW5nIHByaW5jaXBsZXMg YXJlbid0IGd1aWRpbmcgcHJpbmNpcGxlcw0KDQo+IGJ1dCByYXRoZXINCj4gZm9jdXMgb24g d3JpdGluZyBhIHBhdGNoIHRoYXQgbWFrZXMgcmV2aWV3ZXJzIG5vdCBkaXNjYXJkIGEgcGF0 Y2ggZHVlDQo+IHRvIGZvcm1hbGl0aWVzLg0KDQpJIHRoaW5rIHRoZSBwYXRjaCAodjEgYW5k IHYyKSBzYXRpc2ZpZXMgdGhhdC4NCg0KPiBJZiB0aGUgc2hlcGhlcmQgdGhpbmcgaGFkIG5l ZWRlZCBhbiB1cHN0cmVhbSBwYXRjaCwNCj4gZXZlbiB3aXRoIGEgc25pcHBldCB0aGF0IHBh dGNoIGNvdWxkIGhhdmUgZWFzaWx5IGJlZW4gY3JlYXRlZCBieQ0KPiBjb252ZXJ0aW5nIHRo YXQgc25pcHBldCB0byBhIHNlZCwgc28gbW9yZSB0aW1lIHdhcyB3YXN0ZWQgZGViYXRpbmcg dGhhbg0KPiBvdmVyd29ya2luZy4NCg0KSSBkbyBub3Qgc2VlIHlvdXIgcG9pbnQgaGVyZSAt LSAjNTc1OTggaXMgYWJvdXQgZG9jdW1lbnRhdGluZy9tYWtpbmcgDQpwb2xpY3ksIG5vdCAn c2hvdWxkIHdlIHNwZW50IHRpbWUgb24gY29ycmVjdGluZyB0aGUgc2hlcGhlcmQgcGFja2Fn ZSB0byANCm1hdGNoIHBvbGljeSAvIGNvbnZpbmNpbmcgdGhlIG90aGVyIHBhcnR5IHRoYXQg dGhlIHN0YXR1cyBxdW8gbWF0Y2hlcyANCnBvbGljeScuDQoNCj4+PiBhbmQgYWxzbyBwb2lu dCB0b3dhcmRzIHRoZSByaWdodCBzb2x1dGlvbi7CoCBTZWUgb3VyIGRpc2N1c3Npb25zIG9u DQo+Pj4gdGhlIGluZGl2aWR1YWwgc29sdXRpb25zIG9uIHBvaW50cyBpbiB3aGljaCBJIGJl bGlldmUgeW91J3ZlDQo+Pj4gZXJyb3JlZC4NCj4+DQo+PiBUaGVzZSBhcmU6DQo+Pg0KPj4g KiB0aGUgdHlwbydzDQo+PiAqIGluY2x1ZGluZyAic2tpcHBpbmcgdGVzdHMgaW5kaWNhdGlu ZyBmYWlsdXJlIHVuZGVyIOKAmEZpeGluZw0KPj4gdGVjaG5pY2FsIGlzc3Vlc+KAmSINCj4+ ICogImRvbid0IG1lbnRpb24gZmlsZSBuYW1lcyBvZiBub24tZnJlZSB0aGluZ3MgaW4gcGF0 Y2hlcyINCj4+DQo+PiBEaWQgSSBtaXNzIGFueT8NCj4gSSdtIHByZXR0eSBzdXJlIHRoZXJl J3MgYWxzbyBhIGRpc2N1c3Npb24gb24gc3RvcmUgcGF0aCBlbWJlZGRpbmdzIGF0DQo+IHRo ZSB2ZXJ5IGxlYXN0LiAgRm9yZ2l2ZSBtZSBpZiBJIHRvbyBtaXNzZWQgc29tZXRoaW5nLg0K VGhlcmUgd2FzIGEgZGlzY3Vzc2lvbiBvbiBzdG9yZSBmaWxlIG5hbWUgZW1iZWRkaW5ncy4g IFRoZXJlIHdhcyBubyANCm1lbnRpb24gb2YgYW55IGVycm9ycyBpbiB0aGUgZG9jdW1lbnRh dGlvbiBvZiBzdG9yZSBmaWxlIG5hbWVzLiAgSUlSQywgDQp3ZSBhZ3JlZSBvbiBob3cgc3Rv cmUgZmlsZSBuYW1lIGVtYmVkZGluZ3MgbXVzdCBiZSBkb25lLiAgVGhlcmUgd2VyZSwgDQpo b3dldmVyLCBwcm9wb3NhbHMgdG8gZXh0ZW5kIHRoZSBkb2N1bWVudGF0aW9uIHRvIGNvdmVy IOKAmGhvdyB0byBlbWJlZOKAmSANCmluIG1vcmUgZGV0YWlsIChzdWJzdGl0dXRlKiArIHNl YXJjaC1pbnB1dC1maWxlIC4uLiksIGJ1dCBubyBlcnJvcnMuDQoNCkdyZWV0aW5ncywNCk1h eGltZS4NCg== --------------RneJSr4rW60YFuWvSkivYcO6 Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc" Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2 ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc /gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4 LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0 k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D =3DOVqp -----END PGP PUBLIC KEY BLOCK----- --------------RneJSr4rW60YFuWvSkivYcO6-- --------------A60oN2LySqwFEM12Dd7BpjjC-- --------------b304Y9bejnymBhUvwnTF0ap0 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYxuJgAUDAAAAAAAKCRBJ4+4iGRcl7op3 AQCYF8cmXphoV90U1eiSpXMlv1ETCRG9s0Prpbm/bTfHPQEAr76d7Ou/26rqpoEkxxsU+Hb6Ubc9 B3HI+QwSS8wO9g4= =BW3S -----END PGP SIGNATURE----- --------------b304Y9bejnymBhUvwnTF0ap0--
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.
Received: (at 57598) by debbugs.gnu.org; 9 Sep 2022 15:09:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 11:09:52 2022
Received: from localhost ([127.0.0.1]:35009 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oWfdf-0003BB-Im
for submit <at> debbugs.gnu.org; Fri, 09 Sep 2022 11:09:52 -0400
Received: from mail-ej1-f65.google.com ([209.85.218.65]:33655)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <liliana.prikler@HIDDEN>) id 1oWfdd-0003Ay-DI
for 57598 <at> debbugs.gnu.org; Fri, 09 Sep 2022 11:09:50 -0400
Received: by mail-ej1-f65.google.com with SMTP id lc7so4789376ejb.0
for <57598 <at> debbugs.gnu.org>; Fri, 09 Sep 2022 08:09:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:message-id:content-transfer-encoding:cc:to:subject
:date:from:from:to:cc:subject:date;
bh=DSH2NtZY3PQTC9fFJQkWMf/DkB/1uEtpmw/Cv0n+AMo=;
b=RB27Z8fDTtIJ2XFhBirBQANWfULF0jfkBugGZd4Rw0w6xoRT4pHsnPzA/oUwy+QU4c
2kl9ebzqGuLU31Dxvb3pYQyJilPkTfwNIlxb8T5Ae0DDDFUJ/3OFjLg1ORSnlBsNFYeh
ab1QRNL7dsEruUKgQElSScUflGRqFadVfFUXY/zNOEAwE6PuP2P8QRYrPsKlUAaJuGzI
DpqRrZ7H7yJUp2vkY4iuUiqW6gVEXnSyOtwbkJCIKDRmB7Xa7QsTalWn/pqmoTBGfJUF
tZ6/bPbrlTbMScxnr7FUdnP4Dz7kx5uRZSr9l/QWm7pIuwnwESrv50ygtNQgYNG0dfm1
pILQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=mime-version:message-id:content-transfer-encoding:cc:to:subject
:date:from:x-gm-message-state:from:to:cc:subject:date;
bh=DSH2NtZY3PQTC9fFJQkWMf/DkB/1uEtpmw/Cv0n+AMo=;
b=GjYi+GizlJchSsS5oFpLLPwS97G55b+1jnU1J3wI1q8liMrm1xfylMx0zEThGzQ0au
hsBjyJAgm5IBVlbfZXd+F5N7n2DSdNbv9OTUlG6CPEYEKtxk9wrxoQ91RNa2xEK0a9ZP
yxYv1sgGFt7ibI/jYgYo+e475hOVile106DKh/qZxy6M9mDIo4NuiSxgGPy+KE1AkeuX
OofFU2WSyfjTkn9qggVWn5BvcUt6xTpg6RQQE3xmfkhth6ONndQWbIZcgEOAb1Z35Fik
icuAn0tZBEvCNsOBLGlZnNDDfN8rRSZAS8NxZxyRul6Pa1v1b4vDnVCEZCROe4SAMQTK
93iw==
X-Gm-Message-State: ACgBeo1H2SPRi20lgo7GbcB57M8vAcIwahZa3dizEXvYeX2b8+f7xiGV
HGhz7nPsg2FKQQyrqk9WIS7hKCrqt+A=
X-Google-Smtp-Source: AA6agR5rA2mTbgIBetX28G58h2IWMDUL2Bom3iKU1G5I9NNBL3Cc5B7j6p74jt+jiXD6+YpXV6jpqA==
X-Received: by 2002:a17:907:2c75:b0:741:5871:4318 with SMTP id
ib21-20020a1709072c7500b0074158714318mr9954710ejc.532.1662736183642;
Fri, 09 Sep 2022 08:09:43 -0700 (PDT)
Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at.
[85.127.52.93]) by smtp.gmail.com with ESMTPSA id
kz5-20020a17090777c500b007708851c6f0sm389200ejc.146.2022.09.09.08.09.43
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 09 Sep 2022 08:09:43 -0700 (PDT)
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Date: Sat, 6 Aug 2022 08:55:03 +0200
Subject: [alternative PATCH] doc: Update contribution guidelines on
patches, etc.
to: 57598 <at> debbugs.gnu.org
Content-Transfer-Encoding: 8bit
Message-ID: <246b28ff9c402cfce8c2ef799d7d73b1dbb2cca9.camel@HIDDEN>
MIME-Version: 1.0
X-Spam-Score: 2.1 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: * doc/contributing.texi ("Snippets versus Phases"): Replaced
with... ("Modifying Sources"): ... this. List more use cases and some principles.
--- Hi Maxime, here is an update of my guidelines patch, incorporating the
changes Ludo’ requested and some of your bits, as well as fixing some omissions.
Content analysis details: (2.1 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (liliana.prikler[at]gmail.com)
2.1 DATE_IN_PAST_96_XX Date: is 96 hours or more before Received:
date
0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[209.85.218.65 listed in wl.mailspike.net]
0.1 PP_MIME_FAKE_ASCII_TEXT BODY: MIME text/plain claims to be ASCII
but isn't
0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
-0.0 T_SCC_BODY_TEXT_LINE No description available.
X-Debbugs-Envelope-To: 57598
Cc: Maxime Devos <maximedevos@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.1 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: * doc/contributing.texi ("Snippets versus Phases"): Replaced
with... ("Modifying Sources"): ... this. List more use cases and some principles.
--- Hi Maxime, here is an update of my guidelines patch, incorporating the
changes Ludo’ requested and some of your bits, as well as fixing some omissions.
Content analysis details: (1.1 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[209.85.218.65 listed in wl.mailspike.net]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (liliana.prikler[at]gmail.com)
2.1 DATE_IN_PAST_96_XX Date: is 96 hours or more before Received:
date
0.1 PP_MIME_FAKE_ASCII_TEXT BODY: MIME text/plain claims to be ASCII
but isn't
0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
-0.0 T_SCC_BODY_TEXT_LINE No description available.
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
* doc/contributing.texi ("Snippets versus Phases"): Replaced with...
("Modifying Sources"): ... this. List more use cases and some principles.
---
Hi Maxime,
here is an update of my guidelines patch, incorporating the changes Ludo’
requested and some of your bits, as well as fixing some omissions.
Cheers
doc/contributing.texi | 115 +++++++++++++++++++++++++++++++++++++-----
1 file changed, 102 insertions(+), 13 deletions(-)
diff --git a/doc/contributing.texi b/doc/contributing.texi
index 17a54f94cc..4894982259 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -451,7 +451,7 @@ needed is to review and apply the patch.
* Package Naming:: What's in a name?
* Version Numbers:: When the name is not enough.
* Synopses and Descriptions:: Helping users find the right package.
-* Snippets versus Phases:: Whether to use a snippet, or a build phase.
+* Modifying Sources:: When to use patches, snippets, or build phases.
* Emacs Packages:: Your Elisp fix.
* Python Modules:: A touch of British comedy.
* Perl Modules:: Little pearls.
@@ -708,20 +708,109 @@ Gettext}):
for the X11 resize-and-rotate (RandR) extension. @dots{}")
@end lisp
-@node Snippets versus Phases
-@subsection Snippets versus Phases
+@node Modifying Sources
+@subsection Modifying Sources
+@cindex patches, when to use
@cindex snippets, when to use
-The boundary between using an origin snippet versus a build phase to
-modify the sources of a package can be elusive. Origin snippets are
-typically used to remove unwanted files such as bundled libraries,
-nonfree sources, or to apply simple substitutions. The source derived
-from an origin should produce a source that can be used to build the
-package on any system that the upstream package supports (i.e., act as
-the corresponding source). In particular, origin snippets must not
-embed store items in the sources; such patching should rather be done
-using build phases. Refer to the @code{origin} record documentation for
-more information (@pxref{origin Reference}).
+
+Guix has three main ways of modifying the source code of a package,
+that you as a packager may use. Each one has its strengths and
+drawbacks, along with intended and historically derived use cases.
+These are
+
+@table @b
+
+@item patches
+If your package has a bug that takes multiple lines to fix, or a fix
+has already been accepted upstream, patches are the preferred way of
+eliminating said bug.@footnote{If you patch a bug that has hitherto
+not been reported or fixed upstream, consider also contacting upstream
+unless the bug and its fix are specific to Guix.}
+Refer to the @code{origin} record documentation
+(particularly the fields @code{patches}, @code{patch-inputs}, and
+@code{patch-flags}) for more information on how to use patches
+(@pxref{origin Reference}).
+When adding a patch, do not forget to also list it in
+@code{dist_patch_DATA} of @file{gnu/local.mk}
+
+As patches are applied to the origin of a package, they become part
+of the corresponding source. You can retrieve this source by
+invoking @code{guix build -S YOUR_PACKAGE}. This also means that
+modifying the patch causes two rebuilds: one for the source and one
+for the package built from it.
+
+Patches are limited in that they lack the expressiveness of Guile.
+If all changes are constrained to single lines, a patch might be much
+larger than the equivalent @code{substitute*}. It is further bad form
+to use a single patch to address multiple unrelated issues, whereas
+snippets can take ``multiple jobs''.
+
+@item snippets
+If your package contains non-free sources, these need to be removed
+through a snippet. This snippet should not only remove the sources in
+question, but also references to the removed sources in build scripts,
+documentation, and so on. @ref{Software Freedom}
+
+If your package bundles external libraries, snippets are the preferred
+way of removing said them. Unlike with non-free sources, it is not a
+requirement to remove @emph{all} bundled libraries, although doing so
+is very much preferred. Bundled libraries that are kept should be
+clearly indicated, preferrably with a reason as to why the bundled copy
+remains. As with non-free sources, references to the removed libraries
+should also be updated in the snippet.
+
+Refer to the @code{origin} record documentation
+(particularly the fields @code{snippet} and @code{modules}), for more
+information on how to use snippets (@pxref{origin Reference}).
+
+While snippets have all of Guile's core as well as extra @code{modules}
+available, their most useful procedure for @emph{editing} sources
+(rather than removing them), is @code{substitute*}, which can not deal
+with multi-line changes that well. Like patches, snippets become part
+of the corresponding source.
+
+@item build phases
+For modifications that retain the intended functionality of the
+package, build phases (usually between @code{unpack} and
+@code{configure}, sometimes between @code{configure} and @code{build})
+can be used. @ref{Build Phases}.
+Such changes include, but are not limited to, fixes of the
+build script(s) or embeddings of store paths (e.g. replacement of
+@file{/bin/sh} with @code{(search-input-file inputs "bin/sh")}).
+
+If you need to embed a store path, do so only inside a build phase.
+A workaround for patches that span multiple lines, is to use a variable
+such as @code{@@store_path@@} inside the patch and substitute the actual
+store path at build time via @code{substitute*}.
+
+Unlike patches and snippets, build phases do @b{not} become part of
+the corresponding source of a package, and should thus be avoided for
+changes that result in observably different runtime behaviour.
+On the other hand, the reduced overhead of unpacking, repacking and
+unpacking again might make for a slightly more pleasant debugging
+experience.
+
+@end table
+
+If your change does not neatly fit in any of the categories above, it
+is usually a matter of preference or convenience.
+
+@cindex auxiliary files
+
+Sometimes, you may need to add a new file, e.g. a source file or
+configuration file, to your package. As a matter of principle
+@b{auxiliary files} should be preferred over an equivalent
+@code{display} or @code{format} when creating non-trivial files, as that
+makes them easier to edit. The exact threshold for a non-trivial file
+might be subjective, though it should lie somewhere between
+10--20 lines.
+
+Auxiliary files are stored in the @file{gnu/packages/aux-files}
+directory and can be retrieved in a snippet or build phase via
+@code{search-auxiliary-file}.
+When adding an auxiliary file, do not forget to also list it in
+@code{AUX_FILES} of @file{Makefile.am}.
@node Emacs Packages
@subsection Emacs Packages
--
2.37.2
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.
Received: (at 57598) by debbugs.gnu.org; 9 Sep 2022 13:32:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 09:32:42 2022
Received: from localhost ([127.0.0.1]:32876 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oWe7c-0008VG-TC
for submit <at> debbugs.gnu.org; Fri, 09 Sep 2022 09:32:42 -0400
Received: from mailrelay.tugraz.at ([129.27.2.202]:7899)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <liliana.prikler@HIDDEN>) id 1oWe7Z-0008V6-NR
for 57598 <at> debbugs.gnu.org; Fri, 09 Sep 2022 09:32:39 -0400
Received: from kagayaki.fritz.box (85-127-52-93.dsl.dynamic.surfer.at
[85.127.52.93])
by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4MPH3h4PwXz1LXsR;
Fri, 9 Sep 2022 15:32:32 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4MPH3h4PwXz1LXsR
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at;
s=mailrelay; t=1662730353;
bh=JlOFPewa0DKs44hThj4/dpGiOvpO1u72noMUmD4yX54=;
h=Subject:From:To:Date:In-Reply-To:References:From;
b=FYFFf9RocV5xJx5Qc6OkXbDDU6gGyi98JRPLI8Cyo33IEm3S6ORg2SoKRtlPaT4WV
h1k+zjm2GIpf2DpHi43LW8GmJOMbi1cqgOGJyqfk2huIDhWlHcMvhuCBzh3zn4gjf1
DT8iW/EH073UICz/E4sLzqigVnbynUARSXIHSCAM=
Message-ID: <b74c40c57dff2a0ac6eee2a7a2124d8ab2d6314e.camel@HIDDEN>
Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc.
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
To: Maxime Devos <maximedevos@HIDDEN>, 57598 <at> debbugs.gnu.org
Date: Fri, 09 Sep 2022 15:32:31 +0200
In-Reply-To: <a24e8c5c-a986-3f6f-15a4-03caeb801e6d@HIDDEN>
References: <20220905160048.18173-1-maximedevos@HIDDEN>
<0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
<d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
<44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
<b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN>
<1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN>
<a24e8c5c-a986-3f6f-15a4-03caeb801e6d@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ
X-Spam-Scanner: SpamAssassin 3.003001
X-Spam-Score-relay: -0.4
X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 57598
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Am Freitag, dem 09.09.2022 um 13:14 +0200 schrieb Maxime Devos:
>
> > In descriptions, it is wise to do so because it helps software
> > stand on its own merits rather than just "being a clone of this
> > thing you aren't allowed to have" (this is real criticism pointed
> > at us from the proprietary software embracers). See for instance
> > minetest, which is described in terms of its features rather than
> > "being a Minecraft clone".
>
> Sentence might have been truncated?
Corrected above.
> Also, this is the package source field, not the description, I don't
> see how the "helps software stand on its own merits" applies to
> snippets of the package source.
Point taken, but imho it still makes sense to prefer keep lists over
remove lists. The GNU project encourages people to read the sources
after all.
> > > How does ignoring a test fix the technical issue identified by
> > > the test (sometimes, the technical issue being a bug in the test
> > > itself)?
> > It fixes the technical issue that an otherwise functional package
> > (w.r.t. the N tests that don't fail) builds. This is a
> > particularly
> > useful distinction with tests that require a network connection and
> > thus have to fail in a build container, or are known flaky upstream
> > and thus cause reproducibility issues.
>
> Network test: right (though preferably those would support a
> --no-network-tests test option or such).
>
> For flaky tests: those sound like bugs to me, ignoring them doesn't
> remove the flakyness.
Call it a bug or whatever, it is a technical issue that we deal with at
build time and not in the origin.
> > >
> > > > There still is the difference that phases are clearly delimited
> > > > while snippets are a block of code that shouldn't get too
> > > > large.
> > > Snippets are delimited clearly as well, though, with the
> > > 'snippet' field?
> > > And the limitations of snippet length and phases length are the
> > > same -- no limits, though conciseness is appreciate as always.
> > True, but phases can be made to do just one thing, whereas snippets
> > have to fix everything that's wrong in more or less one (begin
> > ...).
> > This is a noticable distinction.>
>
> You can do that in snippets too, with comments:
>
> (snippet
> #~(begin
> ;; Do the foo thing
> (foo)
> (foo-2 [...])
> [...]
> ;; Do the bar thing
> (bar)
> (bar-2 [...])
> [...]))
You can, but it's still wiser to just keep the snippet short enough so
you don't have to.
> >
> > > > I think my version at least hinted at this practice in a more
> > > > concise way, so it's not impossible to mention. [...]
> > > I agree it's possible -- as I replied previously:
> > > > I suppose a section could be added somewhere to properly
> > > > document
> > > > the 'embedding store file names' practice, and insert a
> > > > cross-reference,
> > > I don't think documenting the how of the practice should be done
> > > in this section, properly explaining 'search-input-file' /
> > > 'search-
> > > input-directory', 'inputs / native-inputs', 'bash' being an
> > > implicit
> > > input but you still have to add it to 'inputs' in some cases
> > > because
> > > of cross-compilation, this-package-input and this-package-native-
> > > input ... would make the
> > > subsubsection a bit too long I think, distracting from other
> > > situations, hence the proposal for a cross-reference.
> > > How about leaving the 'how to embed store file names' for a
> > > separate
> > > documentation patch and section, adding a cross-reference
> > > later?
> > See above, "I suppose a section could be added..." means I'm
> > somewhat indifferent to whether it's done now or later;
>
> Nitpick: you are quoting some text I wrote, so 'I' refers to me here,
> not you.
Ahh, my bad, the nesting level confused me.
> I would however very
> > much prefer a wording that points people toward this practice
> > existing,
> > even if they have to go look in the code for examples.
> > Alternatively,
> > a footnote for the most common case (search-input-file inputs
> > "bin/command") ought to suffice for the time being.
>
> Aside from the typo's and a few rephrasings, I'm done with the
> documentation. If someone wants to extend the section with such
> information, they can always do so later.
I haven't seen a v2 though. Am I correct in assuming that none of the
points we discussed in the last few mails are going to be addressed?
> >
> > IMHO, I think a reader who remembers the guiding principles should
> > see that it applies.
>
> Likely. But removing the explicit mention of the guiding principle
> still makes the logical reasoning incomplete, remembering has nothing
> to do with it. As I've written previously: ‘This has nothing do do
> with [...] and remembering, but rather with [...]’.
In that case, let me rephrase my criticism: "It passes the guidelines"
should not be part of the logical reasoning here. Otherwise, why not
have a guideline checklist at the end of each subsection (which would
be silly, obviously, but that's the point).
> > >
> > Also, your guiding principles are (with one exception) really just
> > invariants that ought to hold for the source field of a package.
>
> I don't know about the exceptions (I haven't counted them), but yes,
> indeed. I do not see the problem of this.
For the record, the exception is the "most convenient" bit you've
copied from my patch :)
> > As such, I think it would be easier to state "A package's source
> > should
> > be the smallest corresponding source in terms of uncompressed file
> > size. This corresponding source must consist only of free software
> > (note Free Software) and should build on all platforms supported by
> > upstream." Note how smallest naturally implies unbundling bundled
> > sources.
>
> This criterium on overly small sources. Often, a package's source
> contains things that is not used for the build or outputs and hence
> is not part of the corresponding source. Examples:
Note "should" rather than "shall" or "must", meaning that slightly
larger tarballs are still acceptable.
> * the source contains documentation that could be built and
> installed,
> but Guix doesn't do so yet. --> should be kept (unless non-free)
> * documentation that isn't meant to be built or installed
> (e.g. HACKING, PACKAGERS, ...) --> useful, shouldn't be removed.
> * .gitignore, .github, ... --> nothing wrong with removing those,
> but pointless, let's not waste our time with looking for those
> and removing them, even though doing so would make it smaller.
> * source files for platforms the upstream does not support
> yet/anymore
> (but with some volunteer effort (e.g. bugfixes), it might become
> a supported system again)
> --> removing them (e.g. as part of an overly-broad
> (delete-file-recursively
> "this-dir-has-bundling-albeit-not-all-of-it-is-bundling"))
> can be OK-ish, but removing them for 'minimality' is
> pointless.
I see you're nitpicking for the sake of the argument, but none of the
examples you provide (safe for the bundling one) add much cost to
either packing or unpacking. Thus, I'm pretty sure we can ignore them
for practical purposes. That being said, if you have a better
formulation, please do tell.
>
> > > > I still find this wording very confusing. Perhaps "To add new
> > > > functionality, a patch is almost always the best choice. For
> > > > one,
> > > > it is likely that the new functionality requires changing
> > > > multiple
> > > > lines of source code, which is more convenient to do with a
> > > > patch
> > > > than with a snippet. Further, patches can be taken from and
> > > > submitted to upstreams more easily. If your patch has not been
> > > > submitted to upstream, consider doing so."
> > > It loses some information (that patches are preferred) and
> > > (after re-adding the conclusion) is more verbose, which appears
> > > to be considered very important.
> > Which conclusion is there to re-add?
>
> "patches are preferred"
>
> The conclusion is already stated
> > in the beginning: patches are almost always the best choice. Then
> > two
> > reasons as for why. The part w.r.t. upstreaming changes has also
> > been
> > addressed.
>
> While I consider that policies should have "best choices" coinciding
> with "preferred" and that not doing so would be illogical, people,
> projects, decisions ... are far from always logical.
>
> Because of this, people cannot assume that the 'best choices' are
> 'preferred', so it needs to be mentioned explicitly that these 'best
> choices' are actually 'preferred'.
In that case, simply write preferred choice?
> > I'm using enumeration as a super term here, which can be
> > ((sub)sub)sections, chapters, list elements, whatever, and my claim
> > is that we barely have enough principles to allow the use of a
> > plural.
>
> In English, things are either plural or singular. Everything >= 2 is
> plural. There number of principles, however we count them, is, at
> least, 2. Consequently, the principles are plural, not singular.
> Treating the principles as singular is simply grammatically
> incorrect.
Correction: Everything that isn't exactly 1 is plural in English,
including 0, with perhaps the exception of -1 also using singular.
> Maybe it is barely allowed to be plural, but English grammar doesn't
> care about that -- it is definitively disallowed to be singular, only
> plural remains.
Note that my argument isn't about English grammar, it uses English
grammar.
> > Adding to that, now that I think of it, I also doubt their
> > usefulness in guiding. "Use whatever feels convenient, but note
> > that that might be subjective" is more useful at the end of the
> > section when a user didn't find what they were looking for than at
> > the start.
>
> The introduction has a set of guiding principles, from with concrete
> cases are built. By adding another principle at the end, the cases
> cannot make use of the "use [...] convenient" principle.
>
> Additionally, now the user has to look at _two_ places to find the
> guiding principles -- at the beginning, and at the end. Worse,
> the beginning does not have a cross-reference to the end, so since
> the set at the beginning is presented as exhaustive, the user might
> not know there is another guiding principle.
>
> And even if they did read through the whole section (even though they
> should only have to read the introduction and the relevant worked-out
> case), assuming they read through it in a linear fashion, due to the
> new guiding principle that wasn't alluded to at the beginning, they
> have to redo their mental model of "Modifying Sources" as this
> principle could invalidate things.
This shows both a problem with your structure, but more importantly, a
failure to understand what I meant when I wrote "use whatever is
convenient" in my own patch. This principle *can* only work for cases
in which there is *no clearly established practice*, thus putting it at
the end *after having enumerated all practices* is the logical choice.
With your structure, you have to bend it sideways to shoehorn it in
with the other principles.
> > At the risk of responding jokingly to what was meant serious: I
> > didn't know we suddenly gained 20 guiding principles.
>
> 25 lines are for the guiding principles (sometimes referring to a
> principle of elsewhere in Guix, sometimes a new principle for
> "Modifying Sources"). You proposed to 'cache' them somehow. In
> Guile, to cache something, you can use 'delay/force'. But this
> increases the amount of code (due to the additional use of 'delay'),
> instead of decreasing.
>
> The documentation equivalent (whatever that might be, I am not seeing
> one myself) would then also be at least as long, maybe even a little
> longer due to the use of 'delay'.
Okay, so I did misunderstand those 25 lines as 25 lines within the text
calling back to those guiding principles rather than 25 lines for the
guiding principles themselves. Still, 25 lines are a little much,
especially given that the bulk of it explains the semantics of the
packages' source field.
> >
> > > I suppose table items might take two less line or so less than
> > > subsubsections, but I don't think that's sufficient reason to
> > > step away from a nice section structure.
> > Another reason is that you can end a table in the middle of a
> > section, which you can't do with subsections. Hence why I'm able
> > to put a remark at the bottom, which you have to clumsily fit into
> > the top.
>
> I can, indeed, not put the 'convenience principle' at the bottom,
> except perhaps by adding a new subsubsection, and for tables adding
> such a remark at the bottom is indeed more convenient.
>
> However, I don't see the 'have to clumsily' here -- as explained
> elsewhere, I believe that the 'convenience principle' shouldn't be
> separated from the other principles and that it fits nicely next to
> the the principles --- there is no 'have to', because I choose for
> this, and I am not seeing any 'clumsiness' here.
I think we'd have to debate choice vs. force here which would be a
rather long aside, but to make my argument short, your choice of how to
structure this section (table vs subsections) directly influences your
"choice" where to place particular information in a way that might
inhibit natural information flow.
> >
> >
> >
> > > The patch does this, currently. It already proposes a number of
> > > hammers (patches, snippets and phases) and purposes (adding new
> > > functionality, fixing technical issues, unbundling, ...).
> > > Also, the scenario "oh no, however will I put this nail into a
> > > wall"
> > > actually happened -- see the Shepherd discussion, where there was
> > > a lot of disagreement on how nails (= small work-around in the
> > > Makefile) should be put in walls (= patches, snippet, phase?).
> > > It
> > > was the whole reason to start writing a documentation patch.
> > You might want to add a link here if it supports your argument, but
> > without looking at the discussion this rather sounds like "oh no, I
> > have three hammers, which one do I pick?" – which, fair enough, is
> > still a problem, but one that neither of our patches would cause
> > imho.
>
> As I think I've written previously, the whole point was to solve that
> problem. For the discussion, see:
>
> * https://issues.guix.gnu.org/54216
> *
> https://yhetil.org/guix/c4c0a071-2e03-d4d6-6718-05424d21d146@HIDDEN/
> *
> https://yhetil.org/guix-devel/84e13ef7d437062df5cca51a12e6da54929e0176.camel@HIDDEN/
>
> Not solving the problem defeats the whole point, as the purpose is to
> solve that problem.
I think we might be disagreeing about what constitutes "solving the
problem" here. Correct me if I'm wrong, but to me it seems any
scenario that is not covered by whatever patch is applied counts as
"not having solved the problem". I personally find this line of
reasoning questionable, as there are perfectly valid reasons why
multiple tools could apply.
Take the problem of embedding a store path. You could for instance
replace all occurences of "sh" with /gnu/store/.../bin/sh, or you could
first replace them in a patch with "@sh@" and then replace that with
/gnu/store/.../bin/sh. Of course, you rarely have to do the latter and
the former is simpler, hence why you will often see the former, but
that doesn't mean the latter is invalid.
>
>
> > >
> > > > And if they don't find anything, they see the handy little line
> > > > at the bottom saying "use whatever you think is convenient".
> > > Nowhere did the patch imply that the listed cases were all cases.
> > > In fact, in two places in the introduction it is implied that the
> > > examples are not exhaustive, and that they can choose according
> > > to convenience [...]
> > Emphasis on handy little line rather than needing to be told twice
> > (particularly if people have no idea what to expect due to not
> > having looked at the worked-out cases yet).
>
> They don't need to be told twice. Also, my patch also has that handy
> little line (albeit differently worded), see the 'guiding
> principles'.
>
> Also, on the 'no idea what to expect' -- this is exactly the same for
> your patch too? In both patches, if the user only reads the
> introduction and conclusion (if any) and doesn't read the actual
> (relevant examples)/(explanation of patches, snippets, phases), then
> that's their problem.
I do think a table in the middle of the section is hard to ignore, but
suppose for the sake of argument that they do, then in my case they
will have learned exactly nothing. In your case, they will know the
"guiding principles" and then interpret them to mean whatever they
think it means. I'm not convinced mine is worse here.
> > >
> > > > I also expand a little on the benefits and drawbacks of
> > > > these approaches as you would when describing design patterns.
> > > This is also done in my patch. [...]
> > This is not about the contained information, but the structure of
> > the contained information.
> >
> > My solution->problem style follows roughly this style:
> > 1. solution
> > 2. problems it is known to solve
> > 3. how to use
> > 4. properties, caveats, etc.
> >
> > Your problem->solution style roughly has the following:
> > 1. problem
> > 2. (set of) solution(s)
> > 3. if more than one solution, maybe a help to select
>
> Also, in no particular order
>
> 4.: how to use
> 5.: explanation why it is preferred (properties, caveats?)
No particular order is problematic, but more importantly if a
technology appears more than once (guaranteed by the pigeonhole
principle), then either its properties get repeated (not good for
length) or scattered (not good for the flow you want). Again, a
structural problem.
> > This makes it so that people might have to go to a different
> > subsection than the one they read for their solution to find out
> > about potential caveats, e.g. not embedding store paths in a
> > snippet.
>
> I assume their problem was "X doesn't find Y". This being a
> technical issue, they go to "Fixing technical issues". In that
> subsubsection, there are the words:
>
> > Secondly, if the fix of a technical issue embeds a store file name,
> > then it has to be a phase. Otherwise, if the store file name were
> > embedded in the source, the result of @command{guix build --source}
> > would be unusable on non-Guix systems and also likely unusable on
> > Guix systems of another architecture.
>
> so they actually do know of the caveat 'don't embed store paths in a
> snippet, do it in a phase instead', and they did not need to go to a
> different subsubsection.
Typical happy path.
> > >
> > > > Your problem->solution approach instead leaves people wondering
> > > > when their particular use case has not been described.
> > > See my reply to ‘And if they don't find anything, they see the
> > > handy little line at the bottom saying "use whatever you think is
> > > convenient’.
> > > > It gives them a solution rather than the tools to build
> > > > solutions with.
> > > It does give the tools: snippets, patches and phases.
> > As far as I read, it describes none of those. It puts out guiding
> > principles and some already worked-out cases.
> Here are the descriptions:
>
> > Guix has tree main ways of modifying the source code of a package,
> > that you as a packager may use. These are patches, snippets and
> > phases
>
> Once the user knows _which_ of the three they should use (by
> consulting the following subsubsections), they can then search for
> 'patch', 'snippet' and 'phases' in the manual for more information,
> no need to duplicate that information.
Point taken, but imho cross-references are nice for those who just
learned "okay, I now know I need to solve my technical problem with a
phase, how do I do that?"
>
> > > Also, "giving the tools to build solutions with" does not help
> > > with the problem that I aimed to solve -- there was disagreement
> > > on what the appropriate tools are (see: Shepherd), so it not just
> > > needs to give the tools, but also the solutions.
> > I don't see how my patch lacks this information however.
>
> IIUC, the raw information should usually be indeed all there, but the
> user has to consult _all_ of the sections to determine which option
> (patch, snippet, phase) is appropriate, having to assemble all the
> information is (a) a waste of time and (b) can lead to different
> interpretations and conclusions (see: Shepherd).
>
> More concretely, I cannot use your patch to decide between phases,
> snippets and patches for the Shepherd issue:
>
> * none of three appear to be forbidden by your documentation
> * there is no recommendation for 'patches' (IIRC it wasn't accepted
> upstream and there was no intent to submit it upstream, it being
> really a Guile bug, not a Shepherd bug)
> * there is no recommendation for snippets (it's all free, no
> bundling)
> * build phases are 'to be avoided' (but not forbidden), as it
> resulted
> in observably different runtime behaviour (being a bug fix)
>
> -- three (or at best, two, if build phases are discounted) options
> remain. Myself, I would then consider 'snippets' to be the most
> convenient, but some others (see: Shepherd, IIRC) would really want a
> patch instead, because 'patches can be reverted' or something like
> that.
>
> As such, you are giving the tools (snippets / patches / phases, some
> downsides and upsides), but different people can construct different
> solutions from those tools even in the same situation, leading to
> conflicts.
>
> If I use my patch instead, I go to "fixing technical issues". This
> section tells me to use a patch or a snippet. As the fix is not
> Guix-specific, it recommends a patch to save time when upstreaming.
> Conclusion: write a patch. It was a Guile bug, so the fix was a
> patch to Guile. But that would take time and upstream took the
> responsibility for a fix, so the 'efficient time thing' doesn't
> really apply and a small work-around (setting optimisation flags)
> suffices.
>
> In this situation, the subsubsection doesn't care at all if you go
> for a snippet, so apply the last guiding principle: go for the
> simplest thing: a snippet. (Unless you already have a patch, then a
> patch is simplest.)
> Does someone else have a different idea on what's simplest? Doesn't
> really matter, ‘Sometimes this is subjective, which is also fine’.
I do get the impression that this patch simply codifies what you feel
is right based on the shepherd situation rather than thinking about the
general case, which is why my patch makes weaker statements here. If
this issue could have been avoided with a #:make-flag, we would have
used that.
More importantly, I fail to see the superiority of your patch here.
IIUC neither patch offers a unique solution to the shepherd thing, so
the room for debate remains. You could claim that my patch offers more
room, which fair enough, it does, but on the same token it allows
people to see that the guidelines have been followed and the patch can
be applied.
> > In particular, for review purposes, mine should be easier to work
> > with. For instance, the reviewer sees a hash embedded in a
> > snippet, sees in the snippet entry that you shouldn't do that, and
> > can thus say "nope, don't do a snippet here".
>
> I think we should optimise for packagers before reviewers
Code is more often read than written, so optimising for the reader is
optimizing for the packager as well.
> > Regardless of which patch we pick, it should not mandate a
> > particular solution in potentially contentious cases,
>
> Actually the whole point was to mandate a particular solution for the
> contentious cases, see Shepherd.
But I disagree.
Memes aside, please refrain from the "I'm right, do this" style (which
is another problem with the "problem-centric" approach), but rather
focus on writing a patch that makes reviewers not discard a patch due
to formalities. If the shepherd thing had needed an upstream patch,
even with a snippet that patch could have easily been created by
converting that snippet to a sed, so more time was wasted debating than
overworking.
> > and also point towards the right solution. See our discussions on
> > the individual solutions on points in which I believe you've
> > errored.
>
> These are:
>
> * the typo's
> * including "skipping tests indicating failure under ‘Fixing
> technical issues’"
> * "don't mention file names of non-free things in patches"
>
> Did I miss any?
I'm pretty sure there's also a discussion on store path embeddings at
the very least. Forgive me if I too missed something.
Cheers
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.
Received: (at 57598) by debbugs.gnu.org; 9 Sep 2022 12:31:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 08:31:05 2022
Received: from localhost ([127.0.0.1]:60998 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oWdA0-0006xj-7B
for submit <at> debbugs.gnu.org; Fri, 09 Sep 2022 08:31:05 -0400
Received: from albert.telenet-ops.be ([195.130.137.90]:52404)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <maximedevos@HIDDEN>) id 1oWd9w-0006xI-KE
for 57598 <at> debbugs.gnu.org; Fri, 09 Sep 2022 08:31:03 -0400
Received: from localhost.localdomain
([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16])
by albert.telenet-ops.be with bizsmtp
id HoWy2800N20ykKC06oWyqS; Fri, 09 Sep 2022 14:30:58 +0200
From: Maxime Devos <maximedevos@HIDDEN>
To: 57598 <at> debbugs.gnu.org
Subject: [PATCH v2] doc: Update contribution guidelines on patches, etc.
Date: Fri, 9 Sep 2022 14:30:51 +0200
Message-Id: <20220909123051.15747-1-maximedevos@HIDDEN>
X-Mailer: git-send-email 2.37.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22;
t=1662726659; bh=ShuyIi5oL2KLu5raMueIVayMxJvraM6D4TAkISgfEBU=;
h=From:To:Cc:Subject:Date;
b=WhNwaFDfVGb1lt3/LKr8fbyZWF1n1GX/h40LURo36dX5Gf81MjofENZePz+wp6/0j
4ovILLK/DSRrY0ab0eftwP1dwT7rNgIeYbfp11QQoY915TgzvH/uUhr0bkdO4iK2MQ
x4/7qK8iA8sHzcVcO84nh5y1g5/B7EJiob4L9A8AeGm0kcu0NFf+CcE+HnOYVd7H2k
/tzJ0Y2K+ZDIc2WOA6DbP2z3seyXX2N8CtBn0maIvZWUaq5OFvBBZBanLrkHmbk5Re
+EeAbRdGW/RhksxuddT2rYzUpVMB/8wpsOdNi+OPuIHeQjzsw6yWGgi92WwAsSFBI2
hs+j5qc+tf9dQ==
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 57598
Cc: Maxime Devos <maximedevos@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
* doc/contributing.texi (Modifying Sources): Replaced with ...
("Modifying Sources"): ... this. List more use cases and some principles.
This patch incorporates some text written by Liliana Marie Prikler. The
structure is based on a proposal by Julien Lepiller. The text has been
revised based on reviews by David Larsson and blake.
(! remove following text before committing !)
Unless someone finds some more typo's or such, this is the final version for
me, as it has become a time sink with diminishing returns.
Changes since previous version:
- typofix: tree -> three
- third and fourth principle are merged
- corrected @subsection -> @subsubsection
Not changed:
- no additional information on bugfixes even though initially proposed, I'm
done with the patch, if you'd like such information please write a follow-up
patch.
- I didn't add 'no naming the file names of non-free things in the snippets’,
as I don't think this is currently policy and it seems rather inconvenient
to work with (e.g.: then we wouldn't be able to keep records of what parts
still need to be replaced with something free in the comments)
- going from ‘problem -> solution’ to ‘solution -> problem’ -- would partially
defeats the point of the patch.
- going through the two different patches and take the most concise phrasing
(other people in 57598 <at> debbugs.gnu.org didn't agree to my proposal, also,
I'm about done with the patch
- ‘subsubsections -> item / table’: I haven't read a convincing explanation
on why item / table is better here.
---
doc/contributing.texi | 140 +++++++++++++++++++++++++++++++++++++-----
doc/guix.texi | 2 +-
2 files changed, 126 insertions(+), 16 deletions(-)
diff --git a/doc/contributing.texi b/doc/contributing.texi
index 02c7c5ae59..bd2ae8d9b6 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -441,7 +441,7 @@ needed is to review and apply the patch.
* Package Naming:: What's in a name?
* Version Numbers:: When the name is not enough.
* Synopses and Descriptions:: Helping users find the right package.
-* Snippets versus Phases:: Whether to use a snippet, or a build phase.
+* Modifying Sources:: Whether to use a snippet, or a build phase.
* Emacs Packages:: Your Elisp fix.
* Python Modules:: A touch of British comedy.
* Perl Modules:: Little pearls.
@@ -698,20 +698,130 @@ Gettext}):
for the X11 resize-and-rotate (RandR) extension. @dots{}")
@end lisp
-@node Snippets versus Phases
-@subsection Snippets versus Phases
-
-@cindex snippets, when to use
-The boundary between using an origin snippet versus a build phase to
-modify the sources of a package can be elusive. Origin snippets are
-typically used to remove unwanted files such as bundled libraries,
-nonfree sources, or to apply simple substitutions. The source derived
-from an origin should produce a source that can be used to build the
-package on any system that the upstream package supports (i.e., act as
-the corresponding source). In particular, origin snippets must not
-embed store items in the sources; such patching should rather be done
-using build phases. Refer to the @code{origin} record documentation for
-more information (@pxref{origin Reference}).
+@node Modifying Sources
+@subsection Modifying Sources
+
+Guix has tree main ways of modifying the source code of a package, that
+you as a packager may use. These are patches, snippets and phases.
+Each one has its strengths and drawbacks. To decide between the three,
+there are a few guiding principles to satisfy simultanuously where
+possible:
+
+@itemize
+@item
+In principle, Guix only has free software; when the upstream source
+contains some non-free software, it has to be removed such that
+@command{guix build --source} returns the ‘freed’ source code rather than
+the unmodified upstream source (@pxref{Software Freedom}).
+@item
+The source of the package needs to correspond to what is actually built
+(i.e., act as the corresponding source), to fulfill our ethical and
+legal obligations.
+@item
+The source needs to actually work, not only on your Guix system but also
+on other Guix systems. It preferably should also work on non-Guix
+systems if supported by upstream. This requires some care for
+substitutions involving store items and other architecture-specific
+changes.
+@item
+When there is more than one way to do something, choose whichever method
+is the simplest. Sometimes this is subjective, which is also fine.
+What matters is that you use techniques that are common within the
+community (i.e., patterns that appear throughout @code{gnu/packages/...})
+and are thus clearly legible for reviewers.
+@end itemize
+
+To make things more concrete and to resolve conflicts between the
+principles, a few cases have been worked out:
+
+@subsubsection Removing non-free software
+Non-free software has to be removed in snippets; the reason is that
+patches or phases will not work.
+
+For patches, the problem is that a patch removing a non-free file
+automatically contains the non-free file@footnote{It has been noted that
+git patches support removing files without including the file in the
+patch in
+@url{https://yhetil.org/guix/8b13e899-eb60-490b-a268-639249698c81@@www.fastmail.com/}. If
+it is verified that the @command{patch} utility supports such patches,
+this method can be used and this policy adjusted appropriately.}, and we
+do not want anything non-free in Guix even if only in its patches.
+
+For phases, the problem is that phases do not influence the result of
+@command{guix build --source}.
+
+@subsubsection Removing bundled libraries
+Bundled libraries should not be removed with patches, because then the
+patch would contain the full bundled library, which can be large. They
+can be removed either in snippets or phases, often using the procedure
+@code{delete-file-recursively}. There are a few benefits for snippets here:
+
+When using snippets, the bundled library does not occur in the source
+returned by @code{guix build --source}, so users and reviewers do not
+have to worry about whether the bundled library contains malware,
+whether it is non-free, if it contains pre-compiled binaries ... There
+are also less licensing concerns: if the bundled libraries are removed,
+it becomes less likely that the licensing conditions apply to people
+sharing the source returned by @command{guix build --source}, especially if
+the bundled library is not actually used on Guix systems.@footnote{This
+is @emph{not} a claim that you can simply ignore the licenses of
+libraries when they are unbundled and replaced by Guix packages -- there
+are less concerns, not none.}
+
+As such, snippets are recommended here.
+
+@subsubsection Fixing technical issues (compilation errors, test failures, other bugs ...)
+Usually, a bug fix comes in the form of a patch copied from upstream or
+another distribution. In that case, simply adding the patch to the
+@code{patches} field is the most convenient and usually does not cause
+any problems; there is no need to rewrite it as a snippet or a phase.
+
+If no ready-made patch already exists, then choosing between a patch or
+a snippet is a matter of convenience. However, there are two things to
+keep in mind:
+
+First, when the fix is not Guix-specific, upstreaming the fix is
+strongly desired to avoid the additional maintenance cost to Guix. As
+upstreams cannot accept snippets, writing a patch can be a more
+efficient use of time. Secondly, if the fix of a technical issue embeds
+a store file name, then it has to be a phase. Otherwise, if the store
+file name were embedded in the source, the result of @command{guix build
+--source} would be unusable on non-Guix systems and also likely unusable
+on Guix systems of another architecture.
+
+@subsubsection Adding new functionality
+To add new functionality, a patch is almost always the most convenient
+choice of the three -- patches are usually multi-line changes, which are
+convenient to do with patches and inconvenient to do with phases or
+snippets. This choice is usually also compatible with all the guiding
+principles. As such, patches are preferred. However, as with bug
+fixes, upstreaming the new functionality is desired.
+
+@subsubsection How to add patches
+Refer to the @code{origin} record documentation (particularly the fields
+@code{patches}, @code{patch-inputs}, and @code{patch-flags}) for
+information on how to use patches (@pxref{origin Reference}). When
+adding a patch, do not forget to also list it in @code{dist_patch_DATA}
+of @file{gnu/local.mk}.
+
+@subsubsection How to add files
+New source files can be added in phases or snippets, by using
+@b{auxiliarry files}. Auxiliary files are stored in the
+@file{gnu/packages/aux-files} directory and can be retrieved (in a
+snippet or a phase) with @code{search-auxiliary-file}. When adding an
+auxiliary file, do not forget to also list it in @code{AUX_FILES} of
+@file{Makefile.am}.
+
+Another option for adding new files, is to use procedures such as
+@code{display}, @code{format} and @code{call-with-output-file}. As a
+matter of principle, auxiliary files ought to be preferred over an
+equivalent @code{call-with-output-file} when creating non-trivil files,
+as that makes them easier to edit. The exact threshold for a
+non-trivial file might be subjective, though it should lie somewhere
+between 10--20 lines.
+
+Currently, there is no policy on deciding between phase and snippets for
+adding new files, except for the guiding principles.
@node Emacs Packages
@subsection Emacs Packages
diff --git a/doc/guix.texi b/doc/guix.texi
index 7bce8a567c..042ab3bd8a 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -70,7 +70,7 @@ Copyright @copyright{} 2019 Jakob L. Kreuze@*
Copyright @copyright{} 2019 Kyle Andrews@*
Copyright @copyright{} 2019 Alex Griffin@*
Copyright @copyright{} 2019, 2020, 2021, 2022 Guillaume Le Vaillant@*
-Copyright @copyright{} 2020 Liliana Marie Prikler@*
+Copyright @copyright{} 2020, 2022 Liliana Marie Prikler@*
Copyright @copyright{} 2019, 2020, 2021, 2022 Simon Tournier@*
Copyright @copyright{} 2020 Wiktor Żelazny@*
Copyright @copyright{} 2020 Damien Cassou@*
base-commit: a44e08337d15b3f254a35d0311663c2bbd501852
prerequisite-patch-id: 0caac311875ee39cb48573657ebb960e90da6dfb
prerequisite-patch-id: 418285493d89ebf102175902d9b09a0174e88190
prerequisite-patch-id: 3c39eb839d9d3ff3fca6cd98621a5d5c411b7af4
prerequisite-patch-id: 8d5662e874c469f5ee496ef5181cf2d0a30ad1d8
prerequisite-patch-id: 26513c3b3b86963df718ee41d14a25d1cc6a8f3f
prerequisite-patch-id: 2b2497e2edec0afc48ebadd6f09f0c661c466127
prerequisite-patch-id: 2712efb97bf33985fd0658e4dd8e936dc08be5fe
prerequisite-patch-id: 9d2409b480a8bff0fef029b4b095922d4957e06f
--
2.37.2
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.Received: (at 57598) by debbugs.gnu.org; 9 Sep 2022 11:14:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 07:14:38 2022 Received: from localhost ([127.0.0.1]:60941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oWbxz-0002sz-Ce for submit <at> debbugs.gnu.org; Fri, 09 Sep 2022 07:14:38 -0400 Received: from baptiste.telenet-ops.be ([195.130.132.51]:56248) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <maximedevos@HIDDEN>) id 1oWbxt-0002si-H0 for 57598 <at> debbugs.gnu.org; Fri, 09 Sep 2022 07:14:34 -0400 Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16] ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]) by baptiste.telenet-ops.be with bizsmtp id HnER2800P20ykKC01nERlQ; Fri, 09 Sep 2022 13:14:27 +0200 Message-ID: <a24e8c5c-a986-3f6f-15a4-03caeb801e6d@HIDDEN> Date: Fri, 9 Sep 2022 13:14:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Content-Language: en-US To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 57598 <at> debbugs.gnu.org References: <20220905160048.18173-1-maximedevos@HIDDEN> <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN> <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN> <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN> <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN> <1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN> From: Maxime Devos <maximedevos@HIDDEN> Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc. In-Reply-To: <1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------ztoDhl3zz8S7BeO6MhLpiOLo" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1662722067; bh=1Y1FS593G81grZ4wkUEizHFCc0seFdnJfROIZljCB3A=; h=Date:To:References:From:Subject:In-Reply-To; b=dI9rZonTyHxJI5VccKRyRLeOgT2KAA5j9ep4DsaH4ZC4AXqeojOqv/ptfDLNd5zHt Bd3T079JVIA4YxFrXbJpS+qFgvWOiJ3tVOQNO/qF9mmYAZerkeiJyFjwD/1VRTlMi1 zE/jyIon2Qufagw/Rl8HXmtw1yEE0SsRx8Wpz4selzayeYdsgqDbjlT++CbJ82LTdQ 7Jg7SOPwCmRnWoRoopbPr5tF/qGxaNftiMTDED5zNIPpoN8MKsd00kIjj0YpyWi7EP 9aJtD/UXt3pDOOaUy4iqfU0TJIqQQF4JEJrSFw0vpYrgmOFx3C3OVVeFxrNHhrjL5x ZlpH30Grn5INA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 57598 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------ztoDhl3zz8S7BeO6MhLpiOLo Content-Type: multipart/mixed; boundary="------------LEdw0eVxVIORtTBS4903Yefe"; protected-headers="v1" From: Maxime Devos <maximedevos@HIDDEN> To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 57598 <at> debbugs.gnu.org Message-ID: <a24e8c5c-a986-3f6f-15a4-03caeb801e6d@HIDDEN> Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc. References: <20220905160048.18173-1-maximedevos@HIDDEN> <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN> <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN> <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN> <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN> <1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN> In-Reply-To: <1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN> --------------LEdw0eVxVIORtTBS4903Yefe Content-Type: multipart/mixed; boundary="------------tRDWi1bv5GRDIutW2FCxCszJ" --------------tRDWi1bv5GRDIutW2FCxCszJ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQoNCk9uIDA5LTA5LTIwMjIgMTA6MDQsIExpbGlhbmEgTWFyaWUgUHJpa2xlciB3cm90ZToN Cj4gQW0gRG9ubmVyc3RhZywgZGVtIDA4LjA5LjIwMjIgdW0gMTM6MTIgKzAyMDAgc2Nocmll YiBNYXhpbWUgRGV2b3M6DQo+PiBPbiAwNy0wOS0yMDIyIDEwOjA5LCBMaWxpYW5hIE1hcmll IFByaWtsZXIgd3JvdGU6DQo+Pj4gQW0gRGllbnN0YWcsIGRlbSAwNi4wOS4yMDIyIHVtIDIy OjIxICswMjAwIHNjaHJpZWIgTWF4aW1lIERldm9zOg0KPj4+PiBJdCBpcywgdG8gbXkga25v d2xlZGdlLCBub3QgZm9yYmlkZGVuIHRvIG1lbnRpb24gbm9uLWZyZWUNCj4+Pj4gc29mdHdh cmUgYnkgbmFtZSBpbiBjb2RlLCBhcyBsb25nIGFzIGl0cyBub3QgYSByZWNvbW1lbmRhdGlv bg0KPj4+PiAoZXhwbGljaXQgb3IgaW1wbGllZCkuDQo+Pj4gSW5kZWVkLCB0aGVyZSBpcyBu byBoYXJkIHJ1bGUsIGhlbmNlICJhdm9pZCIgcmF0aGVyIHRoYW4gImZvcmJpZCIuDQo+PiBX aGF0IEkgYWxzbyBtZWFudCBpcywgdGhhdCB0byBteSBrbm93bGVkZ2UgdGhlcmUgaXMgbm8g c29mdCBydWxlDQo+PiBlaXRoZXIuICBBZ2Fpbiwgd2h5IHNob3VsZCB3ZSBhdm9pZCB0aGlz LCB3aGF0J3MgdGhlIHBvaW50IG9mIHRoYXQ/DQo+IEluIGRlc2NyaXB0aW9ucywgaXQgaXMg d2lzZSB0byBkbyBzbyBiZWNhdXNlIGl0IGhlbHBzIHNvZnR3YXJlIHN0YW5kIG9uDQo+IGl0 cyBvd24gbWVyaXRzIHJhdGhlciB0aGFuIGp1c3QgImJlaW5nIGEgY2xvbmUgb2YgdGhpcyB0 aGluZyB5b3UgYXJlbid0DQo+IGFsbG93ZWQgdG8gaGF2ZSIgKHRoaXMgaXMgcmVhbCBjcml0 aWNpc20gcG9pbnRlZCBhdCB1cyBmcm9tIHRoZQ0KPiBwcm9wcmlldGFyeSBzb2Z0d2FyZSBl bWJyYWNlcnMpLiAgU2VlIGZvciBpbnN0YW5jZSBtaW5ldGVzdCwgd2hpY2hpc3kNCg0KU2Vu dGVuY2UgbWlnaHQgaGF2ZSBiZWVuIHRydW5jYXRlZD8gQWxzbywgdGhpcyBpcyB0aGUgcGFj a2FnZSBzb3VyY2UgDQpmaWVsZCwgbm90IHRoZSBkZXNjcmlwdGlvbiwgSSBkb24ndCBzZWUg aG93IHRoZSAiaGVscHMgc29mdHdhcmUgc3RhbmQgb24gDQppdHMgb3duIG1lcml0cyIgYXBw bGllcyB0byBzbmlwcGV0cyBvZiB0aGUgcGFja2FnZSBzb3VyY2UuDQoNCj4gDQo+PiBIb3cg ZG9lcyBpZ25vcmluZyBhIHRlc3QgZml4IHRoZSB0ZWNobmljYWwgaXNzdWUgaWRlbnRpZmll ZCBieSB0aGUNCj4+IHRlc3QgKHNvbWV0aW1lcywgdGhlIHRlY2huaWNhbCBpc3N1ZSBiZWlu ZyBhIGJ1ZyBpbiB0aGUgdGVzdCBpdHNlbGYpPw0KPiBJdCBmaXhlcyB0aGUgdGVjaG5pY2Fs IGlzc3VlIHRoYXQgYW4gb3RoZXJ3aXNlIGZ1bmN0aW9uYWwgcGFja2FnZQ0KPiAody5yLnQu IHRoZSBOIHRlc3RzIHRoYXQgZG9uJ3QgZmFpbCkgYnVpbGRzLiAgVGhpcyBpcyBhIHBhcnRp Y3VsYXJseQ0KPiB1c2VmdWwgZGlzdGluY3Rpb24gd2l0aCB0ZXN0cyB0aGF0IHJlcXVpcmUg YSBuZXR3b3JrIGNvbm5lY3Rpb24gYW5kDQo+IHRodXMgaGF2ZSB0byBmYWlsIGluIGEgYnVp bGQgY29udGFpbmVyLCBvciBhcmUga25vd24gZmxha3kgdXBzdHJlYW0gYW5kDQo+IHRodXMg Y2F1c2UgcmVwcm9kdWNpYmlsaXR5IGlzc3Vlcy4NCg0KTmV0d29yayB0ZXN0OiByaWdodCAo dGhvdWdoIHByZWZlcmFibHkgdGhvc2Ugd291bGQgc3VwcG9ydCBhIA0KLS1uby1uZXR3b3Jr LXRlc3RzIHRlc3Qgb3B0aW9uIG9yIHN1Y2gpLg0KDQpGb3IgZmxha3kgdGVzdHM6IHRob3Nl IHNvdW5kIGxpa2UgYnVncyB0byBtZSwgaWdub3JpbmcgdGhlbSBkb2Vzbid0IA0KcmVtb3Zl IHRoZSBmbGFreW5lc3MuDQoNCj4+PiBUaGVyZSBzdGlsbCBpcyB0aGUgZGlmZmVyZW5jZSB0 aGF0IHBoYXNlcyBhcmUgY2xlYXJseSBkZWxpbWl0ZWQNCj4+PiB3aGlsZSBzbmlwcGV0cyBh cmUgYSBibG9jayBvZiBjb2RlIHRoYXQgc2hvdWxkbid0IGdldCB0b28gbGFyZ2UuDQo+PiBT bmlwcGV0cyBhcmUgZGVsaW1pdGVkIGNsZWFybHkgYXMgd2VsbCwgdGhvdWdoLCB3aXRoIHRo ZSAnc25pcHBldCcNCj4+IGZpZWxkPw0KPj4gQW5kIHRoZSBsaW1pdGF0aW9ucyBvZiBzbmlw cGV0IGxlbmd0aCBhbmQgcGhhc2VzIGxlbmd0aCBhcmUgdGhlIHNhbWUNCj4+ICDCoC0tIG5v IGxpbWl0cywgdGhvdWdoIGNvbmNpc2VuZXNzIGlzIGFwcHJlY2lhdGUgYXMgYWx3YXlzLg0K PiBUcnVlLCBidXQgcGhhc2VzIGNhbiBiZSBtYWRlIHRvIGRvIGp1c3Qgb25lIHRoaW5nLCB3 aGVyZWFzIHNuaXBwZXRzDQo+IGhhdmUgdG8gZml4IGV2ZXJ5dGhpbmcgdGhhdCdzIHdyb25n IGluIG1vcmUgb3IgbGVzcyBvbmUgKGJlZ2luIC4uLikuDQo+IFRoaXMgaXMgYSBub3RpY2Fi bGUgZGlzdGluY3Rpb24uPiANCg0KWW91IGNhbiBkbyB0aGF0IGluIHNuaXBwZXRzIHRvbywg d2l0aCBjb21tZW50czoNCg0KKHNuaXBwZXQNCiAgICN+KGJlZ2luDQogICAgICAgOzsgRG8g dGhlIGZvbyB0aGluZw0KICAgICAgIChmb28pDQogICAgICAgKGZvby0yIFsuLi5dKQ0KICAg ICAgIFsuLi5dDQogICAgICAgOzsgRG8gdGhlIGJhciB0aGluZw0KICAgICAgIChiYXIpDQog ICAgICAgKGJhci0yIFsuLi5dKQ0KICAgICAgIFsuLi5dKSkNCg0KDQo+Pg0KPj4+IEkgdGhp bmsgbXkgdmVyc2lvbiBhdCBsZWFzdCBoaW50ZWQgYXQgdGhpcyBwcmFjdGljZSBpbiBhIG1v cmUNCj4+PiBjb25jaXNlIHdheSwgc28gaXQncyBub3QgaW1wb3NzaWJsZSB0byBtZW50aW9u LiBbLi4uXQ0KPj4gSSBhZ3JlZSBpdCdzIHBvc3NpYmxlIC0tIGFzIEkgcmVwbGllZCBwcmV2 aW91c2x5Og0KPj4+IEkgc3VwcG9zZSBhIHNlY3Rpb24gY291bGQgYmUgYWRkZWQgc29tZXdo ZXJlIHRvIHByb3Blcmx5IGRvY3VtZW50DQo+Pj4gdGhlICdlbWJlZGRpbmcgc3RvcmUgZmls ZSBuYW1lcycgcHJhY3RpY2UsIGFuZCBpbnNlcnQgYQ0KPj4+IGNyb3NzLXJlZmVyZW5jZSwN Cj4+IEkgZG9uJ3QgdGhpbmsgZG9jdW1lbnRpbmcgdGhlIGhvdyBvZiB0aGUgcHJhY3RpY2Ug c2hvdWxkIGJlIGRvbmUNCj4+IGluIHRoaXMgc2VjdGlvbiwgcHJvcGVybHkgZXhwbGFpbmlu ZyAnc2VhcmNoLWlucHV0LWZpbGUnIC8gJ3NlYXJjaC0NCj4+IGlucHV0LWRpcmVjdG9yeScs ICdpbnB1dHMgLyBuYXRpdmUtaW5wdXRzJywgJ2Jhc2gnIGJlaW5nIGFuIGltcGxpY2l0DQo+ PiBpbnB1dCBidXQgeW91IHN0aWxsIGhhdmUgdG8gYWRkIGl0IHRvICdpbnB1dHMnIGluIHNv bWUgY2FzZXMgYmVjYXVzZQ0KPj4gb2YgY3Jvc3MtY29tcGlsYXRpb24sIHRoaXMtcGFja2Fn ZS1pbnB1dCBhbmQgdGhpcy1wYWNrYWdlLW5hdGl2ZS0NCj4+IGlucHV0IC4uLiB3b3VsZCBt YWtlIHRoZQ0KPj4gc3Vic3Vic2VjdGlvbiBhIGJpdCB0b28gbG9uZyBJIHRoaW5rLCBkaXN0 cmFjdGluZyBmcm9tIG90aGVyDQo+PiBzaXR1YXRpb25zLCBoZW5jZSB0aGUgcHJvcG9zYWwg Zm9yIGEgY3Jvc3MtcmVmZXJlbmNlLg0KPj4gSG93IGFib3V0IGxlYXZpbmcgdGhlICdob3cg dG8gZW1iZWQgc3RvcmUgZmlsZSBuYW1lcycgZm9yIGEgc2VwYXJhdGUNCj4+ICDCoGRvY3Vt ZW50YXRpb24gcGF0Y2ggYW5kIHNlY3Rpb24sIGFkZGluZyBhIGNyb3NzLXJlZmVyZW5jZSBs YXRlcj8NCj4gU2VlIGFib3ZlLCAiSSBzdXBwb3NlIGEgc2VjdGlvbiBjb3VsZCBiZSBhZGRl ZC4uLiIgbWVhbnMgSSdtIHNvbWV3aGF0DQo+IGluZGlmZmVyZW50IHRvIHdoZXRoZXIgaXQn cyBkb25lIG5vdyBvciBsYXRlcjsNCg0KTml0cGljazogeW91IGFyZSBxdW90aW5nIHNvbWUg dGV4dCBJIHdyb3RlLCBzbyAnSScgcmVmZXJzIHRvIG1lIGhlcmUsIA0Kbm90IHlvdS4NCg0K ICBJIHdvdWxkIGhvd2V2ZXIgdmVyeQ0KPiBtdWNoIHByZWZlciBhIHdvcmRpbmcgdGhhdCBw b2ludHMgcGVvcGxlIHRvd2FyZCB0aGlzIHByYWN0aWNlIGV4aXN0aW5nLA0KPiBldmVuIGlm IHRoZXkgaGF2ZSB0byBnbyBsb29rIGluIHRoZSBjb2RlIGZvciBleGFtcGxlcy4gIEFsdGVy bmF0aXZlbHksDQo+IGEgZm9vdG5vdGUgZm9yIHRoZSBtb3N0IGNvbW1vbiBjYXNlIChzZWFy Y2gtaW5wdXQtZmlsZSBpbnB1dHMNCj4gImJpbi9jb21tYW5kIikgb3VnaHQgdG8gc3VmZmlj ZSBmb3IgdGhlIHRpbWUgYmVpbmcuDQoNCkFzaWRlIGZyb20gdGhlIHR5cG8ncyBhbmQgYSBm ZXcgcmVwaHJhc2luZ3MsIEknbSBkb25lIHdpdGggdGhlIA0KZG9jdW1lbnRhdGlvbi4gIElm IHNvbWVvbmUgd2FudHMgdG8gZXh0ZW5kIHRoZSBzZWN0aW9uIHdpdGggc3VjaCANCmluZm9y bWF0aW9uLCB0aGV5IGNhbiBhbHdheXMgZG8gc28gbGF0ZXIuDQoNCj4+DQo+Pj4gSSB0aGlu ayBjYWxsaW5nIGJhY2sgdG8gYSBndWlkaW5nIHByaW5jaXBsZSBpbiBhbmQgb2YgaXRzZWxm IHNob3dzDQo+Pj4gdGhhdCB0aGUgc2VjdGlvbiBoYXMgZ3Jvd24gdG9vIGxvbmcgdG8gcmVt ZW1iZXIgaXQgYnkgdGhlIHBvaW50IHlvdQ0KPj4+IGNvbWUgdG8gdGhpcyBleGFtcGxlLA0K Pj4gVGhpcyBoYXMgbm90aGluZyB0byBkbyB3aXRoIGxlbmd0aCBhbmQgcmVtZW1iZXJpbmcs IGJ1dCByYXRoZXIgd2l0aA0KPj4gZXhwbGFpbmluZyB3aHkgYSBwaGFzZSBtdXN0IGJlIHVz ZWQgLS0gdG8gZXhwbGFpbiB0aGF0LCBJIHN0YXRlIHdoaWNoDQo+PiBwcmluY2lwbGUgYXBw bGllcyAoYXMgbWVudGlvbmVkIHByZXZpb3VzbHkpLiBJZiBJIHJlbW92ZWQgdGhlDQo+PiBl eHBsYW5hdGlvbnMsIEkgd291bGQganVzdCBiZSBzdGF0aW5nIGhvdyB0byBkbyB0aGluZ3Ms IHdpdGhvdXQNCj4+IGdpdmluZyBhIGxvZ2ljYWwgcmVhc29uaW5nIG9uIHRoZSAnd2h5Jy4N Cj4gSU1ITywgSSB0aGluayBhIHJlYWRlciB3aG8gcmVtZW1iZXJzIHRoZSBndWlkaW5nIHBy aW5jaXBsZXMgc2hvdWxkIHNlZQ0KPiB0aGF0IGl0IGFwcGxpZXMuDQoNCkxpa2VseS4gQnV0 IHJlbW92aW5nIHRoZSBleHBsaWNpdCBtZW50aW9uIG9mIHRoZSBndWlkaW5nIHByaW5jaXBs ZSBzdGlsbCANCm1ha2VzIHRoZSBsb2dpY2FsIHJlYXNvbmluZyBpbmNvbXBsZXRlLCByZW1l bWJlcmluZyBoYXMgbm90aGluZyB0byBkbyANCndpdGggaXQuICBBcyBJJ3ZlIHdyaXR0ZW4g cHJldmlvdXNseTog4oCYVGhpcyBoYXMgbm90aGluZyBkbyBkbyB3aXRoIFsuLi5dIA0KYW5k IHJlbWVtYmVyaW5nLCBidXQgcmF0aGVyIHdpdGggWy4uLl3igJkuDQoNCj4+PiBhbmQgSSB0 aGluayB0aGF0J3MgbW9yZSBwcm9ibGVtYXRpYyB0aGFuIG1lcmVseSB0aGUNCj4+PiBjYWxs YmFjay4gSWYgeW91IGRpZG4ndCBuZWVkIHRvIGRpdmlkZSB0aGlzIGludG8gc3Vic3Vic2Vj dGlvbnMsDQo+Pj4geW91IGNvdWxkIGludHJvZHVjZSB0aGUgZ3VpZGluZyBwcmluY2lwbGVz IGluIGEgd2F5IHRoYXQgZmVlbHMgbW9yZQ0KPj4+IG5hdHVyYWwuDQo+PiBJIGNvbnNpZGVy IGl0IG1vcmUgbmF0dXJhbCB0byBoYXZlIHRoZSAnZ3VpZGluZyBwcmluY2lwbGVzJyBfYmVm b3JlXw0KPj4gdGhlIGNvbmNyZXRlIGNhc2VzLCBhcyB0aGV5IGFyZSBtZWFudCB0byBiZSAn Z3VpZGluZycgYW5kDQo+PiAncHJpbmNpcGxlcycuDQo+PiBJdCdzIGxpa2UgJ3N0YXJ0aW5n IGZyb20gZmlyc3QgcHJpbmNpcGxlcycsIHRoZXJlIGludHJvZHVjaW5nIHRoZQ0KPj4gZmly c3QgcHJpbmNpcGxlcyBhcyB5b3UgZ28gaXMgYWQtaG9jLg0KPj4gVGhlIGd1aWRpbmcgcHJp bmNpcGxlcyBhbHNvIG5lZWQgdG8gYmUgb3V0c2lkZSB0aGUgZXhhbXBsZXMsIGluIGNhc2UN Cj4+ICDCoG9uZSBvZiB0aGUgZXhhbXBsZXMgZG9lc24ndCBhcHBseSB0byB0aGUgcGFja2Fn ZXIncyB1c2UgY2FzZSwgc3VjaA0KPj4gIMKgdGhhdCB0aGV5IGNhbiBmYWxsLWJhY2sgdG8g dGhlIGd1aWRpbmcgcHJpbmNpcGxlcy4NCj4+IEFsc28sIGluIHlvdXIgcGF0Y2ggeW91IGFy ZSBkaXZpZGluZyB0aGluZ3MgaW4gc3Vic3Vic2VjdGlvbnMgYXMNCj4+IHdlbGwswqBqdXN0 IHVuZGVyIGEgZGlmZmVyZW50IG5hbWUgYW5kIGRpZmZlcmVudCByZXByZXNlbnRhdGlvbiAo dGFibGUNCj4+IGVudHJpZXPCoGluIGEgc3Vic2VjdGlvbiksIGFzIG1lbnRpb25lZCBwcmV2 aW91c2x5Lg0KPiBBIHRhYmxlIGVudHJ5IGlzIG5vdCBhIHN1YnNlY3Rpb24sIGFzIG11Y2gg YXMgeW91IHdhbnQgaXQgdG8gYmUgdGhhdC4NCg0KSXQgaW5kZWVkIGlzIG5vdCwgcmF0aGVy IHRoZXkgYXJlIGVxdWl2YWxlbnQgaGVyZSBpbiB0ZXJtcyBvZiBzdHJ1Y3R1cmUsIA0KbmVz dGluZyBhbmQgcHJvYmxlbWF0aWNuZXNzLg0KDQo+IA0KPiBBbHNvLCB5b3VyIGd1aWRpbmcg cHJpbmNpcGxlcyBhcmUgKHdpdGggb25lIGV4Y2VwdGlvbikgcmVhbGx5IGp1c3QNCj4gaW52 YXJpYW50cyB0aGF0IG91Z2h0IHRvIGhvbGQgZm9yIHRoZSBzb3VyY2UgZmllbGQgb2YgYSBw YWNrYWdlLg0KDQpJIGRvbid0IGtub3cgYWJvdXQgdGhlIGV4Y2VwdGlvbnMgKEkgaGF2ZW4n dCBjb3VudGVkIHRoZW0pLCBidXQgeWVzLCANCmluZGVlZC4gIEkgZG8gbm90IHNlZSB0aGUg cHJvYmxlbSBvZiB0aGlzLg0KDQo+IEFzIHN1Y2gsIEkgdGhpbmsgaXQgd291bGQgYmUgZWFz aWVyIHRvIHN0YXRlICJBIHBhY2thZ2UncyBzb3VyY2Ugc2hvdWxkDQo+IGJlIHRoZSBzbWFs bGVzdCBjb3JyZXNwb25kaW5nIHNvdXJjZSBpbiB0ZXJtcyBvZiB1bmNvbXByZXNzZWQgZmls ZQ0KPiBzaXplLiAgVGhpcyBjb3JyZXNwb25kaW5nIHNvdXJjZSBtdXN0IGNvbnNpc3Qgb25s eSBvZiBmcmVlIHNvZnR3YXJlDQo+IChub3RlIEZyZWUgU29mdHdhcmUpIGFuZCBzaG91bGQg YnVpbGQgb24gYWxsIHBsYXRmb3JtcyBzdXBwb3J0ZWQgYnkNCj4gdXBzdHJlYW0uIiAgTm90 ZSBob3cgc21hbGxlc3QgbmF0dXJhbGx5IGltcGxpZXMgdW5idW5kbGluZyBidW5kbGVkDQo+ IHNvdXJjZXMuDQoNClRoaXMgY3JpdGVyaXVtIG9uIG92ZXJseSBzbWFsbCBzb3VyY2VzLiAg T2Z0ZW4sIGEgcGFja2FnZSdzIHNvdXJjZSANCmNvbnRhaW5zIHRoaW5ncyB0aGF0IGlzIG5v dCB1c2VkIGZvciB0aGUgYnVpbGQgb3Igb3V0cHV0cyBhbmQgaGVuY2UNCmlzIG5vdCBwYXJ0 IG9mIHRoZSBjb3JyZXNwb25kaW5nIHNvdXJjZS4gIEV4YW1wbGVzOg0KDQoqIHRoZSBzb3Vy Y2UgY29udGFpbnMgZG9jdW1lbnRhdGlvbiB0aGF0IGNvdWxkIGJlIGJ1aWx0IGFuZCBpbnN0 YWxsZWQsDQogICBidXQgR3VpeCBkb2Vzbid0IGRvIHNvIHlldC4gIC0tPiBzaG91bGQgYmUg a2VwdCAodW5sZXNzIG5vbi1mcmVlKQ0KKiBkb2N1bWVudGF0aW9uIHRoYXQgaXNuJ3QgbWVh bnQgdG8gYmUgYnVpbHQgb3IgaW5zdGFsbGVkDQogICAoZS5nLiBIQUNLSU5HLCBQQUNLQUdF UlMsIC4uLikgLS0+IHVzZWZ1bCwgc2hvdWxkbid0IGJlIHJlbW92ZWQuDQoqIC5naXRpZ25v cmUsIC5naXRodWIsIC4uLiAtLT4gbm90aGluZyB3cm9uZyB3aXRoIHJlbW92aW5nIHRob3Nl LA0KICAgYnV0IHBvaW50bGVzcywgbGV0J3Mgbm90IHdhc3RlIG91ciB0aW1lIHdpdGggbG9v a2luZyBmb3IgdGhvc2UNCiAgIGFuZCByZW1vdmluZyB0aGVtLCBldmVuIHRob3VnaCBkb2lu ZyBzbyB3b3VsZCBtYWtlIGl0IHNtYWxsZXIuDQoqIHNvdXJjZSBmaWxlcyBmb3IgcGxhdGZv cm1zIHRoZSB1cHN0cmVhbSBkb2VzIG5vdCBzdXBwb3J0IHlldC9hbnltb3JlDQogICAoYnV0 IHdpdGggc29tZSB2b2x1bnRlZXIgZWZmb3J0IChlLmcuIGJ1Z2ZpeGVzKSwgaXQgbWlnaHQg YmVjb21lDQogICBhIHN1cHBvcnRlZCBzeXN0ZW0gYWdhaW4pDQogICAtLT4gcmVtb3Zpbmcg dGhlbSAoZS5nLiBhcyBwYXJ0IG9mIGFuIG92ZXJseS1icm9hZCANCihkZWxldGUtZmlsZS1y ZWN1cnNpdmVseSANCiJ0aGlzLWRpci1oYXMtYnVuZGxpbmctYWxiZWl0LW5vdC1hbGwtb2Yt aXQtaXMtYnVuZGxpbmciKSkNCiAgICAgICBjYW4gYmUgT0staXNoLCBidXQgcmVtb3Zpbmcg dGhlbSBmb3IgJ21pbmltYWxpdHknIGlzIHBvaW50bGVzcy4NCg0KDQo+Pj4gSSBzdGlsbCBm aW5kIHRoaXMgd29yZGluZyB2ZXJ5IGNvbmZ1c2luZy4gUGVyaGFwcyAiVG8gYWRkIG5ldw0K Pj4+IGZ1bmN0aW9uYWxpdHksIGEgcGF0Y2ggaXMgYWxtb3N0IGFsd2F5cyB0aGUgYmVzdCBj aG9pY2UuIEZvciBvbmUsDQo+Pj4gaXQgaXMgbGlrZWx5IHRoYXQgdGhlIG5ldyBmdW5jdGlv bmFsaXR5IHJlcXVpcmVzIGNoYW5naW5nIG11bHRpcGxlDQo+Pj4gbGluZXMgb2Ygc291cmNl IGNvZGUsIHdoaWNoIGlzIG1vcmUgY29udmVuaWVudCB0byBkbyB3aXRoIGEgcGF0Y2gNCj4+ PiB0aGFuIHdpdGggYSBzbmlwcGV0LiBGdXJ0aGVyLCBwYXRjaGVzIGNhbiBiZSB0YWtlbiBm cm9tIGFuZA0KPj4+IHN1Ym1pdHRlZCB0byB1cHN0cmVhbXMgbW9yZSBlYXNpbHkuIElmIHlv dXIgcGF0Y2ggaGFzIG5vdCBiZWVuDQo+Pj4gc3VibWl0dGVkIHRvIHVwc3RyZWFtLCBjb25z aWRlciBkb2luZyBzby4iDQo+PiBJdCBsb3NlcyBzb21lIGluZm9ybWF0aW9uICh0aGF0IHBh dGNoZXMgYXJlIHByZWZlcnJlZCkgYW5kDQo+PiAoYWZ0ZXIgcmUtYWRkaW5nIHRoZSBjb25j bHVzaW9uKSBpcyBtb3JlIHZlcmJvc2UsIHdoaWNoIGFwcGVhcnMNCj4+IHRvIGJlIGNvbnNp ZGVyZWQgdmVyeSBpbXBvcnRhbnQuDQo+IFdoaWNoIGNvbmNsdXNpb24gaXMgdGhlcmUgdG8g cmUtYWRkPw0KDQoicGF0Y2hlcyBhcmUgcHJlZmVycmVkIg0KDQogICBUaGUgY29uY2x1c2lv biBpcyBhbHJlYWR5IHN0YXRlZA0KPiBpbiB0aGUgYmVnaW5uaW5nOiBwYXRjaGVzIGFyZSBh bG1vc3QgYWx3YXlzIHRoZSBiZXN0IGNob2ljZS4gIFRoZW4gdHdvDQo+IHJlYXNvbnMgYXMg Zm9yIHdoeS4gIFRoZSBwYXJ0IHcuci50LiB1cHN0cmVhbWluZyBjaGFuZ2VzIGhhcyBhbHNv IGJlZW4NCj4gYWRkcmVzc2VkLg0KDQpXaGlsZSBJIGNvbnNpZGVyIHRoYXQgcG9saWNpZXMg c2hvdWxkIGhhdmUgImJlc3QgY2hvaWNlcyIgY29pbmNpZGluZyANCndpdGggInByZWZlcnJl ZCIgYW5kIHRoYXQgbm90IGRvaW5nIHNvIHdvdWxkIGJlIGlsbG9naWNhbCwgcGVvcGxlLCAN CnByb2plY3RzLCBkZWNpc2lvbnMgLi4uIGFyZSBmYXIgZnJvbSBhbHdheXMgbG9naWNhbC4N Cg0KQmVjYXVzZSBvZiB0aGlzLCBwZW9wbGUgY2Fubm90IGFzc3VtZSB0aGF0IHRoZSAnYmVz dCBjaG9pY2VzJyBhcmUgDQoncHJlZmVycmVkJywgc28gaXQgbmVlZHMgdG8gYmUgbWVudGlv bmVkIGV4cGxpY2l0bHkgdGhhdCB0aGVzZSAnYmVzdCANCmNob2ljZXMnIGFyZSBhY3R1YWxs eSAncHJlZmVycmVkJy4NCg0KPj4+IEFuIGVudW1lcmF0aW9uIG91Z2h0IHRvIGhhdmUgYXQg bGVhc3QgdGhyZWUgZWxlbWVudHMgKG90aGVyd2lzZQ0KPj4+IGl0J3MganVzdCBhIHBhaXIp LCBhbmQgSSB0aGluayBpZiB3ZSBkbyBwcm9wZXIgY291bnRpbmcgYW5kIG9taXQNCj4+PiBu by1icmFpbmVycywgc3VjaCBhcyB0aGUgIm9ubHkgZnJlZSBzb2Z0d2FyZSIgcGFydCB0aGF0 IGhhcyBhbHJlYWR5DQo+Pj4gYmVlbiBtZW50aW9uZWQsIHdlIGNvbWUgdmVyeSBjbG9zZSB0 byBza2lydGluZyB0aGF0IGxpbmUuDQo+PiBUaGUgIm9ubHkgZnJlZSBzb2Z0d2FyZSIgaXMg bWVudGlvbmVkIGVsc2V3aGVyZSwgeWVzLCBidXQgaXQgaXMgb25lDQo+PiBvZiB0aGUgcHJp bmNpcGxlcyBmb3IgZGVjaWRpbmcgYmV0d2VlbiBzbmlwcGV0cywgcGhhc2VzIGFuZCBwYXRj aGVzLg0KPj4gV2hpbGUgeW91IGNhbGwgaXQgYSBuby1icmFpbmVyLCBpdCBpcyBzb21ldGlt ZXMgbmVnbGVjdGVkLCBzbyBpdA0KPj4gc291bmRzIGltcG9ydGFudCB0byBtZSB0byBleHBs aWNpdGx5IGxpc3QgaXQuDQo+PiBNZXJnaW5nIHRoZSAzdGggYW5kIDR0aCBAaXRlbSwgSSBj b3VudCA0IHByaW5jaXBsZXMsIHNvIGl0IGZpdHMgd2l0aA0KPj4gYW4gZW51bWVyYXRpb24u DQo+PiBBbHNvLCBJJ20gbm90IGZvbGxvd2luZyB5b3VyIHBvaW50IGhlcmUgLS0geW91ciBj b21wbGFpbnQgd2FzIHRoYXQNCj4+IHRoZXnCoGFyZW4ndCBndWlkaW5nIHByaW5jaXBsZXMg KGJhc2VkIG9uIHRoZSBudW1iZXIgb2YgdGhlbSksIGJ1dA0KPj4geW91csKgcmVzcG9uc2Ug aXMgdGhhdCB0aGV5IG1pZ2h0IG5vdCBmb3JtIGFuIGVudW1lcmF0aW9uP8KgIFRoZXkgYXJl DQo+PiBuYW1lZMKgdGhlIGd1aWRpbmcgcHJpbmNpcGxlcywgbm90IHRoZSBndWlkaW5nIGVu dW1lcmF0aW9uLsKgIFdoYXQgaGF2ZQ0KPj4gZW51bWVyYXRpb25zIHRvIGRvIHdpdGggYW55 dGhpbmc/DQo+IEknbSB1c2luZyBlbnVtZXJhdGlvbiBhcyBhIHN1cGVyIHRlcm0gaGVyZSwg d2hpY2ggY2FuIGJlDQo+ICgoc3ViKXN1YilzZWN0aW9ucywgY2hhcHRlcnMsIGxpc3QgZWxl bWVudHMsIHdoYXRldmVyLCBhbmQgbXkgY2xhaW0gaXMNCj4gdGhhdCB3ZSBiYXJlbHkgaGF2 ZSBlbm91Z2ggcHJpbmNpcGxlcyB0byBhbGxvdyB0aGUgdXNlIG9mIGEgcGx1cmFsLg0KDQpJ biBFbmdsaXNoLCB0aGluZ3MgYXJlIGVpdGhlciBwbHVyYWwgb3Igc2luZ3VsYXIuICBFdmVy eXRoaW5nID49IDIgaXMgDQpwbHVyYWwuICBUaGVyZSBudW1iZXIgb2YgcHJpbmNpcGxlcywg aG93ZXZlciB3ZSBjb3VudCB0aGVtLCBpcywgYXQgDQpsZWFzdCwgMi4gIENvbnNlcXVlbnRs eSwgdGhlIHByaW5jaXBsZXMgYXJlIHBsdXJhbCwgbm90IHNpbmd1bGFyLiANClRyZWF0aW5n IHRoZSBwcmluY2lwbGVzIGFzIHNpbmd1bGFyIGlzIHNpbXBseSBncmFtbWF0aWNhbGx5IGlu Y29ycmVjdC4NCg0KTWF5YmUgaXQgaXMgYmFyZWx5IGFsbG93ZWQgdG8gYmUgcGx1cmFsLCBi dXQgRW5nbGlzaCBncmFtbWFyIGRvZXNuJ3QgDQpjYXJlIGFib3V0IHRoYXQgLS0gaXQgaXMg ZGVmaW5pdGl2ZWx5IGRpc2FsbG93ZWQgdG8gYmUgc2luZ3VsYXIsIG9ubHkgDQpwbHVyYWwg cmVtYWlucy4NCg0KPiBBZGRpbmcgdG8gdGhhdCwgbm93IHRoYXQgSSB0aGluayBvZiBpdCwg SSBhbHNvIGRvdWJ0IHRoZWlyIHVzZWZ1bG5lc3MNCj4gaW4gZ3VpZGluZy4gICJVc2Ugd2hh dGV2ZXIgZmVlbHMgY29udmVuaWVudCwgYnV0IG5vdGUgdGhhdCB0aGF0IG1pZ2h0DQo+IGJl IHN1YmplY3RpdmUiIGlzIG1vcmUgdXNlZnVsIGF0IHRoZSBlbmQgb2YgdGhlIHNlY3Rpb24g d2hlbiBhIHVzZXINCj4gZGlkbid0IGZpbmQgd2hhdCB0aGV5IHdlcmUgbG9va2luZyBmb3Ig dGhhbiBhdCB0aGUgc3RhcnQuDQoNClRoZSBpbnRyb2R1Y3Rpb24gaGFzIGEgc2V0IG9mIGd1 aWRpbmcgcHJpbmNpcGxlcywgZnJvbSB3aXRoIGNvbmNyZXRlIA0KY2FzZXMgYXJlIGJ1aWx0 LiAgQnkgYWRkaW5nIGFub3RoZXIgcHJpbmNpcGxlIGF0IHRoZSBlbmQsIHRoZSBjYXNlcw0K Y2Fubm90IG1ha2UgdXNlIG9mIHRoZSAidXNlIFsuLi5dIGNvbnZlbmllbnQiIHByaW5jaXBs ZS4NCg0KQWRkaXRpb25hbGx5LCBub3cgdGhlIHVzZXIgaGFzIHRvIGxvb2sgYXQgX3R3b18g cGxhY2VzIHRvIGZpbmQgdGhlIA0KZ3VpZGluZyBwcmluY2lwbGVzIC0tIGF0IHRoZSBiZWdp bm5pbmcsIGFuZCBhdCB0aGUgZW5kLiAgV29yc2UsDQp0aGUgYmVnaW5uaW5nIGRvZXMgbm90 IGhhdmUgYSBjcm9zcy1yZWZlcmVuY2UgdG8gdGhlIGVuZCwgc28gc2luY2UNCnRoZSBzZXQg YXQgdGhlIGJlZ2lubmluZyBpcyBwcmVzZW50ZWQgYXMgZXhoYXVzdGl2ZSwgdGhlIHVzZXIg bWlnaHQNCm5vdCBrbm93IHRoZXJlIGlzIGFub3RoZXIgZ3VpZGluZyBwcmluY2lwbGUuDQoN CkFuZCBldmVuIGlmIHRoZXkgZGlkIHJlYWQgdGhyb3VnaCB0aGUgd2hvbGUgc2VjdGlvbiAo ZXZlbiB0aG91Z2ggdGhleSANCnNob3VsZCBvbmx5IGhhdmUgdG8gcmVhZCB0aGUgaW50cm9k dWN0aW9uIGFuZCB0aGUgcmVsZXZhbnQgd29ya2VkLW91dCANCmNhc2UpLCBhc3N1bWluZyB0 aGV5IHJlYWQgdGhyb3VnaCBpdCBpbiBhIGxpbmVhciBmYXNoaW9uLCBkdWUgdG8gdGhlIG5l dyANCmd1aWRpbmcgcHJpbmNpcGxlIHRoYXQgd2Fzbid0IGFsbHVkZWQgdG8gYXQgdGhlIGJl Z2lubmluZywgdGhleSBoYXZlDQp0byByZWRvIHRoZWlyIG1lbnRhbCBtb2RlbCBvZiAiTW9k aWZ5aW5nIFNvdXJjZXMiIGFzIHRoaXMgcHJpbmNpcGxlDQpjb3VsZCBpbnZhbGlkYXRlIHRo aW5ncy4NCg0KPj4+PiBJIGRvIG5vdCBzZWUgd2hhdCB0aGUgcHJvYmxlbSBpcyB3aXRoIGFk ZGl0aW9uYWwgbGVuZ3RoIGFzIGxvbmcNCj4+Pj4gYXMgdGhpcyBhZGRpdGlvbmFsIGxlbmd0 aCBjb21lcyB3aXRoIGFkZGl0aW9uYWwgdXNlZnVsDQo+Pj4+IGluZm9ybWF0aW9uIGFuZCB0 aGUgbWFudWFsIGlzIHdlbGwtc3RydWN0dXJlZCAoZS5nLiB3aXRoDQo+Pj4+IChzdWIpKHN1 YilzZWN0aW9ucywgY2hhcHRlcnMgYW5kIGluZGljZXMpIC0tIHdlIGRvIG5vdCBoYXZlIGEN Cj4+Pj4gcGFnZSBsaW1pdC4NCj4+Pj4NCj4+Pj4gQXQgd29yc3QsIHBlcmhhcHMgdGhlIHNh bWUgaW5mb3JtYXRpb24gY291bGQgcGVyaGFwcyBiZSBlbmNvZGVkDQo+Pj4+IHdpdGggZmV3 ZXIgd29yZHM/IEkgY291bGQgY29tcGFyZSB0aGUgdHdvIHBhdGNoZXMgdG8gc2VlIHdoaWNo DQo+Pj4+IG9uZSBmb3JtdWxhdGVzIGNlcnRhaW4gaW5mb3JtYXRpb24gaW4gdGhlIGZld2Vz dCB3b3JkcywgYW5kDQo+Pj4+IGNob29zZSB0aGUgbGVhc3QgdmVyYm9zZSBvZiB0aGUgdHdv IGZvciBlYWNoIHBpZWNlIG9mIGluZm9ybWF0aW9uDQo+Pj4+IHRoYXQgaXMgcHJlc2VudCBp biBib3RoPw0KPj4+Pg0KPj4+PiBBbHNvLCBjb21wYXJpbmcgdGhlIHR3byBwYXRjaGVzLCBt eSBwYXRjaCBoYXMgNDAgbW9yZSBsaW5lcywgYnV0DQo+Pj4+IGFib3V0IDI1IG9mIHRoZW0g YXJlIGZvciBub3RpbmcgdGhlIGd1aWRpbmcgcHJpbmNpcGxlcyAod2hpY2ggYXJlDQo+Pj4+ IGFic2VudCBpbiB5b3VyIHBhdGNoKS4NCj4+Pj4gQ29tcGVuc2F0aW5nIGZvciB0aGF0LCB0 aGUgcGF0Y2hlcyBhcmUgYWJvdXQgdGhlIHNhbWUgbGVuZ3RoLCBzbw0KPj4+PiBJIGRvIG5v dCB0aGluayB0aGF0ICdzaGVlciBsZW5ndGgnIGlzIGFjY3VyYXRlIGhlcmUuDQo+Pj4gMjUg bGluZXMgY2FsbGluZyBiYWNrIHRvIGVhcmxpZXIgaW5mb3JtYXRpb24gYXJlLCBpbWhvLCBh bg0KPj4+IGluZGljYXRvciB0aGF0IHRoZSBzZWN0aW9uIGlzIHRvbyBsb25nLiBJbWFnaW5l IHlvdSdkIGhhdmUgdHdlbnR5LQ0KPj4+IGZpdmUgZnVuY3Rpb24gY2FsbHMgdG8gZ3VpZGlu Z19wcmluY2lwbGVzKG4pIGluIHlvdXIgcHJvZ3JhbSDigJMgYXQNCj4+PiBzb21lIHBvaW50 LCB5b3UnZCB0cnkgdG8gY2FjaGUgdGhvc2UuDQo+PiAoZGVmaW5lIGNhY2hlZC1ndWlkaW5n LXByaW5jaXBsZXMNCj4+ICDCoCAoZGVsYXkgKGxpc3QgKGd1aWRpbmctcHJpbmNpcGxlLTAp DQo+PiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgWy4uLl0NCj4+ ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAoZ3VpZGluZy1wcmlu Y2lwbGUtMjQpKSkpDQo+PiBDYWNoaW5nIHRoZSBndWlkaW5nIHByaW5jaXBsZXMgZG9lcyBu b3QgcmVkdWNlIHRoZSBsZW5ndGguDQo+PiBJIGRvbid0IHNlZSB0aGUgcHJvYmxlbSB3aXRo IGNhbGxpbmcgYmFjayB0byBlYXJsaWVyIGluZm9ybWF0aW9uLg0KPj4gQWxzbywgaXQgaXNu J3QgZWFybGllciBpbmZvcm1hdGlvbiwgdGhlcmUgaXMgbm8gbmljZSBsaXN0IG9mIGd1aWRp bmcNCj4+IHByaW5jaXBsZXMgYW55d2hlcmUgZWxzZS4NCj4gQXQgdGhlIHJpc2sgb2YgcmVz cG9uZGluZyBqb2tpbmdseSB0byB3aGF0IHdhcyBtZWFudCBzZXJpb3VzOiBJIGRpZG4ndA0K PiBrbm93IHdlIHN1ZGRlbmx5IGdhaW5lZCAyMCBndWlkaW5nIHByaW5jaXBsZXMuDQoNCjI1 IGxpbmVzIGFyZSBmb3IgdGhlIGd1aWRpbmcgcHJpbmNpcGxlcyAoc29tZXRpbWVzIHJlZmVy cmluZyB0byBhIA0KcHJpbmNpcGxlIG9mIGVsc2V3aGVyZSBpbiBHdWl4LCBzb21ldGltZXMg YSBuZXcgcHJpbmNpcGxlIGZvciAiTW9kaWZ5aW5nIA0KU291cmNlcyIpLiAgWW91IHByb3Bv c2VkIHRvICdjYWNoZScgdGhlbSBzb21laG93LiAgSW4gR3VpbGUsIHRvIGNhY2hlIA0Kc29t ZXRoaW5nLCB5b3UgY2FuIHVzZSAnZGVsYXkvZm9yY2UnLiAgQnV0IHRoaXMgaW5jcmVhc2Vz IHRoZSBhbW91bnQgb2YgDQpjb2RlIChkdWUgdG8gdGhlIGFkZGl0aW9uYWwgdXNlIG9mICdk ZWxheScpLCBpbnN0ZWFkIG9mIGRlY3JlYXNpbmcuDQoNClRoZSBkb2N1bWVudGF0aW9uIGVx dWl2YWxlbnQgKHdoYXRldmVyIHRoYXQgbWlnaHQgYmUsIEkgYW0gbm90IHNlZWluZyANCm9u ZSBteXNlbGYpIHdvdWxkIHRoZW4gYWxzbyBiZSBhdCBsZWFzdCBhcyBsb25nLCBtYXliZSBl dmVuIGEgbGl0dGxlIA0KbG9uZ2VyIGR1ZSB0byB0aGUgdXNlIG9mICdkZWxheScuDQoNCj4+ Pj4+IEdvaW5nIGRvd24gdG8gc3Vic3Vic2VjdGlvbnMganVzdCB0byBmaW5kIG91dCB3aGVy ZSBwYXRjaGVzIGFyZQ0KPj4+Pj4gYXBwcm9wcmlhdGUsIGlzIGltaG8gb3ZlcmtpbGwuDQo+ Pj4+IFRoZSAnZ29pbmcgZG93biB0byBzdWJzdWJzZWN0aW9uJyBpcyB0aGUgY2FzZSBmb3Ig eW91ciBwYXRjaCB0b28sDQo+Pj4+IHRob3VnaD8gSW4gbXkgY2FzZSwgaXQncyBhIHN1YnN1 YnNlY3Rpb24sIGluIHlvdXIgY2FzZSBpdCdzIGENCj4+Pj4gdGFibGUNCj4+Pj4gZW50cnkg aW5zaWRlIGEgc3Vic2VjdGlvbiwgYm90aCBhcmUgdGhlIHNhbWUgbGV2ZWwgb2YgbmVzdGlu Zy4NCj4+PiBUaGVzZSBhcmUgc3RpbGwgdHdvIHZlcnkgZGlmZmVyZW50IGtpbmRzIG9mIG5l c3RpbmcuIEEgdGFibGUgZml0cw0KPj4+IG9udG8gYSAodmlydHVhbCkgcGFnZSBtb3JlIGVh c2lseSB0aGFuIHNldmVyYWwgc3Vic2VjdGlvbnMuDQo+PiBJIHN1cHBvc2UgdGFibGUgaXRl bXMgbWlnaHQgdGFrZSB0d28gbGVzcyBsaW5lIG9yIHNvIGxlc3MgdGhhbg0KPj4gc3Vic3Vi c2VjdGlvbnMsIGJ1dCBJIGRvbid0IHRoaW5rIHRoYXQncyBzdWZmaWNpZW50IHJlYXNvbiB0 byBzdGVwDQo+PiBhd2F5IGZyb20gYSBuaWNlIHNlY3Rpb24gc3RydWN0dXJlLg0KPiBBbm90 aGVyIHJlYXNvbiBpcyB0aGF0IHlvdSBjYW4gZW5kIGEgdGFibGUgaW4gdGhlIG1pZGRsZSBv ZiBhIHNlY3Rpb24sDQo+IHdoaWNoIHlvdSBjYW4ndCBkbyB3aXRoIHN1YnNlY3Rpb25zLiAg SGVuY2Ugd2h5IEknbSBhYmxlIHRvIHB1dCBhDQo+IHJlbWFyayBhdCB0aGUgYm90dG9tLCB3 aGljaCB5b3UgaGF2ZSB0byBjbHVtc2lseSBmaXQgaW50byB0aGUgdG9wLg0KDQpJIGNhbiwg aW5kZWVkLCBub3QgcHV0IHRoZSAnY29udmVuaWVuY2UgcHJpbmNpcGxlJyBhdCB0aGUgYm90 dG9tLCBleGNlcHQgDQpwZXJoYXBzIGJ5IGFkZGluZyBhIG5ldyBzdWJzdWJzZWN0aW9uLCBh bmQgZm9yIHRhYmxlcyBhZGRpbmcgc3VjaCBhIA0KcmVtYXJrIGF0IHRoZSBib3R0b20gaXMg aW5kZWVkIG1vcmUgY29udmVuaWVudC4NCg0KSG93ZXZlciwgSSBkb24ndCBzZWUgdGhlICdo YXZlIHRvIGNsdW1zaWx5JyBoZXJlIC0tIGFzIGV4cGxhaW5lZCANCmVsc2V3aGVyZSwgSSBi ZWxpZXZlIHRoYXQgdGhlICdjb252ZW5pZW5jZSBwcmluY2lwbGUnIHNob3VsZG4ndCBiZSAN CnNlcGFyYXRlZCBmcm9tIHRoZSBvdGhlciBwcmluY2lwbGVzIGFuZCB0aGF0IGl0IGZpdHMg bmljZWx5IG5leHQgdG8gdGhlIA0KdGhlIHByaW5jaXBsZXMgLS0tIHRoZXJlIGlzIG5vICdo YXZlIHRvJywgYmVjYXVzZSBJIGNob29zZSBmb3IgdGhpcywgYW5kIA0KSSBhbSBub3Qgc2Vl aW5nIGFueSAnY2x1bXNpbmVzcycgaGVyZS4NCg0KPj4+PiBBbHNvLCBpdCdzIGEgbWF0dGVy IG9mIGRpZmZlcmVudCBzdHJ1Y3R1cmUgLS0gaW4gbXkgdjIgYW5kIHYzDQo+Pj4+IHBhdGNo LCBJIGhhdmUgYSAncHJvYmxlbSAtPiBzb2x1dGlvbicgc3RydWN0dXJlIC0tIHRoZSBpZGVh IGlzDQo+Pj4+IHRoYXQgdGhlIHBhY2thZ2VzIGhhcyBhIHByb2JsZW0sIHRoZXkgbG9vayBh dCB0aGUgc2VjdGlvbiwgdGhleQ0KPj4+PiByZWFkIHRoZSBzdWJzdWJzZWN0aW9uIG5hbWVz LCBzZWxlY3QgdGhlDQo+Pj4+IHN1YnN1YnNlY3Rpb24gdGhhdCBtYXRjaGVzIHRoZWlyIHBy b2JsZW0gYW5kIHJlYWQgdGhlIHNvbHV0aW9uIC0tDQo+Pj4+IGluIHNob3J0LCB0aGUgaWRl YSBpcyB0byBwcm92aWRlIGEgc29sdXRpb24gdG8gdGhlIHByb2JsZW0uDQo+Pj4+DQo+Pj4+ IFlvdXIgc3RydWN0dXJlIGlzIHRoZSBvdGhlciB3YXkgYXJvdW5kIC0tIGZvciBzb2x1dGlv bnMgKHBhdGNoZXMsDQo+Pj4+IHNuaXBwZXRzLCBwaGFzZXMpLCBpdCBnaXZlcyB0aGUgcGVy bWl0dGVkIHByb2JsZW1zIHRvIGFwcGx5IGl0DQo+Pj4+IHRvLg0KPj4+Pg0KPj4+PiBTbyB5 ZXMsIHlvdXIgcGF0Y2ggaXMgbW9yZSBjb252ZW5pZW50IGZvciBmaW5kaW5nIG91dCB3aGVy ZQ0KPj4+PiBwYXRjaGVzIGFyZSBhcHByb3ByaWF0ZS7CoCBJIGRvIG5vdCBzZWUgdGhlIGJl bmVmaXQgb2YgdGhhdCB0aG91Z2gNCj4+Pj4gLS0gYSBuZXcgY29udHJpYnV0b3IgcGFja2Fn aW5nIGEgdGhpbmcgd291bGRuJ3Qga25vdyBpbiBhZHZhbmNlDQo+Pj4+IHdoaWNoIHNvbHV0 aW9ucyBjb3VsZCBiZSBhcHByb3ByaWF0ZSBmb3IgdGhlbSAoeW91ciAnc29sdXRpb24gLT4N Cj4+Pj4gcHJvYmxlbScgcGF0Y2g/KSwgcmF0aGVyLCB0aGV5IHN0YXJ0IHdpdGggYSBwcm9i bGVtIGFuZCBhcmUNCj4+Pj4gc2VhcmNoaW5nIGZvciBhbiBhcHByb3ByaWF0ZSBzb2x1dGlv biAobXkgcHJvYmxlbS0+c29sdXRpb24NCj4+Pj4gcGF0Y2gpLg0KPj4+IEkgdGhpbmsgdGhp cyBpZGVhIGNhbiBiZSBkZWJ1bmtlZCBwcmV0dHkgZWFzaWx5LiBJZiBJIGdpdmUgeW91IGEN Cj4+PiBoYW1tZXIgYW5kIEkgdGVsbCB5b3UgInRoaXMgaXMgYSBoYW1tZXIsIHlvdSBjYW4g dXNlIGl0IHRvIHB1dA0KPj4+IG5haWxzIGludG8gYSB3YWxsIiwgYW5kIHlvdSBoYXZlIGEg bmFpbCBhbmQgeW91IHdhbnQgdG8gcHV0IGl0IGludG8NCj4+PiBhIHdhbGwsIHlvdSB3b24n dCBnbyAib2ggbm8sIGhvd2V2ZXIgd2lsbCBJIHB1dCB0aGlzIG5haWwgaW50byBhDQo+Pj4g d2FsbD8iIOKAkyB5b3Ugd2lsbCBzaW1wbHkgdXNlIHRoZSBoYW1tZXIgdG8gZG8gc28uDQo+ PiBUaGUgcGF0Y2ggZG9lcyB0aGlzLCBjdXJyZW50bHkuwqAgSXQgYWxyZWFkeSBwcm9wb3Nl cyBhIG51bWJlciBvZg0KPj4gaGFtbWVycyAocGF0Y2hlcywgc25pcHBldHMgYW5kIHBoYXNl cykgYW5kIHB1cnBvc2VzIChhZGRpbmcgbmV3DQo+PiBmdW5jdGlvbmFsaXR5LCBmaXhpbmcg dGVjaG5pY2FsIGlzc3VlcywgdW5idW5kbGluZywgLi4uKS4NCj4+IEFsc28sIHRoZSBzY2Vu YXJpbyAib2ggbm8sIGhvd2V2ZXIgd2lsbCBJIHB1dCB0aGlzIG5haWwgaW50byBhIHdhbGwi DQo+PiBhY3R1YWxseSBoYXBwZW5lZCAtLSBzZWUgdGhlIFNoZXBoZXJkIGRpc2N1c3Npb24s IHdoZXJlIHRoZXJlIHdhcw0KPj4gYSBsb3Qgb2YgZGlzYWdyZWVtZW50IG9uIGhvdyBuYWls cyAoPSBzbWFsbCB3b3JrLWFyb3VuZCBpbiB0aGUNCj4+IE1ha2VmaWxlKSBzaG91bGQgYmUg cHV0IGluIHdhbGxzICg9IHBhdGNoZXMsIHNuaXBwZXQsIHBoYXNlPykuwqDCoCBJdA0KPj4g d2FzIHRoZSB3aG9sZcKgcmVhc29uIHRvIHN0YXJ0IHdyaXRpbmcgYSBkb2N1bWVudGF0aW9u IHBhdGNoLg0KPiBZb3UgbWlnaHQgd2FudCB0byBhZGQgYSBsaW5rIGhlcmUgaWYgaXQgc3Vw cG9ydHMgeW91ciBhcmd1bWVudCwgYnV0DQo+IHdpdGhvdXQgbG9va2luZyBhdCB0aGUgZGlz Y3Vzc2lvbiB0aGlzIHJhdGhlciBzb3VuZHMgbGlrZSAib2ggbm8sIEkNCj4gaGF2ZSB0aHJl ZSBoYW1tZXJzLCB3aGljaCBvbmUgZG8gSSBwaWNrPyIg4oCTIHdoaWNoLCBmYWlyIGVub3Vn aCwgaXMNCj4gc3RpbGwgYSBwcm9ibGVtLCBidXQgb25lIHRoYXQgbmVpdGhlciBvZiBvdXIg cGF0Y2hlcyB3b3VsZCBjYXVzZSBpbWhvLg0KDQpBcyBJIHRoaW5rIEkndmUgd3JpdHRlbiBw cmV2aW91c2x5LCB0aGUgd2hvbGUgcG9pbnQgd2FzIHRvIHNvbHZlIHRoYXQgDQpwcm9ibGVt LiBGb3IgdGhlIGRpc2N1c3Npb24sIHNlZToNCg0KKiBodHRwczovL2lzc3Vlcy5ndWl4Lmdu dS5vcmcvNTQyMTYNCiogaHR0cHM6Ly95aGV0aWwub3JnL2d1aXgvYzRjMGEwNzEtMmUwMy1k NGQ2LTY3MTgtMDU0MjRkMjFkMTQ2QHRlbGVuZXQuYmUvDQoqIA0KaHR0cHM6Ly95aGV0aWwu b3JnL2d1aXgtZGV2ZWwvODRlMTNlZjdkNDM3MDYyZGY1Y2NhNTFhMTJlNmRhNTQ5MjllMDE3 Ni5jYW1lbEB0ZWxlbmV0LmJlLw0KDQpOb3Qgc29sdmluZyB0aGUgcHJvYmxlbSBkZWZlYXRz IHRoZSB3aG9sZSBwb2ludCwgYXMgdGhlIHB1cnBvc2UgaXMgdG8gDQpzb2x2ZSB0aGF0IHBy b2JsZW0uDQoNCj4+PiBPZiBjb3Vyc2UsIGZvciB0aGlzIHRvIHdvcmsgSSBhbHNvIGhhdmUg dG8gdGVsbCB5b3UgKmhvdyogdG8gdXNlIGENCj4+PiBoYW1tZXIgdG8gcHV0IG5haWxzIGlu dG8gYSB3YWxsLCBidXQgdGhhdCdzIGV4YWN0bHkgd2hhdCBJIGRpZCBpbg0KPj4+IG15IHBh dGNoIGJ5IGluc2VydGluZyB0aGUgcmlnaHQgbm90ZXMgaW50byB0aGUgR3VpeCBtYW51YWwu DQo+PiBBbHNvIGFscmVhZHkgdGhlIGNhc2UuDQo+Pj4gTXkgc29sdXRpb24tPnByb2JsZW0g YXBwcm9hY2ggaGFzIHRoZSBiZW5lZml0LCB0aGF0IGZvbGtzIGNhbiBqdXN0DQo+Pj4gZ28g b3ZlciBhbGwgdGhlIHNvbHV0aW9ucywgY2hlY2sgaWYgdGhlaXIgcHJvYmxlbSBmaXRzLCBh bmQgYXBwbHkNCj4+PiB0aGUgb25lIHRoYXQgc2F5cyAiaGVyZSwgdXNlIHRoaXMiLg0KPj4g QSBwcm9ibGVtLT5zb2x1dGlvbiBzdHJ1Y3R1cmUgaXMgdXNlZnVsIGZvciB0aGF0IHRvbz8N Cj4+IEFuZCBpdCBhbHJlYWR5IGxpc3RzIGFsbCB0aGUgc29sdXRpb25zIChzbmlwcGV0cywg cGhhc2VzIGFuZCBwYXRjaGVzKQ0KPj4gYW5kIGluZm9ybWF0aW9uIHRvIGRlY2lkZSB3aGV0 aGVyIHRoZSBzb2x1dGlvbiBmaXRzIHRoZWlyIHByb2JsZW0NCj4+ICh0aGUgZ3VpZGluZyBw cmluY2lwbGVzLCBhbmQgdGhlIHdvcmtlZC1vdXQgY2FzZXMpLg0KPiBBZ2FpbiwgSSBiZWxp ZXZlIHlvdSdyZSBvdmVyc2VsbGluZyB0aGUgZ3VpZGluZyBwcmluY2lwbGVzLg0KDQpJIG5l dmVyIGNsYWltZWQgdGhleSB3ZXJlIHN1cGVyIGdyZWF0LCBqdXN0IHRoYXQgdGhleSBhcmUg Y29udmVuaWVudCBhbmQgDQpzb2x2ZWQgYSBudW1iZXIgb2YgcHJvYmxlbXMuICBJJ20gbm90 IHNlZWluZyBhbnkgb3ZlcnNlbGxpbmcgaGVyZS4NCg0KPj4+IEFuZCBpZiB0aGV5IGRvbid0 IGZpbmQgYW55dGhpbmcsIHRoZXkgc2VlIHRoZSBoYW5keSBsaXR0bGUgbGluZSBhdA0KPj4+ IHRoZSBib3R0b20gc2F5aW5nICJ1c2Ugd2hhdGV2ZXIgeW91IHRoaW5rIGlzIGNvbnZlbmll bnQiLg0KPj4gTm93aGVyZSBkaWQgdGhlIHBhdGNoIGltcGx5IHRoYXQgdGhlIGxpc3RlZCBj YXNlcyB3ZXJlIGFsbCBjYXNlcy4gSW4NCj4+IGZhY3QsIGluIHR3byBwbGFjZXMgaW4gdGhl IGludHJvZHVjdGlvbiBpdCBpcyBpbXBsaWVkIHRoYXQgdGhlDQo+PiBleGFtcGxlcyBhcmUg bm90IGV4aGF1c3RpdmUsIGFuZCB0aGF0IHRoZXkgY2FuIGNob29zZSBhY2NvcmRpbmcgdG8N Cj4+IGNvbnZlbmllbmNlICBbLi4uXQ0KPiBFbXBoYXNpcyBvbiBoYW5keSBsaXR0bGUgbGlu ZSByYXRoZXIgdGhhbiBuZWVkaW5nIHRvIGJlIHRvbGQgdHdpY2UNCj4gKHBhcnRpY3VsYXJs eSBpZiBwZW9wbGUgaGF2ZSBubyBpZGVhIHdoYXQgdG8gZXhwZWN0IGR1ZSB0byBub3QgaGF2 aW5nDQo+IGxvb2tlZCBhdCB0aGUgd29ya2VkLW91dCBjYXNlcyB5ZXQpLg0KDQpUaGV5IGRv bid0IG5lZWQgdG8gYmUgdG9sZCB0d2ljZS4gIEFsc28sIG15IHBhdGNoIGFsc28gaGFzIHRo YXQgaGFuZHkgDQpsaXR0bGUgbGluZSAoYWxiZWl0IGRpZmZlcmVudGx5IHdvcmRlZCksIHNl ZSB0aGUgJ2d1aWRpbmcgcHJpbmNpcGxlcycuDQoNCkFsc28sIG9uIHRoZSAnbm8gaWRlYSB3 aGF0IHRvIGV4cGVjdCcgLS0gdGhpcyBpcyBleGFjdGx5IHRoZSBzYW1lIGZvciANCnlvdXIg cGF0Y2ggdG9vPyAgSW4gYm90aCBwYXRjaGVzLCBpZiB0aGUgdXNlciBvbmx5IHJlYWRzIHRo ZSANCmludHJvZHVjdGlvbiBhbmQgY29uY2x1c2lvbiAoaWYgYW55KSBhbmQgZG9lc24ndCBy ZWFkIHRoZSBhY3R1YWwgDQoocmVsZXZhbnQgZXhhbXBsZXMpLyhleHBsYW5hdGlvbiBvZiBw YXRjaGVzLCBzbmlwcGV0cywgcGhhc2VzKSwgdGhlbiANCnRoYXQncyB0aGVpciBwcm9ibGVt Lg0KDQo+Pj4gIMKgSSBhbHNvIGV4cGFuZCBhIGxpdHRsZSBvbiB0aGUgYmVuZWZpdHMgYW5k IGRyYXdiYWNrcyBvZg0KPj4+IHRoZXNlIGFwcHJvYWNoZXMgYXMgeW91IHdvdWxkIHdoZW4g ZGVzY3JpYmluZyBkZXNpZ24gcGF0dGVybnMuDQo+PiBUaGlzIGlzIGFsc28gZG9uZSBpbiBt eSBwYXRjaC4gWy4uLl0NCj4gVGhpcyBpcyBub3QgYWJvdXQgdGhlIGNvbnRhaW5lZCBpbmZv cm1hdGlvbiwgYnV0IHRoZSBzdHJ1Y3R1cmUgb2YgdGhlDQo+IGNvbnRhaW5lZCBpbmZvcm1h dGlvbi4NCj4gDQo+IE15IHNvbHV0aW9uLT5wcm9ibGVtIHN0eWxlIGZvbGxvd3Mgcm91Z2hs eSB0aGlzIHN0eWxlOg0KPiAxLiBzb2x1dGlvbg0KPiAyLiBwcm9ibGVtcyBpdCBpcyBrbm93 biB0byBzb2x2ZQ0KPiAzLiBob3cgdG8gdXNlDQo+IDQuIHByb3BlcnRpZXMsIGNhdmVhdHMs IGV0Yy4NCj4gDQo+IFlvdXIgcHJvYmxlbS0+c29sdXRpb24gc3R5bGUgcm91Z2hseSBoYXMg dGhlIGZvbGxvd2luZzoNCj4gMS4gcHJvYmxlbQ0KPiAyLiAoc2V0IG9mKSBzb2x1dGlvbihz KQ0KPiAzLiBpZiBtb3JlIHRoYW4gb25lIHNvbHV0aW9uLCBtYXliZSBhIGhlbHAgdG8gc2Vs ZWN0DQoNCkFsc28sIGluIG5vIHBhcnRpY3VsYXIgb3JkZXINCg0KICAgNC46IGhvdyB0byB1 c2UNCiAgIDUuOiBleHBsYW5hdGlvbiB3aHkgaXQgaXMgcHJlZmVycmVkIChwcm9wZXJ0aWVz LCBjYXZlYXRzPykNCg0KPiANCj4gVGhpcyBtYWtlcyBpdCBzbyB0aGF0IHBlb3BsZSBtaWdo dCBoYXZlIHRvIGdvIHRvIGEgZGlmZmVyZW50IHN1YnNlY3Rpb24NCj4gdGhhbiB0aGUgb25l IHRoZXkgcmVhZCBmb3IgdGhlaXIgc29sdXRpb24gdG8gZmluZCBvdXQgYWJvdXQgcG90ZW50 aWFsDQo+IGNhdmVhdHMsIGUuZy4gbm90IGVtYmVkZGluZyBzdG9yZSBwYXRocyBpbiBhIHNu aXBwZXQuDQoNCkkgYXNzdW1lIHRoZWlyIHByb2JsZW0gd2FzICJYIGRvZXNuJ3QgZmluZCBZ Ii4gIFRoaXMgYmVpbmcgYSB0ZWNobmljYWwgDQppc3N1ZSwgdGhleSBnbyB0byAiRml4aW5n IHRlY2huaWNhbCBpc3N1ZXMiLiAgSW4gdGhhdCBzdWJzdWJzZWN0aW9uLCANCnRoZXJlIGFy ZSB0aGUgd29yZHM6DQoNCj4gU2Vjb25kbHksIGlmIHRoZSBmaXggb2YgYSB0ZWNobmljYWwg aXNzdWUgZW1iZWRzIGEgc3RvcmUgZmlsZSBuYW1lLCB0aGVuDQo+IGl0IGhhcyB0byBiZSBh IHBoYXNlLiAgT3RoZXJ3aXNlLCBpZiB0aGUgc3RvcmUgZmlsZSBuYW1lIHdlcmUgZW1iZWRk ZWQgaW4NCj4gdGhlIHNvdXJjZSwgdGhlIHJlc3VsdCBvZiBAY29tbWFuZHtndWl4IGJ1aWxk IC0tc291cmNlfSB3b3VsZCBiZSB1bnVzYWJsZQ0KPiBvbiBub24tR3VpeCBzeXN0ZW1zIGFu ZCBhbHNvIGxpa2VseSB1bnVzYWJsZSBvbiBHdWl4IHN5c3RlbXMgb2YgYW5vdGhlcg0KPiBh cmNoaXRlY3R1cmUuDQoNCnNvIHRoZXkgYWN0dWFsbHkgZG8ga25vdyBvZiB0aGUgY2F2ZWF0 ICdkb24ndCBlbWJlZCBzdG9yZSBwYXRocyBpbiBhIA0Kc25pcHBldCwgZG8gaXQgaW4gYSBw aGFzZSBpbnN0ZWFkJywgYW5kIHRoZXkgZGlkIG5vdCBuZWVkIHRvIGdvIHRvIGEgDQpkaWZm ZXJlbnQgc3Vic3Vic2VjdGlvbi4NCg0KPj4+IFlvdXIgcHJvYmxlbS0+c29sdXRpb24gYXBw cm9hY2ggaW5zdGVhZCBsZWF2ZXMgcGVvcGxlIHdvbmRlcmluZw0KPj4+IHdoZW4gdGhlaXIg cGFydGljdWxhciB1c2UgY2FzZSBoYXMgbm90IGJlZW4gZGVzY3JpYmVkLg0KPj4gU2VlIG15 IHJlcGx5IHRvIOKAmEFuZCBpZiB0aGV5IGRvbid0IGZpbmQgYW55dGhpbmcsIHRoZXkgc2Vl IHRoZSBoYW5keQ0KPj4gbGl0dGxlIGxpbmUgYXQgdGhlIGJvdHRvbSBzYXlpbmcgInVzZSB3 aGF0ZXZlciB5b3UgdGhpbmsgaXMNCj4+IGNvbnZlbmllbnTigJkuDQo+Pj4gSXQgZ2l2ZXMg dGhlbSBhIHNvbHV0aW9uIHJhdGhlciB0aGFuIHRoZSB0b29scyB0byBidWlsZCBzb2x1dGlv bnMNCj4+PiB3aXRoLg0KPj4gSXQgZG9lcyBnaXZlIHRoZSB0b29sczogc25pcHBldHMsIHBh dGNoZXMgYW5kIHBoYXNlcy4NCj4gQXMgZmFyIGFzIEkgcmVhZCwgaXQgZGVzY3JpYmVzIG5v bmUgb2YgdGhvc2UuICBJdCBwdXRzIG91dCBndWlkaW5nDQo+IHByaW5jaXBsZXMgYW5kIHNv bWUgYWxyZWFkeSB3b3JrZWQtb3V0IGNhc2VzLg0KSGVyZSBhcmUgdGhlIGRlc2NyaXB0aW9u czoNCg0KPiBHdWl4IGhhcyB0cmVlIG1haW4gd2F5cyBvZiBtb2RpZnlpbmcgdGhlIHNvdXJj ZSBjb2RlIG9mIGEgcGFja2FnZSwgdGhhdA0KPiB5b3UgYXMgYSBwYWNrYWdlciBtYXkgdXNl LiAgVGhlc2UgYXJlIHBhdGNoZXMsIHNuaXBwZXRzIGFuZCBwaGFzZXMNCg0KT25jZSB0aGUg dXNlciBrbm93cyBfd2hpY2hfIG9mIHRoZSB0aHJlZSB0aGV5IHNob3VsZCB1c2UgKGJ5IGNv bnN1bHRpbmcNCnRoZSBmb2xsb3dpbmcgc3Vic3Vic2VjdGlvbnMpLCB0aGV5IGNhbiB0aGVu IHNlYXJjaCBmb3IgJ3BhdGNoJywgDQonc25pcHBldCcgYW5kICdwaGFzZXMnIGluIHRoZSBt YW51YWwgZm9yIG1vcmUgaW5mb3JtYXRpb24sIG5vIG5lZWQgdG8gDQpkdXBsaWNhdGUgdGhh dCBpbmZvcm1hdGlvbi4NCg0KPj4gQWxzbywgImdpdmluZyB0aGUgdG9vbHMgdG8gYnVpbGQg c29sdXRpb25zIHdpdGgiIGRvZXMgbm90IGhlbHAgd2l0aA0KPj4gdGhlwqBwcm9ibGVtIHRo YXQgSSBhaW1lZCB0byBzb2x2ZSAtLSB0aGVyZSB3YXMgZGlzYWdyZWVtZW50IG9uIHdoYXQN Cj4+IHRoZcKgYXBwcm9wcmlhdGUgdG9vbHMgYXJlIChzZWU6IFNoZXBoZXJkKSwgc28gaXQg bm90IGp1c3QgbmVlZHMgdG8NCj4+IGdpdmUgdGhlwqB0b29scywgYnV0IGFsc28gdGhlIHNv bHV0aW9ucy4NCj4gSSBkb24ndCBzZWUgaG93IG15IHBhdGNoIGxhY2tzIHRoaXMgaW5mb3Jt YXRpb24gaG93ZXZlci4NCg0KSUlVQywgdGhlIHJhdyBpbmZvcm1hdGlvbiBzaG91bGQgdXN1 YWxseSBiZSBpbmRlZWQgYWxsIHRoZXJlLCBidXQgdGhlIA0KdXNlciBoYXMgdG8gY29uc3Vs dCBfYWxsXyBvZiB0aGUgc2VjdGlvbnMgdG8gZGV0ZXJtaW5lIHdoaWNoIG9wdGlvbiANCihw YXRjaCwgc25pcHBldCwgcGhhc2UpIGlzIGFwcHJvcHJpYXRlLCBoYXZpbmcgdG8gYXNzZW1i bGUgYWxsIHRoZSANCmluZm9ybWF0aW9uIGlzIChhKSBhIHdhc3RlIG9mIHRpbWUgYW5kIChi KSBjYW4gbGVhZCB0byBkaWZmZXJlbnQgDQppbnRlcnByZXRhdGlvbnMgYW5kIGNvbmNsdXNp b25zIChzZWU6IFNoZXBoZXJkKS4NCg0KTW9yZSBjb25jcmV0ZWx5LCBJIGNhbm5vdCB1c2Ug eW91ciBwYXRjaCB0byBkZWNpZGUgYmV0d2VlbiBwaGFzZXMsIA0Kc25pcHBldHMgYW5kIHBh dGNoZXMgZm9yIHRoZSBTaGVwaGVyZCBpc3N1ZToNCg0KKiBub25lIG9mIHRocmVlIGFwcGVh ciB0byBiZSBmb3JiaWRkZW4gYnkgeW91ciBkb2N1bWVudGF0aW9uDQoqIHRoZXJlIGlzIG5v IHJlY29tbWVuZGF0aW9uIGZvciAncGF0Y2hlcycgKElJUkMgaXQgd2Fzbid0IGFjY2VwdGVk IA0KdXBzdHJlYW0gYW5kIHRoZXJlIHdhcyBubyBpbnRlbnQgdG8gc3VibWl0IGl0IHVwc3Ry ZWFtLCBpdCBiZWluZyByZWFsbHkgDQphIEd1aWxlIGJ1Zywgbm90IGEgU2hlcGhlcmQgYnVn KQ0KKiB0aGVyZSBpcyBubyByZWNvbW1lbmRhdGlvbiBmb3Igc25pcHBldHMgKGl0J3MgYWxs IGZyZWUsIG5vIGJ1bmRsaW5nKQ0KKiBidWlsZCBwaGFzZXMgYXJlICd0byBiZSBhdm9pZGVk JyAoYnV0IG5vdCBmb3JiaWRkZW4pLCBhcyBpdCByZXN1bHRlZA0KICAgaW4gb2JzZXJ2YWJs eSBkaWZmZXJlbnQgcnVudGltZSBiZWhhdmlvdXIgKGJlaW5nIGEgYnVnIGZpeCkNCg0KLS0g dGhyZWUgKG9yIGF0IGJlc3QsIHR3bywgaWYgYnVpbGQgcGhhc2VzIGFyZSBkaXNjb3VudGVk KSBvcHRpb25zIA0KcmVtYWluLiAgTXlzZWxmLCBJIHdvdWxkIHRoZW4gY29uc2lkZXIgJ3Nu aXBwZXRzJyB0byBiZSB0aGUgbW9zdCANCmNvbnZlbmllbnQsIGJ1dCBzb21lIG90aGVycyAo c2VlOiBTaGVwaGVyZCwgSUlSQykgd291bGQgcmVhbGx5IHdhbnQgYSANCnBhdGNoIGluc3Rl YWQsIGJlY2F1c2UgJ3BhdGNoZXMgY2FuIGJlIHJldmVydGVkJyBvciBzb21ldGhpbmcgbGlr ZSB0aGF0Lg0KDQpBcyBzdWNoLCB5b3UgYXJlIGdpdmluZyB0aGUgdG9vbHMgKHNuaXBwZXRz IC8gcGF0Y2hlcyAvIHBoYXNlcywgc29tZSANCmRvd25zaWRlcyBhbmQgdXBzaWRlcyksIGJ1 dCBkaWZmZXJlbnQgcGVvcGxlIGNhbiBjb25zdHJ1Y3QgZGlmZmVyZW50IA0Kc29sdXRpb25z IGZyb20gdGhvc2UgdG9vbHMgZXZlbiBpbiB0aGUgc2FtZSBzaXR1YXRpb24sIGxlYWRpbmcg dG8gY29uZmxpY3RzLg0KDQpJZiBJIHVzZSBteSBwYXRjaCBpbnN0ZWFkLCBJIGdvIHRvICJm aXhpbmcgdGVjaG5pY2FsIGlzc3VlcyIuIFRoaXMgDQpzZWN0aW9uIHRlbGxzIG1lIHRvIHVz ZSBhIHBhdGNoIG9yIGEgc25pcHBldC4gIEFzIHRoZSBmaXggaXMgbm90IA0KR3VpeC1zcGVj aWZpYywgaXQgcmVjb21tZW5kcyBhIHBhdGNoIHRvIHNhdmUgdGltZSB3aGVuIHVwc3RyZWFt aW5nLiANCkNvbmNsdXNpb246IHdyaXRlIGEgcGF0Y2guICBJdCB3YXMgYSBHdWlsZSBidWcs IHNvIHRoZSBmaXggd2FzIGEgcGF0Y2ggDQp0byBHdWlsZS4gIEJ1dCB0aGF0IHdvdWxkIHRh a2UgdGltZSBhbmQgdXBzdHJlYW0gdG9vayB0aGUgcmVzcG9uc2liaWxpdHkgDQpmb3IgYSBm aXgsIHNvIHRoZSAnZWZmaWNpZW50IHRpbWUgdGhpbmcnIGRvZXNuJ3QgcmVhbGx5IGFwcGx5 IGFuZCBhIA0Kc21hbGwgd29yay1hcm91bmQgKHNldHRpbmcgb3B0aW1pc2F0aW9uIGZsYWdz KSBzdWZmaWNlcy4NCg0KSW4gdGhpcyBzaXR1YXRpb24sIHRoZSBzdWJzdWJzZWN0aW9uIGRv ZXNuJ3QgY2FyZSBhdCBhbGwgaWYgeW91IGdvIGZvciBhIA0Kc25pcHBldCwgc28gYXBwbHkg dGhlIGxhc3QgZ3VpZGluZyBwcmluY2lwbGU6IGdvIGZvciB0aGUgc2ltcGxlc3QgdGhpbmc6 DQphIHNuaXBwZXQuIChVbmxlc3MgeW91IGFscmVhZHkgaGF2ZSBhIHBhdGNoLCB0aGVuIGEg cGF0Y2ggaXMgc2ltcGxlc3QuKQ0KRG9lcyBzb21lb25lIGVsc2UgaGF2ZSBhIGRpZmZlcmVu dCBpZGVhIG9uIHdoYXQncyBzaW1wbGVzdD8gIERvZXNuJ3QNCnJlYWxseSBtYXR0ZXIsIOKA mFNvbWV0aW1lcyB0aGlzIGlzIHN1YmplY3RpdmUsIHdoaWNoIGlzIGFsc28gZmluZeKAmS4N Cg0KPiBJbg0KPiBwYXJ0aWN1bGFyLCBmb3IgcmV2aWV3IHB1cnBvc2VzLCBtaW5lIHNob3Vs ZCBiZSBlYXNpZXIgdG8gd29yayB3aXRoLg0KPiBGb3IgaW5zdGFuY2UsIHRoZSByZXZpZXdl ciBzZWVzIGEgaGFzaCBlbWJlZGRlZCBpbiBhIHNuaXBwZXQsIHNlZXMgaW4NCj4gdGhlIHNu aXBwZXQgZW50cnkgdGhhdCB5b3Ugc2hvdWxkbid0IGRvIHRoYXQsIGFuZCBjYW4gdGh1cyBz YXkgIm5vcGUsDQo+IGRvbid0IGRvIGEgc25pcHBldCBoZXJlIi4NCg0KSSB0aGluayB3ZSBz aG91bGQgb3B0aW1pc2UgZm9yIHBhY2thZ2VycyBiZWZvcmUgcmV2aWV3ZXJzDQo+IA0KPiBS ZWdhcmRsZXNzIG9mIHdoaWNoIHBhdGNoIHdlIHBpY2ssIGl0IHNob3VsZCBub3QgbWFuZGF0 ZSBhIHBhcnRpY3VsYXINCj4gc29sdXRpb24gaW4gcG90ZW50aWFsbHkgY29udGVudGlvdXMg Y2FzZXMsDQoNCkFjdHVhbGx5IHRoZSB3aG9sZSBwb2ludCB3YXMgdG8gbWFuZGF0ZSBhIHBh cnRpY3VsYXIgc29sdXRpb24gZm9yIHRoZSANCmNvbnRlbnRpb3VzIGNhc2VzLCBzZWUgU2hl cGhlcmQuDQoNCj4gYW5kIGFsc28gcG9pbnQgdG93YXJkcyB0aGUNCj4gcmlnaHQgc29sdXRp b24uICBTZWUgb3VyIGRpc2N1c3Npb25zIG9uIHRoZSBpbmRpdmlkdWFsIHNvbHV0aW9ucyBv bg0KPiBwb2ludHMgaW4gd2hpY2ggSSBiZWxpZXZlIHlvdSd2ZSBlcnJvcmVkLg0KDQpUaGVz ZSBhcmU6DQoNCiogdGhlIHR5cG8ncw0KKiBpbmNsdWRpbmcgInNraXBwaW5nIHRlc3RzIGlu ZGljYXRpbmcgZmFpbHVyZSB1bmRlciDigJhGaXhpbmcgdGVjaG5pY2FsIA0KaXNzdWVz4oCZ Ig0KKiAiZG9uJ3QgbWVudGlvbiBmaWxlIG5hbWVzIG9mIG5vbi1mcmVlIHRoaW5ncyBpbiBw YXRjaGVzIg0KDQpEaWQgSSBtaXNzIGFueT8NCg0KR3JlZXRpbmdzLA0KTWF4aW1lDQo= --------------tRDWi1bv5GRDIutW2FCxCszJ Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc" Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2 ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc /gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4 LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0 k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D =3DOVqp -----END PGP PUBLIC KEY BLOCK----- --------------tRDWi1bv5GRDIutW2FCxCszJ-- --------------LEdw0eVxVIORtTBS4903Yefe-- --------------ztoDhl3zz8S7BeO6MhLpiOLo Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYxsgEQUDAAAAAAAKCRBJ4+4iGRcl7lVn AP0c+nSCLm1gIRDKhyzhSqGikSO1/NELtlT7yKCO7xDq4gD/bWt8MRqdlRdLGYTDFgFSL4Nhnao0 EVHaLzEKmrPgbAk= =ftmT -----END PGP SIGNATURE----- --------------ztoDhl3zz8S7BeO6MhLpiOLo--
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.Received: (at 57598) by debbugs.gnu.org; 9 Sep 2022 08:04:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 09 04:04:44 2022 Received: from localhost ([127.0.0.1]:60854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oWZ0F-0006Og-Dx for submit <at> debbugs.gnu.org; Fri, 09 Sep 2022 04:04:44 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:4606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <liliana.prikler@HIDDEN>) id 1oWZ0A-0006OR-WF for 57598 <at> debbugs.gnu.org; Fri, 09 Sep 2022 04:04:42 -0400 Received: from kagayaki.fritz.box (85-127-52-93.dsl.dynamic.surfer.at [85.127.52.93]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4MP7nF6sNXz3wkj; Fri, 9 Sep 2022 10:04:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1662710674; bh=wt03wgni0fyW7+DkIj8549+pqugm7pa/dcKT+FftKvs=; h=Subject:From:To:Date:In-Reply-To:References; b=ojTfoV6Q4mRmaAN1svBf5VRWzsRW57q8CpVPwXqFg8J4NBWvtHYYKkGKVs0eHi85J cjAQWkUtOn5OppSaarjNlqZJleK8MLKiypb/UMeNiKeFR3xJD/woBN8Z9w+5vZ7uR1 jZbB6eeq63h328fPbam6jBRZCghC1PTP5za0bhbk= Message-ID: <1e707c8e345af7b2fb0353c5f1c0e37d716e3308.camel@HIDDEN> Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc. From: Liliana Marie Prikler <liliana.prikler@HIDDEN> To: Maxime Devos <maximedevos@HIDDEN>, 57598 <at> debbugs.gnu.org Date: Fri, 09 Sep 2022 10:04:32 +0200 In-Reply-To: <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN> References: <20220905160048.18173-1-maximedevos@HIDDEN> <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN> <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN> <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN> <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57598 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Am Donnerstag, dem 08.09.2022 um 13:12 +0200 schrieb Maxime Devos: > On 07-09-2022 10:09, Liliana Marie Prikler wrote: > > Am Dienstag, dem 06.09.2022 um 22:21 +0200 schrieb Maxime Devos: > > > It is, to my knowledge, not forbidden to mention non-free > > > software by name in code, as long as its not a recommendation > > > (explicit or implied). > > Indeed, there is no hard rule, hence "avoid" rather than "forbid". > What I also meant is, that to my knowledge there is no soft rule > either. Again, why should we avoid this, what's the point of that? In descriptions, it is wise to do so because it helps software stand on its own merits rather than just "being a clone of this thing you aren't allowed to have" (this is real criticism pointed at us from the proprietary software embracers). See for instance minetest, whichisy > How does ignoring a test fix the technical issue identified by the > test (sometimes, the technical issue being a bug in the test itself)? It fixes the technical issue that an otherwise functional package (w.r.t. the N tests that don't fail) builds. This is a particularly useful distinction with tests that require a network connection and thus have to fail in a build container, or are known flaky upstream and thus cause reproducibility issues. > > There still is the difference that phases are clearly delimited > > while snippets are a block of code that shouldn't get too large. > Snippets are delimited clearly as well, though, with the 'snippet' > field? > And the limitations of snippet length and phases length are the same > -- no limits, though conciseness is appreciate as always. True, but phases can be made to do just one thing, whereas snippets have to fix everything that's wrong in more or less one (begin ...). This is a noticable distinction. > > > I think my version at least hinted at this practice in a more > > concise way, so it's not impossible to mention. [...] > I agree it's possible -- as I replied previously: > > I suppose a section could be added somewhere to properly document > > the 'embedding store file names' practice, and insert a > > cross-reference, > I don't think documenting the how of the practice should be done > in this section, properly explaining 'search-input-file' / 'search- > input-directory', 'inputs / native-inputs', 'bash' being an implicit > input but you still have to add it to 'inputs' in some cases because > of cross-compilation, this-package-input and this-package-native- > input ... would make the > subsubsection a bit too long I think, distracting from other > situations, hence the proposal for a cross-reference. > How about leaving the 'how to embed store file names' for a separate > documentation patch and section, adding a cross-reference later? See above, "I suppose a section could be added..." means I'm somewhat indifferent to whether it's done now or later; I would however very much prefer a wording that points people toward this practice existing, even if they have to go look in the code for examples. Alternatively, a footnote for the most common case (search-input-file inputs "bin/command") ought to suffice for the time being. > > > > I think calling back to a guiding principle in and of itself shows > > that the section has grown too long to remember it by the point you > > come to this example, > This has nothing to do with length and remembering, but rather with > explaining why a phase must be used -- to explain that, I state which > principle applies (as mentioned previously). If I removed the > explanations, I would just be stating how to do things, without > giving a logical reasoning on the 'why'. IMHO, I think a reader who remembers the guiding principles should see that it applies. > > and I think that's more problematic than merely the > > callback. If you didn't need to divide this into subsubsections, > > you could introduce the guiding principles in a way that feels more > > natural. > I consider it more natural to have the 'guiding principles' _before_ > the concrete cases, as they are meant to be 'guiding' and > 'principles'. > It's like 'starting from first principles', there introducing the > first principles as you go is ad-hoc. > The guiding principles also need to be outside the examples, in case > one of the examples doesn't apply to the packager's use case, such > that they can fall-back to the guiding principles. > Also, in your patch you are dividing things in subsubsections as > well, just under a different name and different representation (table > entries in a subsection), as mentioned previously. A table entry is not a subsection, as much as you want it to be that. Also, your guiding principles are (with one exception) really just invariants that ought to hold for the source field of a package. As such, I think it would be easier to state "A package's source should be the smallest corresponding source in terms of uncompressed file size. This corresponding source must consist only of free software (note Free Software) and should build on all platforms supported by upstream." Note how smallest naturally implies unbundling bundled sources. > > I still find this wording very confusing. Perhaps "To add new > > functionality, a patch is almost always the best choice. For one, > > it is likely that the new functionality requires changing multiple > > lines of source code, which is more convenient to do with a patch > > than with a snippet. Further, patches can be taken from and > > submitted to upstreams more easily. If your patch has not been > > submitted to upstream, consider doing so." > It loses some information (that patches are preferred) and > (after re-adding the conclusion) is more verbose, which appears > to be considered very important. Which conclusion is there to re-add? The conclusion is already stated in the beginning: patches are almost always the best choice. Then two reasons as for why. The part w.r.t. upstreaming changes has also been addressed. > > An enumeration ought to have at least three elements (otherwise > > it's just a pair), and I think if we do proper counting and omit > > no-brainers, such as the "only free software" part that has already > > been mentioned, we come very close to skirting that line. > The "only free software" is mentioned elsewhere, yes, but it is one > of the principles for deciding between snippets, phases and patches. > While you call it a no-brainer, it is sometimes neglected, so it > sounds important to me to explicitly list it. > Merging the 3th and 4th @item, I count 4 principles, so it fits with > an enumeration. > Also, I'm not following your point here -- your complaint was that > they aren't guiding principles (based on the number of them), but > your response is that they might not form an enumeration? They are > named the guiding principles, not the guiding enumeration. What have > enumerations to do with anything? I'm using enumeration as a super term here, which can be ((sub)sub)sections, chapters, list elements, whatever, and my claim is that we barely have enough principles to allow the use of a plural. Adding to that, now that I think of it, I also doubt their usefulness in guiding. "Use whatever feels convenient, but note that that might be subjective" is more useful at the end of the section when a user didn't find what they were looking for than at the start. > > > > which (along with its sheer length) is my main > > > > complaint with the way you've phrased things. > > > (I'm assuming "its = the patch as a whole" here) > > > > > > I could remove another section of the manual to compensate for > > > the additional length, but I doubt that's what you intended. I > > > do not see the problem with the sheer length -- we have a bit of > > > a documentation problem in Guix, there is lots of useful > > > information that is currently undocumented. > > > I do not think there have been any complaints about the manual > > > being too long, if anything, it's too short. > > I personally tend towards "less verbose", hence my complaint of > > describing something with many words that could be described with > > fewer. A section can still be too long while the chapter around it > > is too short. > Do you have anything in particular in mind? This is more of a broad statement that applies to the patch as a whole than to any of its constituent parts in particular. However, in some cases where I think it's particularly noticable, I'll try to point out shorter formulations. > > > I've written some documentation, it was originally a bit hard to > > > follow so in a next version I've restructured it a bit and > > > explained more, this restructuring and explanation entailed some > > > additional length. > > > > > > There had been some proposals for additional cases to document, > > > so they were added, increasing the length. You have added new > > > information is your patch, it was considered useful so I've > > > integrated some of it in my patch, increasing the length. (I > > > didn't integrate all of the new parts, if I did, it would > > > increase even further. (If desired, in can integrate the rest, > > > at cost of some time.)). > > My patch did not just state some things you missed, it also omitted > > things that I think are either not necessary or probably better > > documented elsewhere. > What particular things do you have in mind, and where do you > think they should better be documented? I can move things > around a bit and add cross-references. > > > > > I do not see what the problem is with additional length as long > > > as this additional length comes with additional useful > > > information and the manual is well-structured (e.g. with > > > (sub)(sub)sections, chapters and indices) -- we do not have a > > > page limit. > > > > > > At worst, perhaps the same information could perhaps be encoded > > > with fewer words? I could compare the two patches to see which > > > one formulates certain information in the fewest words, and > > > choose the least verbose of the two for each piece of information > > > that is present in both? > > > > > > Also, comparing the two patches, my patch has 40 more lines, but > > > about 25 of them are for noting the guiding principles (which are > > > absent in your patch). > > > Compensating for that, the patches are about the same length, so > > > I do not think that 'sheer length' is accurate here. > > 25 lines calling back to earlier information are, imho, an > > indicator that the section is too long. Imagine you'd have twenty- > > five function calls to guiding_principles(n) in your program – at > > some point, you'd try to cache those. > (define cached-guiding-principles > (delay (list (guiding-principle-0) > [...] > (guiding-principle-24)))) > Caching the guiding principles does not reduce the length. > I don't see the problem with calling back to earlier information. > Also, it isn't earlier information, there is no nice list of guiding > principles anywhere else. At the risk of responding jokingly to what was meant serious: I didn't know we suddenly gained 20 guiding principles. > > > > > Going down to subsubsections just to find out where patches are > > > > appropriate, is imho overkill. > > > The 'going down to subsubsection' is the case for your patch too, > > > though? In my case, it's a subsubsection, in your case it's a > > > table > > > entry inside a subsection, both are the same level of nesting. > > These are still two very different kinds of nesting. A table fits > > onto a (virtual) page more easily than several subsections. > I suppose table items might take two less line or so less than > subsubsections, but I don't think that's sufficient reason to step > away from a nice section structure. Another reason is that you can end a table in the middle of a section, which you can't do with subsections. Hence why I'm able to put a remark at the bottom, which you have to clumsily fit into the top. > > > Also, it's a matter of different structure -- in my v2 and v3 > > > patch, I have a 'problem -> solution' structure -- the idea is > > > that the packages has a problem, they look at the section, they > > > read the subsubsection names, select the > > > subsubsection that matches their problem and read the solution -- > > > in short, the idea is to provide a solution to the problem. > > > > > > Your structure is the other way around -- for solutions (patches, > > > snippets, phases), it gives the permitted problems to apply it > > > to. > > > > > > So yes, your patch is more convenient for finding out where > > > patches are appropriate. I do not see the benefit of that though > > > -- a new contributor packaging a thing wouldn't know in advance > > > which solutions could be appropriate for them (your 'solution -> > > > problem' patch?), rather, they start with a problem and are > > > searching for an appropriate solution (my problem->solution > > > patch). > > I think this idea can be debunked pretty easily. If I give you a > > hammer and I tell you "this is a hammer, you can use it to put > > nails into a wall", and you have a nail and you want to put it into > > a wall, you won't go "oh no, however will I put this nail into a > > wall?" – you will simply use the hammer to do so. > The patch does this, currently. It already proposes a number of > hammers (patches, snippets and phases) and purposes (adding new > functionality, fixing technical issues, unbundling, ...). > Also, the scenario "oh no, however will I put this nail into a wall" > actually happened -- see the Shepherd discussion, where there was > a lot of disagreement on how nails (= small work-around in the > Makefile) should be put in walls (= patches, snippet, phase?). It > was the whole reason to start writing a documentation patch. You might want to add a link here if it supports your argument, but without looking at the discussion this rather sounds like "oh no, I have three hammers, which one do I pick?" – which, fair enough, is still a problem, but one that neither of our patches would cause imho. > > Of course, for this to work I also have to tell you *how* to use a > > hammer to put nails into a wall, but that's exactly what I did in > > my patch by inserting the right notes into the Guix manual. > Also already the case. > > My solution->problem approach has the benefit, that folks can just > > go over all the solutions, check if their problem fits, and apply > > the one that says "here, use this". > A problem->solution structure is useful for that too? > And it already lists all the solutions (snippets, phases and patches) > and information to decide whether the solution fits their problem > (the guiding principles, and the worked-out cases). Again, I believe you're overselling the guiding principles. > > And if they don't find anything, they see the handy little line at > > the bottom saying "use whatever you think is convenient". > Nowhere did the patch imply that the listed cases were all cases. In > fact, in two places in the introduction it is implied that the > examples are not exhaustive, and that they can choose according to > convenience [...] Emphasis on handy little line rather than needing to be told twice (particularly if people have no idea what to expect due to not having looked at the worked-out cases yet). > > I also expand a little on the benefits and drawbacks of > > these approaches as you would when describing design patterns. > This is also done in my patch. [...] This is not about the contained information, but the structure of the contained information. My solution->problem style follows roughly this style: 1. solution 2. problems it is known to solve 3. how to use 4. properties, caveats, etc. Your problem->solution style roughly has the following: 1. problem 2. (set of) solution(s) 3. if more than one solution, maybe a help to select This makes it so that people might have to go to a different subsection than the one they read for their solution to find out about potential caveats, e.g. not embedding store paths in a snippet. > > Your problem->solution approach instead leaves people wondering > > when their particular use case has not been described. > See my reply to ‘And if they don't find anything, they see the handy > little line at the bottom saying "use whatever you think is > convenient’. > > It gives them a solution rather than the tools to build solutions > > with. > It does give the tools: snippets, patches and phases. As far as I read, it describes none of those. It puts out guiding principles and some already worked-out cases. > Also, "giving the tools to build solutions with" does not help with > the problem that I aimed to solve -- there was disagreement on what > the appropriate tools are (see: Shepherd), so it not just needs to > give the tools, but also the solutions. I don't see how my patch lacks this information however. In particular, for review purposes, mine should be easier to work with. For instance, the reviewer sees a hash embedded in a snippet, sees in the snippet entry that you shouldn't do that, and can thus say "nope, don't do a snippet here". Regardless of which patch we pick, it should not mandate a particular solution in potentially contentious cases, and also point towards the right solution. See our discussions on the individual solutions on points in which I believe you've errored. Cheers
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.
Received: (at 57598) by debbugs.gnu.org; 8 Sep 2022 11:12:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 08 07:12:54 2022
Received: from localhost ([127.0.0.1]:57364 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oWFSm-0002LM-S8
for submit <at> debbugs.gnu.org; Thu, 08 Sep 2022 07:12:54 -0400
Received: from laurent.telenet-ops.be ([195.130.137.89]:36376)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <maximedevos@HIDDEN>) id 1oWFSh-0002LA-KM
for 57598 <at> debbugs.gnu.org; Thu, 08 Sep 2022 07:12:51 -0400
Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]
([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16])
by laurent.telenet-ops.be with bizsmtp
id HPCj2800E20ykKC01PCjxg; Thu, 08 Sep 2022 13:12:46 +0200
Message-ID: <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN>
Date: Thu, 8 Sep 2022 13:12:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.12.0
Content-Language: en-US
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>,
57598 <at> debbugs.gnu.org
References: <20220905160048.18173-1-maximedevos@HIDDEN>
<0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
<d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
<44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
From: Maxime Devos <maximedevos@HIDDEN>
Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc.
In-Reply-To: <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="------------bYZznqRF4e00yv03Q3Otn4Cv"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22;
t=1662635566; bh=BVj7tKpf7nZIYzt8MDLzRBiS15zOU/pDnYZAaFh4sMU=;
h=Date:To:References:From:Subject:In-Reply-To;
b=L9pccPYsqDvdVfGfZo600Nvy5POMADKNHMwjwsR3tsM03UkqiVvW1cS2VIZ6fbu2F
q1afo3I3P0ab0PmnTKbeYohJ+QgqyVhYEfJD09a6c88psEKDXrdp/hR8oTX7wa09nt
GlKKHDd8+NqBbowj6Uq5RYtPHH6e9QnU1pXfEbGMM3APzn5s3Lnn6blt/1AqmNnV4q
y+pOXtLckMpIppflgMLJXbq7Ncv/+HR2bzncx0gkJzpHzCZAEWkTuE05lIEFC3efDI
81oGJD4W18n3zJpS46Z/l7pSKXJBLHUqg/UefopNbEWNeLIq4xRK7NKqJwxOIWJgH3
jyLSbWMBrvq8w==
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 57598
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------bYZznqRF4e00yv03Q3Otn4Cv
Content-Type: multipart/mixed; boundary="------------N4yS7ui6DXqk1oJogkEaW0eQ";
protected-headers="v1"
From: Maxime Devos <maximedevos@HIDDEN>
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>,
57598 <at> debbugs.gnu.org
Message-ID: <b33540cb-0c72-6170-34d0-b8df4ab79b8f@HIDDEN>
Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc.
References: <20220905160048.18173-1-maximedevos@HIDDEN>
<0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
<d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
<44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
In-Reply-To: <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
--------------N4yS7ui6DXqk1oJogkEaW0eQ
Content-Type: multipart/mixed; boundary="------------lT8JlkWSD5VQXD90Dz1boRGV"
--------------lT8JlkWSD5VQXD90Dz1boRGV
Content-Type: multipart/alternative;
boundary="------------fiI7W13Wn7SOCrw0E7hFeOyo"
--------------fiI7W13Wn7SOCrw0E7hFeOyo
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64
T24gMDctMDktMjAyMiAxMDowOSwgTGlsaWFuYSBNYXJpZSBQcmlrbGVyIHdyb3RlOg0KDQo+
IEFtIERpZW5zdGFnLCBkZW0gMDYuMDkuMjAyMiB1bSAyMjoyMSArMDIwMCBzY2hyaWViIE1h
eGltZSBEZXZvczoNCj4+PiBXZSBhbHNvIGF2b2lkIHNwZWxsaW5nIG91dCB0aGUgbm9uLWZy
ZWUgZmlsZW5hbWUgd2hlcmUgcG9zc2libGUsDQo+Pj4gcHJlZmVycmluZyBrZWVwIGxpc3Rz
IG92ZXIgcmVtb3ZlIGxpc3RzLCB3aGljaCB0aGlzIGtpbmQgb2YgcGF0Y2hlcw0KPj4+IHdv
dWxkIGJlLg0KPj4gU2hvdWxkIHdlPyBJJ20gbm90IHNlZWluZyB0aGUgcG9pbnQgb2YgdGhh
dC4gSSBoYXZlIG5vdCBleHBlcmllbmNlZA0KPj4gYW55IHN1Y2ggYXZvaWRhbmNlIG15c2Vs
Ziwgc2VlIGUuZy4gJ3Rlbm5peCcsICduZXZlcmJhbGwnIGFuZA0KPj4gJ3Nob2d1bicuICBJ
dCBpcywgdG8gbXkga25vd2xlZGdlLCBub3QgZm9yYmlkZGVuIHRvIG1lbnRpb24gbm9uLWZy
ZWUNCj4+IHNvZnR3YXJlIGJ5IG5hbWUgaW4gY29kZSwgYXMgbG9uZyBhcyBpdHMgbm90IGEg
cmVjb21tZW5kYXRpb24NCj4+IChleHBsaWNpdCBvciBpbXBsaWVkKS4NCj4gSW5kZWVkLCAg
dGhlcmUgaXMgbm8gaGFyZCBydWxlLCBoZW5jZSAiYXZvaWQiIHJhdGhlciB0aGFuICJmb3Ji
aWQiLg0KDQpXaGF0IEkgYWxzbyBtZWFudCBpcywgdGhhdCB0byBteSBrbm93bGVkZ2UgdGhl
cmUgaXMgbm8gc29mdCBydWxlIGVpdGhlci4NCg0KQWdhaW4sIHdoeSBzaG91bGQgd2UgYXZv
aWQgdGhpcywgd2hhdCdzIHRoZSBwb2ludCBvZiB0aGF0Pw0KDQo+Pj4+ICtAc3Vic3Vic2Vj
dGlvbiBGaXhpbmcgdGVjaG5pY2FsIGlzc3VlcyAoY29tcGlsYXRpb24gZXJyb3JzLCB0ZXN0
DQo+Pj4+IGZhaWx1cmVzLCBvdGhlciBidWdzIC4uLikNCj4+Pj4gWy4uLl0NCj4+PiBJIGFt
IHByZXR0eSBzdXJlIHRoYXQgbW9zdCBvZiB0aGVzZSBhcmUgKm5vdCogZG9uZSBpbiBzbmlw
cGV0cywgYnV0DQo+Pj4gcmF0aGVyIHBoYXNlcywgaWYgdGhleSBvbmx5IGFmZmVjdCBHdWl4
LsKgIEluIHBhcnRpY3VsYXIsIGdyZXAgZm9yDQo+Pj4gZmFpbGluZy10ZXN0cyBhbmQgeW91
IHdpbGwgZmluZCBhIGZldyBwaGFzZXMgZGlzYWJsaW5nIHRoZW0uDQo+PiBJIGRvIG5vdCB0
aGluayB0aGF0IGlnbm9yaW5nIGEgdGVzdCBjb3VudHMgYXMgYSBidWcgZml4LsKgIEknbGwg
YWRkIGl0DQo+PiB0byB0aGlzIHN1YnN1YnNlY3Rpb24sIGF0IGNvc3Qgb2Ygc29tZSBhZGRp
dGlvbmFsIGxlbmd0aC4NCj4gSSBkbyB0aGluayBpdCBjb3VudHMgYXMgImZpeGluZyB0ZWNo
bmljYWwgaXNzdWVzIHN1Y2ggYXMgdGVzdA0KPiBmYWlsdXJlcyIuDQpIb3cgZG9lcyBpZ25v
cmluZyBhIHRlc3QgZml4IHRoZSB0ZWNobmljYWwgaXNzdWUgaWRlbnRpZmllZCBieSB0aGUg
dGVzdA0KKHNvbWV0aW1lcywgdGhlIHRlY2huaWNhbCBpc3N1ZSBiZWluZyBhIGJ1ZyBpbiB0
aGUgdGVzdCBpdHNlbGYpPw0KPj4+IEluIGZhY3QsIGFzIGZhciBhcyBmaWxlcyB0aGF0IHdp
bGwgbm90IGJlIGluc3RhbGxlZCBhcmUgY29uY2VybmVkLA0KPj4+IEkgdGhpbmsgcGhhc2Vz
IG91Z2h0IHRvIGJlIHByZWZlcnJlZCwgYmVjYXVzZSB0aGV5J3JlIGVhc2llciB0bw0KPj4+
IHRha2UgYXdheSBpZiBhbiBhY3R1YWwgZml4IGlzIG1hZGUuDQo+PiBJIGRvIG5vdCBzZWUg
YSBkaWZmZXJlbmNlIGluIGhhcmRuZXNzL2Vhc3luZXNzIGJldHdlZW4gcmVtb3ZpbmcgYQ0K
Pj4gcGhhc2UgYW5kIHJlbW92aW5nIGEgc25pcHBldCAoYm90aCBhcmUganVzdCBhIG1hdHRl
ciBvZiBvcGVuaW5nDQo+PiBhbiBlZGl0b3IsIHBvaW50aW5nIGl0IGF0IGdudS9wYWNrYWdl
cy8uLi4gYW5kIHJlbW92aW5nIGEgZmV3IGxpbmVzKSwNCj4+IHRob3VnaCBJIGRvIGNvbnNp
ZGVyIHJlbW92aW5nIGEgcGF0Y2ggdG8gYmUgc2xpZ2h0bHkgaGFyZGVyIChiZWNhdXNlDQo+
PiBnbnUvbG9jYWwubWsgaXMgZWFzeSB0byBmb3JnZXQpLg0KPiBUaGVyZSBzdGlsbCBpcyB0
aGUgZGlmZmVyZW5jZSB0aGF0IHBoYXNlcyBhcmUgY2xlYXJseSBkZWxpbWl0ZWQgd2hpbGUN
Cj4gc25pcHBldHMgYXJlIGEgYmxvY2sgb2YgY29kZSB0aGF0IHNob3VsZG4ndCBnZXQgdG9v
IGxhcmdlLg0KDQpTbmlwcGV0cyBhcmUgZGVsaW1pdGVkIGNsZWFybHkgYXMgd2VsbCwgdGhv
dWdoLCB3aXRoIHRoZSAnc25pcHBldCcgZmllbGQ/DQoNCkFuZCB0aGUgbGltaXRhdGlvbnMg
b2Ygc25pcHBldCBsZW5ndGggYW5kIHBoYXNlcyBsZW5ndGggYXJlIHRoZSBzYW1lDQotLSBu
byBsaW1pdHMsIHRob3VnaCBjb25jaXNlbmVzcyBpcyBhcHByZWNpYXRlIGFzIGFsd2F5cy4N
Cg0KPj4+IEZvciB0aGUgc3RvcmUgcGF0aCBlbWJlZGRpbmcsIHRoYXQncyBhIHJhdGhlciBy
b3VuZGFib3V0IHdheSBvZg0KPj4+IHNheWluZyB0aGF0IGNvbnRyaWJ1dGVycyAqb3VnaHQg
dG8qIGVtYmVkIHN0b3JlIHBhdGhzIG9mIGNlcnRhaW5nDQo+Pj4gdGhpbmdzLCBzdWNoIGFz
IGNvbW1hbmRzIGludm9rZWQgdmlhIGV4ZWMgZXQgYWwuDQo+PiBJdCdzIG5vdD8gSXQncyBr
aW5kIG9mIGltcGxpZWQsIHllcywgYnV0IHRoZSBwdXJwb3NlIGlzbid0IGJlaW5nIGENCj4+
ICd5b3Ugc2hvdWxkIGVtYmVkIHN0b3JlIHBhdGhzJyAoc3Vic3ViKXNlY3Rpb24sIGJ1dCBy
YXRoZXIsICdpZiB5b3UNCj4+IGdvIGVtYmVkZGluZyBzdG9yZSBwYXRocyAoYXQgbGVhc3Qg
Zm9yIGZpeGluZyBhIHRlY2huaWNhbCBpc3N1ZSksIGRvDQo+PiBpdCBpbiBhIHBoYXNlJy4N
Cj4+DQo+PiBJJ20gbm90IGZvbGxvd2luZyB3aGF0IHRoZSBjb21wbGFpbnQgaXMsIEkgc3Vw
cG9zZSBhIHNlY3Rpb24gY291bGQgYmUNCj4+IGFkZGVkIHNvbWV3aGVyZSB0byBwcm9wZXJs
eSBkb2N1bWVudCB0aGUgJ2VtYmVkZGluZyBzdG9yZSBmaWxlIG5hbWVzJw0KPj4gcHJhY3Rp
Y2UsIGFuZCBpbnNlcnQgYSBjcm9zcy1yZWZlcmVuY2UsIGJ1dCB0aGF0IHdhc24ndCB0aGUg
cHVycG9zZQ0KPj4gb2YgdGhlIHBhdGNoIGFuZCBnb2luZyBieSBsYXRlciByZXNwb25zZXMs
IHlvdSBzZWVtIG9wcG9zZWQgdG8gbWFraW5nDQo+PiB0aGluZ3MgbG9uZ2VyLg0KPj4NCj4+
IFRoZSBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB0byByZW1vdmUgdGhpcyBpbmZvcm1hdGlvbiwg
YnV0IHRoZW4NCj4+IHZhbHVhYmxlIGluZm9ybWF0aW9uIHdvdWxkIGJlIGxvc3QgKHRoZXJl
IGhhZCBiZWVuIHNvbWUgY2FzZXMgd2hlcmUNCj4+IHN0b3JlIGZpbGUgbmFtZXMgd2VyZSBl
bWJlZGRlZCBpbiBvcmlnaW4pLg0KPiBJIHRoaW5rIG15IHZlcnNpb24gYXQgbGVhc3QgaGlu
dGVkIGF0IHRoaXMgcHJhY3RpY2UgaW4gYSBtb3JlIGNvbmNpc2UNCj4gd2F5LCBzbyBpdCdz
IG5vdCBpbXBvc3NpYmxlIHRvIG1lbnRpb24uIFsuLi5dDQoNCkkgYWdyZWUgaXQncyBwb3Nz
aWJsZSAtLSBhcyBJIHJlcGxpZWQgcHJldmlvdXNseToNCg0KPiBJIHN1cHBvc2UgYSBzZWN0
aW9uIGNvdWxkIGJlIGFkZGVkIHNvbWV3aGVyZSB0byBwcm9wZXJseSBkb2N1bWVudCB0aGUN
Cj4gJ2VtYmVkZGluZyBzdG9yZSBmaWxlIG5hbWVzJyBwcmFjdGljZSwgYW5kIGluc2VydCBh
IGNyb3NzLXJlZmVyZW5jZSwNCkkgZG9uJ3QgdGhpbmsgZG9jdW1lbnRpbmcgdGhlIGhvdyBv
ZiB0aGUgcHJhY3RpY2Ugc2hvdWxkIGJlIGRvbmUNCmluIHRoaXMgc2VjdGlvbiwgcHJvcGVy
bHkgZXhwbGFpbmluZyAnc2VhcmNoLWlucHV0LWZpbGUnIC8gDQonc2VhcmNoLWlucHV0LWRp
cmVjdG9yeScsDQonaW5wdXRzIC8gbmF0aXZlLWlucHV0cycsICdiYXNoJyBiZWluZyBhbiBp
bXBsaWNpdCBpbnB1dCBidXQgeW91IHN0aWxsDQpoYXZlIHRvIGFkZCBpdCB0byAnaW5wdXRz
JyBpbiBzb21lIGNhc2VzIGJlY2F1c2Ugb2YgY3Jvc3MtY29tcGlsYXRpb24sDQp0aGlzLXBh
Y2thZ2UtaW5wdXQgYW5kIHRoaXMtcGFja2FnZS1uYXRpdmUtaW5wdXQgLi4uIHdvdWxkIG1h
a2UgdGhlDQpzdWJzdWJzZWN0aW9uIGEgYml0IHRvbyBsb25nIEkgdGhpbmssIGRpc3RyYWN0
aW5nIGZyb20gb3RoZXIgc2l0dWF0aW9ucywNCmhlbmNlIHRoZSBwcm9wb3NhbCBmb3IgYSBj
cm9zcy1yZWZlcmVuY2UuDQoNCkhvdyBhYm91dCBsZWF2aW5nIHRoZSAnaG93IHRvIGVtYmVk
IHN0b3JlIGZpbGUgbmFtZXMnIGZvciBhIHNlcGFyYXRlDQpkb2N1bWVudGF0aW9uIHBhdGNo
IGFuZCBzZWN0aW9uLCBhZGRpbmcgYSBjcm9zcy1yZWZlcmVuY2UgbGF0ZXI/DQoNCj4+Pj4g
T3RoZXJ3aXNlLCBpZiB0aGUgc3RvcmUNCj4+Pj4gK2ZpbGUgbmFtZSB3ZXJlIGVtYmVkZGVk
IGluIHRoZSBzb3VyY2UsIHRoZSByZXN1bHQgb2YNCj4+Pj4gQGNvbW1hbmR7Z3VpeCBidWls
ZA0KPj4+PiArLS1zb3VyY2V9IHdvdWxkIGJlIHVudXNhYmxlIG9uIG5vbi1HdWl4IHN5c3Rl
bXMgYW5kIGFsc28gbGlrZWx5DQo+Pj4+IHVudXNhYmxlDQo+Pj4+ICtvbiBHdWl4IHN5c3Rl
bXMgb2YgYW5vdGhlciBhcmNoaXRlY3R1cmUuDQo+Pj4gV2h5IGFyZSB5b3UgcmVwZWF0aW5n
IGEgZ3VpZGluZyBwcmluY2lwbGU/DQo+PiBJJ20gc2hvd2luZyB3aHksIGluIHRoaXMgY2Fz
ZSwgYSBwaGFzZSBtdXN0IGJlIHVzZWQsIGJ5IG5vdGluZyB0aGF0DQo+PiBub3QgZG9pbmcg
c28gd291bGQgYmUgY29udHJhcnkgdG8gb25lIG9mIHRoZSBwcmluY2lwbGVzLg0KPj4NCj4+
IElmIG5vdCByZXBlYXRpbmcgdGhlIHByaW5jaXBsZSBpcyBkZXNpcmVkLCBJIGNvdWxkIHBl
cmhhcHMgbnVtYmVyDQo+PiB0aGVtLCBhbmQgcmVmZXIgdG8gdGhlIHByaW5jaXBsZXMgYnkg
bnVtYmVyIGluc3RlYWQgb2YgcmVzdGF0aW5nDQo+PiB0aGVtPyBXb3VsZCByZWR1Y2UgdGhl
IGxlbmd0aCBhIGxpdHRsZS4NCj4gSSB0aGluayBjYWxsaW5nIGJhY2sgdG8gYSBndWlkaW5n
IHByaW5jaXBsZSBpbiBhbmQgb2YgaXRzZWxmIHNob3dzIHRoYXQNCj4gdGhlIHNlY3Rpb24g
aGFzIGdyb3duIHRvbyBsb25nIHRvIHJlbWVtYmVyIGl0IGJ5IHRoZSBwb2ludCB5b3UgY29t
ZSB0bw0KPiB0aGlzIGV4YW1wbGUsDQpUaGlzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggbGVu
Z3RoIGFuZCByZW1lbWJlcmluZywgYnV0IHJhdGhlciB3aXRoDQpleHBsYWluaW5nIHdoeSBh
IHBoYXNlIG11c3QgYmUgdXNlZCAtLSB0byBleHBsYWluIHRoYXQsIEkgc3RhdGUgd2hpY2gN
CnByaW5jaXBsZSBhcHBsaWVzIChhcyBtZW50aW9uZWQgcHJldmlvdXNseSkuIElmIEkgcmVt
b3ZlZCB0aGUNCmV4cGxhbmF0aW9ucywgSSB3b3VsZCBqdXN0IGJlIHN0YXRpbmcgaG93IHRv
IGRvIHRoaW5ncywgd2l0aG91dCBnaXZpbmcNCmEgbG9naWNhbCByZWFzb25pbmcgb24gdGhl
ICd3aHknLg0KPiBhbmQgSSB0aGluayB0aGF0J3MgbW9yZSBwcm9ibGVtYXRpYyB0aGFuIG1l
cmVseSB0aGUNCj4gY2FsbGJhY2suICBJZiB5b3UgZGlkbid0IG5lZWQgdG8gZGl2aWRlIHRo
aXMgaW50byBzdWJzdWJzZWN0aW9ucywgeW91DQo+IGNvdWxkIGludHJvZHVjZSB0aGUgZ3Vp
ZGluZyBwcmluY2lwbGVzIGluIGEgd2F5IHRoYXQgZmVlbHMgbW9yZQ0KPiBuYXR1cmFsLg0K
SSBjb25zaWRlciBpdCBtb3JlIG5hdHVyYWwgdG8gaGF2ZSB0aGUgJ2d1aWRpbmcgcHJpbmNp
cGxlcycgX2JlZm9yZV8gdGhlDQpjb25jcmV0ZSBjYXNlcywgYXMgdGhleSBhcmUgbWVhbnQg
dG8gYmUgJ2d1aWRpbmcnIGFuZCAncHJpbmNpcGxlcycuIEl0J3MNCmxpa2UgJ3N0YXJ0aW5n
IGZyb20gZmlyc3QgcHJpbmNpcGxlcycsIHRoZXJlIGludHJvZHVjaW5nIHRoZSBmaXJzdCAN
CnByaW5jaXBsZXMNCmFzIHlvdSBnbyBpcyBhZC1ob2MuDQoNClRoZSBndWlkaW5nIHByaW5j
aXBsZXMgYWxzbyBuZWVkIHRvIGJlIG91dHNpZGUgdGhlIGV4YW1wbGVzLCBpbiBjYXNlDQpv
bmUgb2YgdGhlIGV4YW1wbGVzIGRvZXNuJ3QgYXBwbHkgdG8gdGhlIHBhY2thZ2VyJ3MgdXNl
IGNhc2UsIHN1Y2gNCnRoYXQgdGhleSBjYW4gZmFsbC1iYWNrIHRvIHRoZSBndWlkaW5nIHBy
aW5jaXBsZXMuDQoNCkFsc28sIGluIHlvdXIgcGF0Y2ggeW91IGFyZSBkaXZpZGluZyB0aGlu
Z3MgaW4gc3Vic3Vic2VjdGlvbnMgYXMgd2VsbCwNCmp1c3QgdW5kZXIgYSBkaWZmZXJlbnQg
bmFtZSBhbmQgZGlmZmVyZW50IHJlcHJlc2VudGF0aW9uICh0YWJsZSBlbnRyaWVzDQppbiBh
IHN1YnNlY3Rpb24pLCBhcyBtZW50aW9uZWQgcHJldmlvdXNseS4NCg0KPj4+PiArQHN1YnN1
YnNlY3Rpb24gQWRkaW5nIG5ldyBmdW5jdGlvbmFsaXR5DQo+Pj4+ICtUbyBhZGQgbmV3IGZ1
bmN0aW9uYWxpdHksIGEgcGF0Y2ggaXMgYWxtb3N0IGFsd2F5cyB0aGUgbW9zdA0KPj4+PiBj
b252ZW5pZW50DQo+Pj4+ICtjaG9pY2Ugb2YgdGhlIHRocmVlIC0tIHBhdGNoZXMgYXJlIHVz
dWFsbHkgbXVsdGktbGluZSBjaGFuZ2VzLA0KPj4+PiB3aGljaA0KPj4+PiBhcmUNCj4+Pj4g
K2NvbnZlbmllbnQgdG8gZG8gd2l0aCBwYXRjaGVzIGFuZCBpbmNvbnZlbmllbnQgdG8gZG8g
d2l0aCBwaGFzZXMNCj4+Pj4gb3INCj4+Pj4gK3NuaXBwZXRzLg0KPj4+IFVobSwgd2hhdD/C
oCBQYXRjaGVzIGFyZSB0aGUgcHJlZmVycmVkIGZvcm0gb2YgcGF0Y2hlcz8NCj4+IE5vLCBJ
IG1lYW50IHRoYXQgcGF0Y2hlcyBhcmUgKHVzdWFsbHkpIHRoZSBwcmVmZXJyZWQgbWV0aG9k
IGZvcg0KPj4gYWRkaW5nIG5ldyBmdW5jdGlvbmFsaXR5LCBhbmQgdGhhdCBtdWx0aS1saW5l
IGNoYW5nZXMgYXJlIGNvbnZlbmllbnQNCj4+IHRvIGRvIHdpdGggcGF0Y2hlcy7CoCDigJh3
aGljaOKAmSByZWZlcnMgdG8gdGhlIOKAmG11bHRpLWxpbmUgY2hhbmdlc+KAmSBoZXJlLA0K
Pj4gbm90IOKAmHBhdGNoZXPigJkuDQo+IEkgc3RpbGwgZmluZCB0aGlzIHdvcmRpbmcgdmVy
eSBjb25mdXNpbmcuICBQZXJoYXBzICJUbyBhZGQgbmV3DQo+IGZ1bmN0aW9uYWxpdHksIGEg
cGF0Y2ggaXMgYWxtb3N0IGFsd2F5cyB0aGUgYmVzdCBjaG9pY2UuICBGb3Igb25lLCBpdA0K
PiBpcyBsaWtlbHkgdGhhdCB0aGUgbmV3IGZ1bmN0aW9uYWxpdHkgcmVxdWlyZXMgY2hhbmdp
bmcgbXVsdGlwbGUgbGluZXMNCj4gb2Ygc291cmNlIGNvZGUsIHdoaWNoIGlzIG1vcmUgY29u
dmVuaWVudCB0byBkbyB3aXRoIGEgcGF0Y2ggdGhhbiB3aXRoIGENCj4gc25pcHBldC4gIEZ1
cnRoZXIsIHBhdGNoZXMgY2FuIGJlIHRha2VuIGZyb20gYW5kIHN1Ym1pdHRlZCB0byB1cHN0
cmVhbXMNCj4gbW9yZSBlYXNpbHkuICBJZiB5b3VyIHBhdGNoIGhhcyBub3QgYmVlbiBzdWJt
aXR0ZWQgdG8gdXBzdHJlYW0sDQo+IGNvbnNpZGVyIGRvaW5nIHNvLiINCkl0IGxvc2VzIHNv
bWUgaW5mb3JtYXRpb24gKHRoYXQgcGF0Y2hlcyBhcmUgcHJlZmVycmVkKSBhbmQNCihhZnRl
ciByZS1hZGRpbmcgdGhlIGNvbmNsdXNpb24pIGlzIG1vcmUgdmVyYm9zZSwgd2hpY2ggYXBw
ZWFycw0KdG8gYmUgY29uc2lkZXJlZCB2ZXJ5IGltcG9ydGFudC4NCj4+PiBbLi4uXQ0KPj4+
IE92ZXJhbGwsIEknbSBub3QgY29udmluY2VkIHRoYXQgd2UgaGF2ZSBlbm91Z2ggZ3VpZGlu
ZyBwcmluY2lwbGVzDQo+Pj4gdG8gY2FsbCB0aGVtIHRoYXQsDQo+PiBJIGRvbid0IHRoaW5r
IHRoZXJlJ3MgYW55IGxvd2VyIGxpbWl0IG9uIGhvdyBtYW55IGd1aWRpbmcgcHJpbmNpcGxl
cw0KPj4gdG8gaGF2ZSwgZXhjZXB0IGZvciBwZXJoYXBzIDIgKGJlY2F1c2Ugb3RoZXJ3aXNl
IGl0IHNob3VsZCBoYXZlIGJlZW4NCj4+IHNpbmd1bGFyIG9yIHRoZXJlIGFyZW4ndCBhbnkp
LsKgIEF0IGhvdyBmZXcgZ3VpZGluZyBwcmluY2lwbGVzIHN0b3ANCj4+IHRoZSBndWlkaW5n
IHByaW5jaXBsZXMgZnJvbSBiZWluZyBndWlkaW5nIHByaW5jaXBsZXMgZm9yIHlvdSwgYW5k
DQo+PiB3aHk/DQo+Pg0KPj4gRm9yIGV4YW1wbGUsIG9uPGh0dHBzOi8vd3d3LmdudS5vcmcv
cGhpbG9zb3BoeS9mcmVlLXN3Lmh0bWw+LCBmb3VyDQo+PiBndWlkaW5nIHByaW5jaXBsZXMg
YXJlIG1lbnRpb25lZCAod2hpY2ggYXJlIG5hbWVkICdlc3NlbnRpYWwNCj4+IGZyZWVkb21z
JyB0aGVyZSksIGFuZA0KPj4gPGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0d1aWRp
bmdfUHJpbmNpcGxlcz4gIGhhcyA1IOKAmEd1aWRpbmcNCj4+IFByaW5jaXBsZXPigJkuDQo+
IEFuIGVudW1lcmF0aW9uIG91Z2h0IHRvIGhhdmUgYXQgbGVhc3QgdGhyZWUgZWxlbWVudHMg
KG90aGVyd2lzZSBpdCdzDQo+IGp1c3QgYSBwYWlyKSwgYW5kIEkgdGhpbmsgaWYgd2UgZG8g
cHJvcGVyIGNvdW50aW5nIGFuZCBvbWl0IG5vLQ0KPiBicmFpbmVycywgc3VjaCBhcyB0aGUg
Im9ubHkgZnJlZSBzb2Z0d2FyZSIgcGFydCB0aGF0IGhhcyBhbHJlYWR5IGJlZW4NCj4gbWVu
dGlvbmVkLCB3ZSBjb21lIHZlcnkgY2xvc2UgdG8gc2tpcnRpbmcgdGhhdCBsaW5lLg0KVGhl
ICJvbmx5IGZyZWUgc29mdHdhcmUiIGlzIG1lbnRpb25lZCBlbHNld2hlcmUsIHllcywgYnV0
IGl0IGlzIG9uZQ0Kb2YgdGhlIHByaW5jaXBsZXMgZm9yIGRlY2lkaW5nIGJldHdlZW4gc25p
cHBldHMsIHBoYXNlcyBhbmQgcGF0Y2hlcy4NCldoaWxlIHlvdSBjYWxsIGl0IGEgbm8tYnJh
aW5lciwgaXQgaXMgc29tZXRpbWVzIG5lZ2xlY3RlZCwgc28gaXQgc291bmRzDQppbXBvcnRh
bnQgdG8gbWUgdG8gZXhwbGljaXRseSBsaXN0IGl0Lg0KDQpNZXJnaW5nIHRoZSAzdGggYW5k
IDR0aCBAaXRlbSwgSSBjb3VudCA0IHByaW5jaXBsZXMsIHNvIGl0IGZpdHMgd2l0aA0KYW4g
ZW51bWVyYXRpb24uDQoNCkFsc28sIEknbSBub3QgZm9sbG93aW5nIHlvdXIgcG9pbnQgaGVy
ZSAtLSB5b3VyIGNvbXBsYWludCB3YXMgdGhhdCB0aGV5DQphcmVuJ3QgZ3VpZGluZyBwcmlu
Y2lwbGVzIChiYXNlZCBvbiB0aGUgbnVtYmVyIG9mIHRoZW0pLCBidXQgeW91cg0KcmVzcG9u
c2UgaXMgdGhhdCB0aGV5IG1pZ2h0IG5vdCBmb3JtIGFuIGVudW1lcmF0aW9uP8KgIFRoZXkg
YXJlIG5hbWVkDQp0aGUgZ3VpZGluZyBwcmluY2lwbGVzLCBub3QgdGhlIGd1aWRpbmcgZW51
bWVyYXRpb24uwqAgV2hhdCBoYXZlDQplbnVtZXJhdGlvbnMgdG8gZG8gd2l0aCBhbnl0aGlu
Zz8NCg0KPj4+IHdoaWNoIChhbG9uZyB3aXRoIGl0cyBzaGVlciBsZW5ndGgpIGlzIG15IG1h
aW4NCj4+PiBjb21wbGFpbnQgd2l0aCB0aGUgd2F5IHlvdSd2ZSBwaHJhc2VkIHRoaW5ncy4N
Cj4+IChJJ20gYXNzdW1pbmcgIml0cyA9IHRoZSBwYXRjaCBhcyBhIHdob2xlIiBoZXJlKQ0K
Pj4NCj4+IEkgY291bGQgcmVtb3ZlIGFub3RoZXIgc2VjdGlvbiBvZiB0aGUgbWFudWFsIHRv
IGNvbXBlbnNhdGUgZm9yIHRoZQ0KPj4gYWRkaXRpb25hbCBsZW5ndGgsIGJ1dCBJIGRvdWJ0
IHRoYXQncyB3aGF0IHlvdSBpbnRlbmRlZC7CoCBJIGRvIG5vdA0KPj4gc2VlIHRoZSBwcm9i
bGVtIHdpdGggdGhlIHNoZWVyIGxlbmd0aCAtLSB3ZSBoYXZlIGEgYml0IG9mIGENCj4+IGRv
Y3VtZW50YXRpb24gcHJvYmxlbSBpbiBHdWl4LCB0aGVyZSBpcyBsb3RzIG9mIHVzZWZ1bCBp
bmZvcm1hdGlvbg0KPj4gdGhhdCBpcyBjdXJyZW50bHkgdW5kb2N1bWVudGVkLg0KPj4gSSBk
byBub3QgdGhpbmsgdGhlcmUgaGF2ZSBiZWVuIGFueSBjb21wbGFpbnRzIGFib3V0IHRoZSBt
YW51YWwgYmVpbmcNCj4+IHRvbyBsb25nLCBpZiBhbnl0aGluZywgaXQncyB0b28gc2hvcnQu
DQo+IEkgcGVyc29uYWxseSB0ZW5kIHRvd2FyZHMgImxlc3MgdmVyYm9zZSIsIGhlbmNlIG15
IGNvbXBsYWludCBvZg0KPiBkZXNjcmliaW5nIHNvbWV0aGluZyB3aXRoIG1hbnkgd29yZHMg
dGhhdCBjb3VsZCBiZSBkZXNjcmliZWQgd2l0aA0KPiBmZXdlci4gIEEgc2VjdGlvbiBjYW4g
c3RpbGwgYmUgdG9vIGxvbmcgd2hpbGUgdGhlIGNoYXB0ZXIgYXJvdW5kIGl0IGlzDQo+IHRv
byBzaG9ydC4NCg0KRG8geW91IGhhdmUgYW55dGhpbmcgaW4gcGFydGljdWxhciBpbiBtaW5k
Pw0KDQo+PiBJJ3ZlIHdyaXR0ZW4gc29tZSBkb2N1bWVudGF0aW9uLCBpdCB3YXMgb3JpZ2lu
YWxseSBhIGJpdCBoYXJkIHRvDQo+PiBmb2xsb3cgc28gaW4gYSBuZXh0IHZlcnNpb24gSSd2
ZSByZXN0cnVjdHVyZWQgaXQgYSBiaXQgYW5kIGV4cGxhaW5lZA0KPj4gbW9yZSwgdGhpcyBy
ZXN0cnVjdHVyaW5nIGFuZCBleHBsYW5hdGlvbiBlbnRhaWxlZCBzb21lIGFkZGl0aW9uYWwN
Cj4+IGxlbmd0aC4NCj4+DQo+PiBUaGVyZSBoYWQgYmVlbiBzb21lIHByb3Bvc2FscyBmb3Ig
YWRkaXRpb25hbCBjYXNlcyB0byBkb2N1bWVudCwgc28NCj4+IHRoZXkgd2VyZSBhZGRlZCwg
aW5jcmVhc2luZyB0aGUgbGVuZ3RoLsKgIFlvdSBoYXZlIGFkZGVkIG5ldw0KPj4gaW5mb3Jt
YXRpb24gaXMgeW91ciBwYXRjaCwgaXQgd2FzIGNvbnNpZGVyZWQgdXNlZnVsIHNvIEkndmUN
Cj4+IGludGVncmF0ZWQgc29tZSBvZiBpdCBpbiBteSBwYXRjaCwgaW5jcmVhc2luZyB0aGUg
bGVuZ3RoLsKgIChJIGRpZG4ndA0KPj4gaW50ZWdyYXRlIGFsbCBvZiB0aGUgbmV3IHBhcnRz
LCBpZiBJIGRpZCwgaXQgd291bGQgaW5jcmVhc2UgZXZlbg0KPj4gZnVydGhlci7CoCAoSWYg
ZGVzaXJlZCwgaW4gY2FuIGludGVncmF0ZSB0aGUgcmVzdCwgYXQgY29zdCAgb2Ygc29tZQ0K
Pj4gdGltZS4pKS4NCj4gTXkgcGF0Y2ggZGlkIG5vdCBqdXN0IHN0YXRlIHNvbWUgdGhpbmdz
IHlvdSBtaXNzZWQsIGl0IGFsc28gb21pdHRlZA0KPiB0aGluZ3MgdGhhdCBJIHRoaW5rIGFy
ZSBlaXRoZXIgbm90IG5lY2Vzc2FyeSBvciBwcm9iYWJseSBiZXR0ZXINCj4gZG9jdW1lbnRl
ZCBlbHNld2hlcmUuDQpXaGF0IHBhcnRpY3VsYXIgdGhpbmdzIGRvIHlvdSBoYXZlIGluIG1p
bmQsIGFuZCB3aGVyZSBkbyB5b3UNCnRoaW5rIHRoZXkgc2hvdWxkIGJldHRlciBiZSBkb2N1
bWVudGVkP8KgIEkgY2FuIG1vdmUgdGhpbmdzDQphcm91bmQgYSBiaXQgYW5kIGFkZCBjcm9z
cy1yZWZlcmVuY2VzLg0KPj4gSSBkbyBub3Qgc2VlIHdoYXQgdGhlIHByb2JsZW0gaXMgd2l0
aCBhZGRpdGlvbmFsIGxlbmd0aCBhcyBsb25nIGFzDQo+PiB0aGlzIGFkZGl0aW9uYWwgbGVu
Z3RoIGNvbWVzIHdpdGggYWRkaXRpb25hbCB1c2VmdWwgaW5mb3JtYXRpb24gYW5kDQo+PiB0
aGUgbWFudWFsIGlzIHdlbGwtc3RydWN0dXJlZCAoZS5nLiB3aXRoIChzdWIpKHN1YilzZWN0
aW9ucywgY2hhcHRlcnMNCj4+IGFuZCBpbmRpY2VzKSAtLSB3ZSBkbyBub3QgaGF2ZSBhIHBh
Z2UgbGltaXQuDQo+Pg0KPj4gQXQgd29yc3QsIHBlcmhhcHMgdGhlIHNhbWUgaW5mb3JtYXRp
b24gY291bGQgcGVyaGFwcyBiZSBlbmNvZGVkIHdpdGgNCj4+IGZld2VyIHdvcmRzPyBJIGNv
dWxkIGNvbXBhcmUgdGhlIHR3byBwYXRjaGVzIHRvIHNlZSB3aGljaCBvbmUNCj4+IGZvcm11
bGF0ZXMgY2VydGFpbiBpbmZvcm1hdGlvbiBpbiB0aGUgZmV3ZXN0IHdvcmRzLCBhbmQgY2hv
b3NlIHRoZQ0KPj4gbGVhc3QgdmVyYm9zZSBvZiB0aGUgdHdvIGZvciBlYWNoIHBpZWNlIG9m
IGluZm9ybWF0aW9uIHRoYXQgaXMNCj4+IHByZXNlbnQgaW4gYm90aD8NCj4+DQo+PiBBbHNv
LCBjb21wYXJpbmcgdGhlIHR3byBwYXRjaGVzLCBteSBwYXRjaCBoYXMgNDAgbW9yZSBsaW5l
cywgYnV0DQo+PiBhYm91dCAyNSBvZiB0aGVtIGFyZSBmb3Igbm90aW5nIHRoZSBndWlkaW5n
IHByaW5jaXBsZXMgKHdoaWNoIGFyZQ0KPj4gYWJzZW50IGluIHlvdXIgcGF0Y2gpLg0KPj4g
Q29tcGVuc2F0aW5nIGZvciB0aGF0LCB0aGUgcGF0Y2hlcyBhcmUgYWJvdXQgdGhlIHNhbWUg
bGVuZ3RoLCBzbyBJIGRvDQo+PiBub3QgdGhpbmsgdGhhdCAnc2hlZXIgbGVuZ3RoJyBpcyBh
Y2N1cmF0ZSBoZXJlLg0KPiAyNSBsaW5lcyBjYWxsaW5nIGJhY2sgdG8gZWFybGllciBpbmZv
cm1hdGlvbiBhcmUsIGltaG8sIGFuIGluZGljYXRvcg0KPiB0aGF0IHRoZSBzZWN0aW9uIGlz
IHRvbyBsb25nLiAgSW1hZ2luZSB5b3UnZCBoYXZlIHR3ZW50eS1maXZlIGZ1bmN0aW9uDQo+
IGNhbGxzIHRvIGd1aWRpbmdfcHJpbmNpcGxlcyhuKSBpbiB5b3VyIHByb2dyYW0g4oCTIGF0
IHNvbWUgcG9pbnQsIHlvdSdkDQo+IHRyeSB0byBjYWNoZSB0aG9zZS4NCihkZWZpbmUgY2Fj
aGVkLWd1aWRpbmctcHJpbmNpcGxlcw0KIMKgIChkZWxheSAobGlzdCAoZ3VpZGluZy1wcmlu
Y2lwbGUtMCkNCiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBbLi4u
XQ0KIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIChndWlkaW5nLXBy
aW5jaXBsZS0yNCkpKSkNCg0KQ2FjaGluZyB0aGUgZ3VpZGluZyBwcmluY2lwbGVzIGRvZXMg
bm90IHJlZHVjZSB0aGUgbGVuZ3RoLg0KDQpJIGRvbid0IHNlZSB0aGUgcHJvYmxlbSB3aXRo
IGNhbGxpbmcgYmFjayB0byBlYXJsaWVyIGluZm9ybWF0aW9uLg0KQWxzbywgaXQgaXNuJ3Qg
ZWFybGllciBpbmZvcm1hdGlvbiwgdGhlcmUgaXMgbm8gbmljZSBsaXN0IG9mIGd1aWRpbmcN
CnByaW5jaXBsZXMgYW55d2hlcmUgZWxzZS4NCg0KPj4+IEdvaW5nIGRvd24gdG8gc3Vic3Vi
c2VjdGlvbnMganVzdCB0byBmaW5kIG91dCB3aGVyZSBwYXRjaGVzIGFyZQ0KPj4+IGFwcHJv
cHJpYXRlLCBpcyBpbWhvIG92ZXJraWxsLg0KPj4gVGhlICdnb2luZyBkb3duIHRvIHN1YnN1
YnNlY3Rpb24nIGlzIHRoZSBjYXNlIGZvciB5b3VyIHBhdGNoIHRvbywNCj4+IHRob3VnaD8g
IEluIG15IGNhc2UsIGl0J3MgYSBzdWJzdWJzZWN0aW9uLCBpbiB5b3VyIGNhc2UgaXQncyBh
IHRhYmxlDQo+PiBlbnRyeSBpbnNpZGUgYSBzdWJzZWN0aW9uLCBib3RoIGFyZSB0aGUgc2Ft
ZSBsZXZlbCBvZiBuZXN0aW5nLg0KPiBUaGVzZSBhcmUgc3RpbGwgdHdvIHZlcnkgZGlmZmVy
ZW50IGtpbmRzIG9mIG5lc3RpbmcuICBBIHRhYmxlIGZpdHMgb250bw0KPiBhICh2aXJ0dWFs
KSBwYWdlIG1vcmUgZWFzaWx5IHRoYW4gc2V2ZXJhbCBzdWJzZWN0aW9ucy4NCkkgc3VwcG9z
ZSB0YWJsZSBpdGVtcyBtaWdodCB0YWtlIHR3byBsZXNzIGxpbmUgb3Igc28gbGVzcyB0aGFu
DQpzdWJzdWJzZWN0aW9ucywgYnV0IEkgZG9uJ3QgdGhpbmsgdGhhdCdzIHN1ZmZpY2llbnQg
cmVhc29uIHRvIHN0ZXANCmF3YXkgZnJvbSBhIG5pY2Ugc2VjdGlvbiBzdHJ1Y3R1cmUuDQo+
PiBBbHNvLCBpdCdzIGEgbWF0dGVyIG9mIGRpZmZlcmVudCBzdHJ1Y3R1cmUgLS0gaW4gbXkg
djIgYW5kIHYzIHBhdGNoLA0KPj4gSSBoYXZlIGEgJ3Byb2JsZW0gLT4gc29sdXRpb24nIHN0
cnVjdHVyZSAtLSB0aGUgaWRlYSBpcyB0aGF0IHRoZQ0KPj4gcGFja2FnZXMgaGFzIGEgcHJv
YmxlbSwgdGhleSBsb29rIGF0IHRoZSBzZWN0aW9uLCB0aGV5IHJlYWQgdGhlDQo+PiBzdWJz
dWJzZWN0aW9uIG5hbWVzLCBzZWxlY3QgdGhlDQo+PiBzdWJzdWJzZWN0aW9uIHRoYXQgbWF0
Y2hlcyB0aGVpciBwcm9ibGVtIGFuZCByZWFkIHRoZSBzb2x1dGlvbiAtLSBpbg0KPj4gc2hv
cnQsIHRoZSBpZGVhIGlzIHRvIHByb3ZpZGUgYSBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbS4N
Cj4+DQo+PiBZb3VyIHN0cnVjdHVyZSBpcyB0aGUgb3RoZXIgd2F5IGFyb3VuZCAtLSBmb3Ig
c29sdXRpb25zIChwYXRjaGVzLA0KPj4gc25pcHBldHMsIHBoYXNlcyksIGl0IGdpdmVzIHRo
ZSBwZXJtaXR0ZWQgcHJvYmxlbXMgdG8gYXBwbHkgaXQgdG8uDQo+Pg0KPj4gU28geWVzLCB5
b3VyIHBhdGNoIGlzIG1vcmUgY29udmVuaWVudCBmb3IgZmluZGluZyBvdXQgd2hlcmUgcGF0
Y2hlcw0KPj4gYXJlIGFwcHJvcHJpYXRlLsKgIEkgZG8gbm90IHNlZSB0aGUgYmVuZWZpdCBv
ZiB0aGF0IHRob3VnaCAtLSBhIG5ldw0KPj4gY29udHJpYnV0b3IgcGFja2FnaW5nIGEgdGhp
bmcgd291bGRuJ3Qga25vdyBpbiBhZHZhbmNlIHdoaWNoDQo+PiBzb2x1dGlvbnMgY291bGQg
YmUgYXBwcm9wcmlhdGUgZm9yIHRoZW0gKHlvdXIgJ3NvbHV0aW9uIC0+IHByb2JsZW0nDQo+
PiBwYXRjaD8pLCByYXRoZXIsIHRoZXkgc3RhcnQgd2l0aCBhIHByb2JsZW0gYW5kIGFyZSBz
ZWFyY2hpbmcgZm9yIGFuDQo+PiBhcHByb3ByaWF0ZSBzb2x1dGlvbiAobXkgcHJvYmxlbS0+
c29sdXRpb24gcGF0Y2gpLg0KPiBJIHRoaW5rIHRoaXMgaWRlYSBjYW4gYmUgZGVidW5rZWQg
cHJldHR5IGVhc2lseS4gIElmIEkgZ2l2ZSB5b3UgYQ0KPiBoYW1tZXIgYW5kIEkgdGVsbCB5
b3UgInRoaXMgaXMgYSBoYW1tZXIsIHlvdSBjYW4gdXNlIGl0IHRvIHB1dCBuYWlscw0KPiBp
bnRvIGEgd2FsbCIsIGFuZCB5b3UgaGF2ZSBhIG5haWwgYW5kIHlvdSB3YW50IHRvIHB1dCBp
dCBpbnRvIGEgd2FsbCwNCj4geW91IHdvbid0IGdvICJvaCBubywgaG93ZXZlciB3aWxsIEkg
cHV0IHRoaXMgbmFpbCBpbnRvIGEgd2FsbD8iIOKAkyB5b3UNCj4gd2lsbCBzaW1wbHkgdXNl
IHRoZSBoYW1tZXIgdG8gZG8gc28uDQpUaGUgcGF0Y2ggZG9lcyB0aGlzLCBjdXJyZW50bHku
wqAgSXQgYWxyZWFkeSBwcm9wb3NlcyBhIG51bWJlciBvZiBoYW1tZXJzDQoocGF0Y2hlcywg
c25pcHBldHMgYW5kIHBoYXNlcykgYW5kIHB1cnBvc2VzIChhZGRpbmcgbmV3IGZ1bmN0aW9u
YWxpdHksDQpmaXhpbmcgdGVjaG5pY2FsIGlzc3VlcywgdW5idW5kbGluZywgLi4uKS4NCg0K
QWxzbywgdGhlIHNjZW5hcmlvICJvaCBubywgaG93ZXZlciB3aWxsIEkgcHV0IHRoaXMgbmFp
bCBpbnRvIGEgd2FsbCINCmFjdHVhbGx5IGhhcHBlbmVkIC0tIHNlZSB0aGUgU2hlcGhlcmQg
ZGlzY3Vzc2lvbiwgd2hlcmUgdGhlcmUgd2FzDQphIGxvdCBvZiBkaXNhZ3JlZW1lbnQgb24g
aG93IG5haWxzICg9IHNtYWxsIHdvcmstYXJvdW5kIGluIHRoZSBNYWtlZmlsZSkNCnNob3Vs
ZCBiZSBwdXQgaW4gd2FsbHMgKD0gcGF0Y2hlcywgc25pcHBldCwgcGhhc2U/KS7CoMKgIEl0
IHdhcyB0aGUgd2hvbGUNCnJlYXNvbiB0byBzdGFydCB3cml0aW5nIGEgZG9jdW1lbnRhdGlv
biBwYXRjaC4NCg0KPiBPZiBjb3Vyc2UsIGZvciB0aGlzIHRvIHdvcmsgSQ0KPiBhbHNvIGhh
dmUgdG8gdGVsbCB5b3UgKmhvdyogdG8gdXNlIGEgaGFtbWVyIHRvIHB1dCBuYWlscyBpbnRv
IGEgd2FsbCwNCj4gYnV0IHRoYXQncyBleGFjdGx5IHdoYXQgSSBkaWQgaW4gbXkgcGF0Y2gg
YnkgaW5zZXJ0aW5nIHRoZSByaWdodCBub3Rlcw0KPiBpbnRvIHRoZSBHdWl4IG1hbnVhbC4N
CkFsc28gYWxyZWFkeSB0aGUgY2FzZS4NCj4gTXkgc29sdXRpb24tPnByb2JsZW0gYXBwcm9h
Y2ggaGFzIHRoZSBiZW5lZml0LCB0aGF0IGZvbGtzIGNhbiBqdXN0IGdvDQo+IG92ZXIgYWxs
IHRoZSBzb2x1dGlvbnMsIGNoZWNrIGlmIHRoZWlyIHByb2JsZW0gZml0cywgYW5kIGFwcGx5
IHRoZSBvbmUNCj4gdGhhdCBzYXlzICJoZXJlLCB1c2UgdGhpcyIuDQoNCkEgcHJvYmxlbS0+
c29sdXRpb24gc3RydWN0dXJlIGlzIHVzZWZ1bCBmb3IgdGhhdCB0b28/DQoNCkFuZCBpdCBh
bHJlYWR5IGxpc3RzIGFsbCB0aGUgc29sdXRpb25zIChzbmlwcGV0cywgcGhhc2VzIGFuZCBw
YXRjaGVzKQ0KYW5kIGluZm9ybWF0aW9uIHRvIGRlY2lkZSB3aGV0aGVyIHRoZSBzb2x1dGlv
biBmaXRzIHRoZWlyIHByb2JsZW0NCih0aGUgZ3VpZGluZyBwcmluY2lwbGVzLCBhbmQgdGhl
IHdvcmtlZC1vdXQgY2FzZXMpLg0KDQo+IEFuZCBpZiB0aGV5IGRvbid0IGZpbmQgYW55dGhp
bmcsIHRoZXkgc2VlDQo+IHRoZSBoYW5keSBsaXR0bGUgbGluZSBhdCB0aGUgYm90dG9tIHNh
eWluZyAidXNlIHdoYXRldmVyIHlvdSB0aGluayBpcw0KPiBjb252ZW5pZW50Ii4NCk5vd2hl
cmUgZGlkIHRoZSBwYXRjaCBpbXBseSB0aGF0IHRoZSBsaXN0ZWQgY2FzZXMgd2VyZSBhbGwg
Y2FzZXMuIEluIGZhY3QsDQppbiB0d28gcGxhY2VzIGluIHRoZSBpbnRyb2R1Y3Rpb24gaXQg
aXMgaW1wbGllZCB0aGF0IHRoZSBleGFtcGxlcyBhcmUgbm90DQpleGhhdXN0aXZlLCBhbmQg
dGhhdCB0aGV5IGNhbiBjaG9vc2UgYWNjb3JkaW5nIHRvIGNvbnZlbmllbmNlOg0KDQogICog
4oCYVG8gbWFrZSB0aGluZ3MgbW9yZSBjb25jcmV0ZSBhbmQgdG8gcmVzb2x2ZSBjb25mbGlj
dHMgYmV0d2VlbiB0aGUNCiAgICBwcmluY2lwbGVzLCBhIF9mZXdfIGNhc2VzIGhhdmUgYmVl
biB3b3JrZWQgb3V0OuKAmQ0KDQogICAgKEVtcGhhc2lzIG9uIF9mZXdfIGFkZGVkKQ0KICAq
IOKAmFdoZW4gdGhlcmUgaXMgbW9yZSB0aGFuIG9uZSB3YXkgdG8gZG8gc29tZXRoaW5nLCBj
aG9vc2Ugd2hpY2hldmVyDQogICAgbWV0aG9kDQogICAgaXMgdGhlIHNpbXBsZXN04oCZDQoN
CiAgICAoSXQgc2F5cyDigJhzaW1wbGVzdOKAmSBpbnN0ZWFkIG9mIOKAmG1vc3QgY29udmVu
aWVudOKAmSwgYnV0IHdoYXRldmVyLikNCg0KPiAgICBJIGFsc28gZXhwYW5kIGEgbGl0dGxl
IG9uIHRoZSBiZW5lZml0cyBhbmQgZHJhd2JhY2tzIG9mDQo+IHRoZXNlIGFwcHJvYWNoZXMg
YXMgeW91IHdvdWxkIHdoZW4gZGVzY3JpYmluZyBkZXNpZ24gcGF0dGVybnMuDQoNClRoaXMg
aXMgYWxzbyBkb25lIGluIG15IHBhdGNoLiBFLmcuLA0KDQogICog4oCYVGhlcmUgYXJlIGEg
ZmV3IGJlbmVmaXRzIGZvciBzbmlwcGV0cyBoZXJlOg0KDQogICAgV2hlbiB1c2luZyBzbmlw
cGV0cywgdGhlIGJ1bmRsZWQgbGlicmFyeSBkb2VzIG5vdCBvY2N1ciBpbiB0aGUgc291cmNl
DQoNCiAgICByZXR1cm5lZCBieSBAY29kZXtndWl4IGJ1aWxkIC0tc291cmNlfSwgc28gdXNl
cnMgYW5kIHJldmlld2VycyBkbyBub3QNCg0KICAgIGhhdmUgdG8gd29ycnkgYWJvdXQgd2hl
dGhlciB0aGUgYnVuZGxlZCBsaWJyYXJ5IGNvbnRhaW5zIG1hbHdhcmUsDQoNCiAgICB3aGV0
aGVyIGl0IGlzIG5vbi1mcmVlLCBpZiBpdCBjb250YWlucyBwcmUtY29tcGlsZWQgYmluYXJp
ZXMgLi4uIFRoZXJlDQoNCiAgICBhcmUgYWxzbyBsZXNzIGxpY2Vuc2luZyBjb25jZXJuczog
aWYgdGhlIGJ1bmRsZWQgbGlicmFyaWVzIGFyZSByZW1vdmVkLA0KDQogICAgaXQgYmVjb21l
cyBsZXNzIGxpa2VseSB0aGF0IHRoZSBsaWNlbnNpbmcgY29uZGl0aW9ucyBhcHBseSB0byBw
ZW9wbGUNCg0KICAgIHNoYXJpbmcgdGhlIHNvdXJjZSByZXR1cm5lZCBieSBAY29tbWFuZHtn
dWl4IGJ1aWxkIC0tc291cmNlfSwgZXNwZWNpYWxseSBpZg0KDQogICAgdGhlIGJ1bmRsZWQg
bGlicmFyeSBpcyBub3QgYWN0dWFsbHkgdXNlZCBvbiBHdWl4IHN5c3RlbXMuQGZvb3Rub3Rl
e1RoaXMNCg0KICAgIGlzIEBlbXBoe25vdH0gYSBjbGFpbSB0aGF0IHlvdSBjYW4gc2ltcGx5
IGlnbm9yZSB0aGUgbGljZW5zZXMgb2YNCg0KICAgIGxpYnJhcmllcyB3aGVuIHRoZXkgYXJl
IHVuYnVuZGxlZCBhbmQgcmVwbGFjZWQgYnkgR3VpeCBwYWNrYWdlcyAtLSB0aGVyZQ0KDQog
ICAgYXJlIGxlc3MgY29uY2VybnMsIG5vdCBub25lLn0NCg0KICAgIEFzIHN1Y2gsIHNuaXBw
ZXRzIGFyZSByZWNvbW1lbmRlZCBoZXJlLuKAmQ0KDQogICog4oCYRm9yIHBoYXNlcywgdGhl
IHByb2JsZW0gaXMgdGhhdCBwaGFzZXMgZG8gbm90IGluZmx1ZW5jZSB0aGUgcmVzdWx0IG9m
DQogICAgQGNvbW1hbmR7Z3VpeCBidWlsZCAtLXNvdXJjZX0u4oCZDQoNCj4gWW91ciBwcm9i
bGVtLT5zb2x1dGlvbiBhcHByb2FjaCBpbnN0ZWFkIGxlYXZlcyBwZW9wbGUgd29uZGVyaW5n
IHdoZW4NCj4gdGhlaXIgcGFydGljdWxhciB1c2UgY2FzZSBoYXMgbm90IGJlZW4gZGVzY3Jp
YmVkLg0KU2VlIG15IHJlcGx5IHRvIOKAmEFuZCBpZiB0aGV5IGRvbid0IGZpbmQgYW55dGhp
bmcsIHRoZXkgc2VlIHRoZSBoYW5keSBsaXR0bGUNCmxpbmUgYXQgdGhlIGJvdHRvbSBzYXlp
bmcgInVzZSB3aGF0ZXZlciB5b3UgdGhpbmsgaXMgY29udmVuaWVudOKAmS4NCj4gSXQgZ2l2
ZXMgdGhlbSBhIHNvbHV0aW9uIHJhdGhlciB0aGFuIHRoZSB0b29scyB0byBidWlsZCBzb2x1
dGlvbnMgd2l0aC4NCg0KSXQgZG9lcyBnaXZlIHRoZSB0b29sczogc25pcHBldHMsIHBhdGNo
ZXMgYW5kIHBoYXNlcy7CoCBBbmQgYXMgdG9vbHMNCmZvciBkZWNpZGluZyBiZXR3ZWVuIHRo
ZSB0aHJlZSBmb3Igbm90LXlldC1kb2N1bWVudGVkIGNhc2VzLCB0aGVyZSBhcmUNCnRoZSBn
dWlkaW5nIHByaW5jaXBsZXMuwqAgQXMgYSBkZW1vbnN0cmF0aW9uIG9uIGhvdyB0byB1c2Ug
dGhlc2UgZ3VpZGluZw0KcHJpbmNpcGxlcywgdmFyaW91cyBjYXNlcyBoYXZlIGJlZW4gd29y
a2VkIG91dCBiYXNlZCBvbiB0aGUgZ3VpZGluZw0KcHJpbmNpcGxlcy4NCg0KU3VtbWFyaXNl
ZCwgaXQgZ2l2ZXMgYm90aCB0aGUgdG9vbHMgX2FuZF8gdGhlIHNvbHV0aW9ucy4NCg0KQWxz
bywgImdpdmluZyB0aGUgdG9vbHMgdG8gYnVpbGQgc29sdXRpb25zIHdpdGgiIGRvZXMgbm90
IGhlbHAgd2l0aCB0aGUNCnByb2JsZW0gdGhhdCBJIGFpbWVkIHRvIHNvbHZlIC0tIHRoZXJl
IHdhcyBkaXNhZ3JlZW1lbnQgb24gd2hhdCB0aGUNCmFwcHJvcHJpYXRlIHRvb2xzIGFyZSAo
c2VlOiBTaGVwaGVyZCksIHNvIGl0IG5vdCBqdXN0IG5lZWRzIHRvIGdpdmUgdGhlDQp0b29s
cywgYnV0IGFsc28gdGhlIHNvbHV0aW9ucy4NCg0KR3JlZXRpbmdzLA0KTWF4aW1lDQo=
--------------fiI7W13Wn7SOCrw0E7hFeOyo
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF=
-8">
</head>
<body>
<p>On 07-09-2022 10:09, Liliana Marie Prikler wrote:<br>
</p>
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<pre class=3D"moz-quote-pre" wrap=3D"">Am Dienstag, dem 06.09.2022 =
um 22:21 +0200 schrieb Maxime Devos:
</pre>
<blockquote type=3D"cite">
<pre class=3D"moz-quote-pre" wrap=3D"">
</pre>
<blockquote type=3D"cite">
<pre class=3D"moz-quote-pre" wrap=3D"">We also avoid spelling o=
ut the non-free filename where possible,
preferring keep lists over remove lists, which this kind of patches
would be.
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">Should we? I'm not seeing =
the point of that. I have not experienced
any such avoidance myself, see e.g. 'tennix', 'neverball' and
'shogun'. It is, to my knowledge, not forbidden to mention non-free
software by name in code, as long as its not a recommendation
(explicit or implied).
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">Indeed, there is no hard ru=
le, hence "avoid" rather than "forbid".
</pre>
</blockquote>
<p>What I also meant is, that to my knowledge there is no soft rule
either.</p>
<p>Again, why should we avoid this, what's the point of that?<br>
</p>
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<pre class=3D"moz-quote-pre" wrap=3D"">
</pre>
<blockquote type=3D"cite">
<pre class=3D"moz-quote-pre" wrap=3D"">+@subsubsection Fixing=
technical issues (compilation errors, test
failures, other bugs ...)
[...]
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">I am pretty sure that mo=
st of these are *not* done in snippets, but
rather phases, if they only affect Guix.=C2=A0 In particular, grep for
failing-tests and you will find a few phases disabling them.
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">I do not think that ignori=
ng a test counts as a bug fix.=C2=A0 I'll add it
to this subsubsection, at cost of some additional length.
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">I do think it counts as "fix=
ing technical issues such as test
failures".
</pre>
</blockquote>
How does ignoring a test fix the technical issue identified by the
test<br>
(sometimes, the technical issue being a bug in the test itself)?<br>
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<pre class=3D"moz-quote-pre" wrap=3D"">In fact, as far as files=
that will not be installed are concerned,
I think phases ought to be preferred, because they're easier to
take away if an actual fix is made.
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">I do not see a difference =
in hardness/easyness between removing a
phase and removing a snippet (both are just a matter of opening
an editor, pointing it at gnu/packages/... and removing a few lines),
though I do consider removing a patch to be slightly harder (because
gnu/local.mk is easy to forget).
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">There still is the differenc=
e that phases are clearly delimited while
snippets are a block of code that shouldn't get too large.
</pre>
</blockquote>
<p>Snippets are delimited clearly as well, though, with the
'snippet' field?</p>
<p>And the limitations of snippet length and phases length are the
same<br>
-- no limits, though conciseness is appreciate as always.
</p>
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<pre class=3D"moz-quote-pre" wrap=3D"">For the store path embed=
ding, that's a rather roundabout way of
saying that contributers *ought to* embed store paths of certaing
things, such as commands invoked via exec et al.
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">
It's not? It's kind of implied, yes, but the purpose isn't being a
'you should embed store paths' (subsub)section, but rather, 'if you
go embedding store paths (at least for fixing a technical issue), do
it in a phase'.
I'm not following what the complaint is, I suppose a section could be
added somewhere to properly document the 'embedding store file names'
practice, and insert a cross-reference, but that wasn't the purpose
of the patch and going by later responses, you seem opposed to making
things longer.
The alternative would be to remove this information, but then
valuable information would be lost (there had been some cases where
store file names were embedded in origin).
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">I think my version at least =
hinted at this practice in a more concise
way, so it's not impossible to mention. [...]</pre>
</blockquote>
<p>I agree it's possible -- as I replied previously:</p>
<p>
<blockquote type=3D"cite">
<pre class=3D"moz-quote-pre" wrap=3D"">I suppose a section could =
be added somewhere to properly document the
'embedding store file names' practice, and insert a cross-reference,</pre=
>
</blockquote>
I don't think documenting the how of the practice should be done<br=
>
in this section, properly explaining 'search-input-file' /
'search-input-directory',<br>
'inputs / native-inputs', 'bash' being an implicit input but you
still<br>
have to add it to 'inputs' in some cases because of
cross-compilation,<br>
this-package-input and this-package-native-input ... would make
the<br>
subsubsection a bit too long I think, distracting from other
situations,<br>
hence the proposal for a cross-reference.</p>
<p>How about leaving the 'how to embed store file names' for a
separate<br>
documentation patch and section, adding a cross-reference later?<br=
>
</p>
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<pre class=3D"moz-quote-pre" wrap=3D"">Otherwise, if the stor=
e
+file name were embedded in the source, the result of
@command{guix build
+--source} would be unusable on non-Guix systems and also likely
unusable
+on Guix systems of another architecture.
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">Why are you repeating a =
guiding principle?
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">I'm showing why, in this c=
ase, a phase must be used, by noting that
not doing so would be contrary to one of the principles.
If not repeating the principle is desired, I could perhaps number
them, and refer to the principles by number instead of restating
them? Would reduce the length a little.
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">I think calling back to a gu=
iding principle in and of itself shows that
the section has grown too long to remember it by the point you come to
this example,</pre>
</blockquote>
This has nothing to do with length and remembering, but rather with<b=
r>
explaining why a phase must be used -- to explain that, I state
which<br>
principle applies (as mentioned previously). If I removed the<br>
explanations, I would just be stating how to do things, without
giving<br>
a logical reasoning on the 'why'.<br>
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<pre class=3D"moz-quote-pre" wrap=3D"">and I think that's more prob=
lematic than merely the
callback. If you didn't need to divide this into subsubsections, you
could introduce the guiding principles in a way that feels more
natural.
</pre>
</blockquote>
I consider it more natural to have the 'guiding principles' _before_
the<br>
concrete cases, as they are meant to be 'guiding' and 'principles'.=C2=
=A0
It's<br>
like 'starting from first principles', there introducing the first
principles<br>
as you go is ad-hoc.<br>
<p>The guiding principles also need to be outside the examples, in
case<br>
one of the examples doesn't apply to the packager's use case, such<=
br>
that they can fall-back to the guiding principles.<br>
</p>
<p>Also, in your patch you are dividing things in subsubsections as
well,<br>
just under a different name and different representation (table
entries<br>
in a subsection), as mentioned previously.<br>
</p>
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<pre class=3D"moz-quote-pre" wrap=3D"">+@subsubsection Adding=
new functionality
+To add new functionality, a patch is almost always the most
convenient
+choice of the three -- patches are usually multi-line changes,
which
are
+convenient to do with patches and inconvenient to do with phases
or
+snippets.
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">Uhm, what?=C2=A0 Patches=
are the preferred form of patches?
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">
No, I meant that patches are (usually) the preferred method for
adding new functionality, and that multi-line changes are convenient
to do with patches.=C2=A0 =E2=80=98which=E2=80=99 refers to the =E2=80=98=
multi-line changes=E2=80=99 here,
not =E2=80=98patches=E2=80=99.
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">I still find this wording ve=
ry confusing. Perhaps "To add new
functionality, a patch is almost always the best choice. For one, it
is likely that the new functionality requires changing multiple lines
of source code, which is more convenient to do with a patch than with a
snippet. Further, patches can be taken from and submitted to upstreams
more easily. If your patch has not been submitted to upstream,
consider doing so."
</pre>
</blockquote>
It loses some information (that patches are preferred) and<br>
(after re-adding the conclusion) is more verbose, which appears<br>
to be considered very important.<br>
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<pre class=3D"moz-quote-pre" wrap=3D"">[...]
Overall, I'm not convinced that we have enough guiding principles
to call them that,
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">
I don't think there's any lower limit on how many guiding principles
to have, except for perhaps 2 (because otherwise it should have been
singular or there aren't any).=C2=A0 At how few guiding principles stop
the guiding principles from being guiding principles for you, and
why?
For example, on <a class=3D"moz-txt-link-rfc2396E" href=3D"https://www.gn=
u.org/philosophy/free-sw.html"><https://www.gnu.org/philosophy/free-sw=
=2Ehtml></a>, four=20
guiding principles are mentioned (which are named 'essential
freedoms' there), and
<a class=3D"moz-txt-link-rfc2396E" href=3D"https://en.wikipedia.org/wiki/=
Guiding_Principles"><https://en.wikipedia.org/wiki/Guiding_Principles&=
gt;</a> has 5 =E2=80=98Guiding=20
Principles=E2=80=99.
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">An enumeration ought to have=
at least three elements (otherwise it's
just a pair), and I think if we do proper counting and omit no-
brainers, such as the "only free software" part that has already been
mentioned, we come very close to skirting that line.
</pre>
</blockquote>
The "only free software" is mentioned elsewhere, yes, but it is one<b=
r>
of the principles for deciding between snippets, phases and patches.<=
br>
While you call it a no-brainer, it is sometimes neglected, so it
sounds<br>
important to me to explicitly list it.
<p>Merging the 3th and 4th @item, I count 4 principles, so it fits
with<br>
an enumeration.</p>
<p>Also, I'm not following your point here -- your complaint was
that they<br>
aren't guiding principles (based on the number of them), but your<b=
r>
response is that they might not form an enumeration?=C2=A0 They are=
named<br>
the guiding principles, not the guiding enumeration.=C2=A0 What hav=
e<br>
enumerations to do with anything?<br>
</p>
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<pre class=3D"moz-quote-pre" wrap=3D"">which (along with its sh=
eer length) is my main
complaint with the way you've phrased things.
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">
(I'm assuming "its =3D the patch as a whole" here)
I could remove another section of the manual to compensate for the
additional length, but I doubt that's what you intended.=C2=A0 I do not
see the problem with the sheer length -- we have a bit of a
documentation problem in Guix, there is lots of useful information
that is currently undocumented.
I do not think there have been any complaints about the manual being
too long, if anything, it's too short.
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">I personally tend towards "l=
ess verbose", hence my complaint of
describing something with many words that could be described with
fewer. A section can still be too long while the chapter around it is
too short.</pre>
</blockquote>
<p>Do you have anything in particular in mind?<br>
</p>
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<blockquote type=3D"cite">
<pre class=3D"moz-quote-pre" wrap=3D"">I've written some document=
ation, it was originally a bit hard to
follow so in a next version I've restructured it a bit and explained
more, this restructuring and explanation entailed some additional
length.
There had been some proposals for additional cases to document, so
they were added, increasing the length.=C2=A0 You have added new
information is your patch, it was considered useful so I've
integrated some of it in my patch, increasing the length.=C2=A0 (I didn't=
integrate all of the new parts, if I did, it would increase even
further.=C2=A0 (If desired, in can integrate the rest, at cost of some
time.)).
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">My patch did not just state =
some things you missed, it also omitted
things that I think are either not necessary or probably better
documented elsewhere.
</pre>
</blockquote>
What particular things do you have in mind, and where do you<br>
think they should better be documented?=C2=A0 I can move things<br>
around a bit and add cross-references.
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<blockquote type=3D"cite">
<pre class=3D"moz-quote-pre" wrap=3D"">I do not see what the prob=
lem is with additional length as long as
this additional length comes with additional useful information and
the manual is well-structured (e.g. with (sub)(sub)sections, chapters
and indices) -- we do not have a page limit.
At worst, perhaps the same information could perhaps be encoded with
fewer words? I could compare the two patches to see which one
formulates certain information in the fewest words, and choose the
least verbose of the two for each piece of information that is
present in both?
Also, comparing the two patches, my patch has 40 more lines, but
about 25 of them are for noting the guiding principles (which are
absent in your patch).
Compensating for that, the patches are about the same length, so I do
not think that 'sheer length' is accurate here.
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">25 lines calling back to ear=
lier information are, imho, an indicator
that the section is too long. Imagine you'd have twenty-five function
calls to guiding_principles(n) in your program =E2=80=93 at some point, y=
ou'd
try to cache those.
</pre>
</blockquote>
(define cached-guiding-principles<br>
=C2=A0 (delay (list (guiding-principle-0)<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [...]<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (guiding-principle-24))))
<p>Caching the guiding principles does not reduce the length.</p>
<p>I don't see the problem with calling back to earlier information.<=
br>
Also, it isn't earlier information, there is no nice list of
guiding<br>
principles anywhere else.<br>
</p>
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<pre class=3D"moz-quote-pre" wrap=3D"">Going down to subsubsect=
ions just to find out where patches are
appropriate, is imho overkill.
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">
The 'going down to subsubsection' is the case for your patch too,
though? In my case, it's a subsubsection, in your case it's a table
entry inside a subsection, both are the same level of nesting.
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">These are still two very dif=
ferent kinds of nesting. A table fits onto
a (virtual) page more easily than several subsections.
</pre>
</blockquote>
I suppose table items might take two less line or so less than<br>
subsubsections, but I don't think that's sufficient reason to step<br=
>
away from a nice section structure.<br>
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<blockquote type=3D"cite">
<pre class=3D"moz-quote-pre" wrap=3D"">Also, it's a matter of dif=
ferent structure -- in my v2 and v3 patch,
I have a 'problem -> solution' structure -- the idea is that the
packages has a problem, they look at the section, they read the
subsubsection names, select the
subsubsection that matches their problem and read the solution -- in
short, the idea is to provide a solution to the problem.
Your structure is the other way around -- for solutions (patches,
snippets, phases), it gives the permitted problems to apply it to.
So yes, your patch is more convenient for finding out where patches
are appropriate.=C2=A0 I do not see the benefit of that though -- a new
contributor packaging a thing wouldn't know in advance which
solutions could be appropriate for them (your 'solution -> problem'
patch?), rather, they start with a problem and are searching for an
appropriate solution (my problem->solution patch).
</pre>
</blockquote>
<pre class=3D"moz-quote-pre" wrap=3D"">I think this idea can be deb=
unked pretty easily. If I give you a
hammer and I tell you "this is a hammer, you can use it to put nails
into a wall", and you have a nail and you want to put it into a wall,
you won't go "oh no, however will I put this nail into a wall?" =E2=80=93=
you
will simply use the hammer to do so.</pre>
</blockquote>
The patch does this, currently.=C2=A0 It already proposes a number of=
hammers<br>
(patches, snippets and phases) and purposes (adding new
functionality,<br>
fixing technical issues, unbundling, ...).
<p>Also, the scenario "oh no, however will I put this nail into a
wall"<br>
actually happened -- see the Shepherd discussion, where there was<b=
r>
a lot of disagreement on how nails (=3D small work-around in the
Makefile)<br>
should be put in walls (=3D patches, snippet, phase?).=C2=A0=C2=A0 =
It was the
whole<br>
reason to start writing a documentation patch.<br>
</p>
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<pre class=3D"moz-quote-pre" wrap=3D"">Of course, for this to work =
I
also have to tell you *how* to use a hammer to put nails into a wall,
but that's exactly what I did in my patch by inserting the right notes
into the Guix manual.
</pre>
</blockquote>
Also already the case.
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<pre class=3D"moz-quote-pre" wrap=3D"">My solution->problem appr=
oach has the benefit, that folks can just go
over all the solutions, check if their problem fits, and apply the one
that says "here, use this".</pre>
</blockquote>
<p>A problem->solution structure is useful for that too?</p>
<p>And it already lists all the solutions (snippets, phases and
patches)<br>
and information to decide whether the solution fits their problem<b=
r>
(the guiding principles, and the worked-out cases).<br>
</p>
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<pre class=3D"moz-quote-pre" wrap=3D"">And if they don't find anyth=
ing, they see
the handy little line at the bottom saying "use whatever you think is
convenient".</pre>
</blockquote>
Nowhere did the patch imply that the listed cases were all cases. In
fact,<br>
in two places in the introduction it is implied that the examples
are not<br>
exhaustive, and that they can choose according to convenience:<br>
<ul>
<li>=E2=80=98To make things more concrete and to resolve conflicts =
between
the<br>
principles, a _few_ cases have been worked out:=E2=80=99<br>
<br>
(Emphasis on _few_ added)</li>
<li>=E2=80=98When there is more than one way to do something, choos=
e
whichever method<br>
is the simplest=E2=80=99<br>
<br>
(It says =E2=80=98simplest=E2=80=99 instead of =E2=80=98most conv=
enient=E2=80=99, but whatever.)<br>
</li>
</ul>
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<pre class=3D"moz-quote-pre" wrap=3D""> I also expand a little on =
the benefits and drawbacks of
these approaches as you would when describing design patterns.</pre>
</blockquote>
<p>This is also done in my patch. E.g.,</p>
<ul>
<li>=E2=80=98There are a few benefits for snippets here:<br>
<br>
<div class=3D"line diff addition">
<pre>When using snippets, the bundled library does not occur in=
the source</pre>
</div>
<div class=3D"line diff addition">
<pre>returned by @code{guix build --source}, so users and revie=
wers do not</pre>
</div>
<div class=3D"line diff addition">
<pre>have to worry about whether the bundled library contains m=
alware,</pre>
</div>
<div class=3D"line diff addition">
<pre>whether it is non-free, if it contains pre-compiled binari=
es ... There</pre>
</div>
<div class=3D"line diff addition">
<pre>are also less licensing concerns: if the bundled libraries=
are removed,</pre>
</div>
<div class=3D"line diff addition">
<pre>it becomes less likely that the licensing conditions apply=
to people</pre>
</div>
<div class=3D"line diff addition">
<pre>sharing the source returned by @command{guix build --sourc=
e}, especially if</pre>
</div>
<div class=3D"line diff addition">
<pre>the bundled library is not actually used on Guix systems.@=
footnote{This</pre>
</div>
<div class=3D"line diff addition">
<pre>is @emph{not} a claim that you can simply ignore the licen=
ses of</pre>
</div>
<div class=3D"line diff addition">
<pre>libraries when they are unbundled and replaced by Guix pac=
kages -- there</pre>
</div>
<div class=3D"line diff addition">
<pre>are less concerns, not none.}</pre>
</div>
<div class=3D"line diff addition">
<pre>
</pre>
</div>
<div class=3D"line diff addition">
<pre>As such, snippets are recommended here.=E2=80=99</pre>
</div>
</li>
<li>=E2=80=98For phases, the problem is that phases do not influenc=
e the
result of<br>
@command{guix build --source}.=E2=80=99
</li>
</ul>
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<pre class=3D"moz-quote-pre" wrap=3D"">Your problem->solution ap=
proach instead leaves people wondering when
their particular use case has not been described.</pre>
</blockquote>
See my reply to =E2=80=98And if they don't find anything, they see th=
e handy
little<br>
line at the bottom saying "use whatever you think is convenient=E2=80=
=99.
<blockquote type=3D"cite"
cite=3D"mid:44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN=
az.at">
<pre class=3D"moz-quote-pre" wrap=3D"">It gives them a solution rat=
her than the tools to build solutions with.</pre>
</blockquote>
<p>It does give the tools: snippets, patches and phases.=C2=A0 And as=
tools<br>
for deciding between the three for not-yet-documented cases, there
are<br>
the guiding principles.=C2=A0 As a demonstration on how to use thes=
e
guiding<br>
principles, various cases have been worked out based on the
guiding<br>
principles.</p>
<p>Summarised, it gives both the tools _and_ the solutions.<br>
</p>
<p>Also, "giving the tools to build solutions with" does not help
with the<br>
problem that I aimed to solve -- there was disagreement on what
the<br>
appropriate tools are (see: Shepherd), so it not just needs to
give the<br>
tools, but also the solutions.<br>
</p>
Greetings,<br>
Maxime<br>
</body>
</html>
--------------fiI7W13Wn7SOCrw0E7hFeOyo--
--------------lT8JlkWSD5VQXD90Dz1boRGV
Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc"
Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable
-----BEGIN PGP PUBLIC KEY BLOCK-----
xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m
xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2
ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL
CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc
/gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4
LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C
kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK
CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W
ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ
Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0
k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo
AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE
fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D
=3DOVqp
-----END PGP PUBLIC KEY BLOCK-----
--------------lT8JlkWSD5VQXD90Dz1boRGV--
--------------N4yS7ui6DXqk1oJogkEaW0eQ--
--------------bYZznqRF4e00yv03Q3Otn4Cv
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"
-----BEGIN PGP SIGNATURE-----
wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYxnOKwUDAAAAAAAKCRBJ4+4iGRcl7oE4
AQDtdxmMVTnJacU9WxjP4u0o+5DrGsvJxnT41XavjvSmfgD/UucFg4ulPdrlNij3rvlwEFU2y+1/
/n00uv4kVb+vswI=
=7etQ
-----END PGP SIGNATURE-----
--------------bYZznqRF4e00yv03Q3Otn4Cv--
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.
Received: (at 57598) by debbugs.gnu.org; 7 Sep 2022 08:10:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 07 04:10:14 2022
Received: from localhost ([127.0.0.1]:53313 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oVq8T-0001Q4-48
for submit <at> debbugs.gnu.org; Wed, 07 Sep 2022 04:10:14 -0400
Received: from mailrelay.tugraz.at ([129.27.2.202]:30599)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <liliana.prikler@HIDDEN>) id 1oVq8N-0001Po-Kw
for 57598 <at> debbugs.gnu.org; Wed, 07 Sep 2022 04:10:12 -0400
Received: from lprikler-laptop.ist.intra (gw.ist.tugraz.at [129.27.202.101])
by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4MMw0Q5pwSz3wVf;
Wed, 7 Sep 2022 10:09:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at;
s=mailrelay; t=1662538198;
bh=lu8bYcjyUDFPErl1qLcQyrpo/NtDhSTJfp6UDgESjIo=;
h=Subject:From:To:Date:In-Reply-To:References;
b=ZtnApfojCspEyGEBp5JYBzpKqvZ7CByrGzCEM9f3/Yg/dRujoaHbhnc/A8jVB6hkF
rMTJ8axgO2oQpHb1fzCxak8hLYRQ2aJgK70jLvvlSB8LXOY4bwyWT1f6N17NkWgLJE
E4d2pL1NWgm94n+3pzF0UJHLqpv51S+s0owZgbaY=
Message-ID: <44573c52ae3781b85f76d113735f3f85b82548bf.camel@HIDDEN>
Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc.
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
To: Maxime Devos <maximedevos@HIDDEN>, 57598 <at> debbugs.gnu.org
Date: Wed, 07 Sep 2022 10:09:58 +0200
In-Reply-To: <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
References: <20220905160048.18173-1-maximedevos@HIDDEN>
<0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
<d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ
X-Spam-Scanner: SpamAssassin 3.003001
X-Spam-Score-relay: -0.4
X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 57598
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Am Dienstag, dem 06.09.2022 um 22:21 +0200 schrieb Maxime Devos:
>
> > We also avoid spelling out the non-free filename where possible,
> > preferring keep lists over remove lists, which this kind of patches
> > would be.
> Should we? I'm not seeing the point of that. I have not experienced
> any such avoidance myself, see e.g. 'tennix', 'neverball' and
> 'shogun'. It is, to my knowledge, not forbidden to mention non-free
> software by name in code, as long as its not a recommendation
> (explicit or implied).
Indeed, there is no hard rule, hence "avoid" rather than "forbid".
> >
> > > +@subsubsection Fixing technical issues (compilation errors, test
> > > failures, other bugs ...)
> > > [...]
> > I am pretty sure that most of these are *not* done in snippets, but
> > rather phases, if they only affect Guix. In particular, grep for
> > failing-tests and you will find a few phases disabling them.
> I do not think that ignoring a test counts as a bug fix. I'll add it
> to this subsubsection, at cost of some additional length.
I do think it counts as "fixing technical issues such as test
failures".
> > In fact, as far as files that will not be installed are concerned,
> > I think phases ought to be preferred, because they're easier to
> > take away if an actual fix is made.
> I do not see a difference in hardness/easyness between removing a
> phase and removing a snippet (both are just a matter of opening
> an editor, pointing it at gnu/packages/... and removing a few lines),
> though I do consider removing a patch to be slightly harder (because
> gnu/local.mk is easy to forget).
There still is the difference that phases are clearly delimited while
snippets are a block of code that shouldn't get too large.
> > For the store path embedding, that's a rather roundabout way of
> > saying that contributers *ought to* embed store paths of certaing
> > things, such as commands invoked via exec et al.
>
> It's not? It's kind of implied, yes, but the purpose isn't being a
> 'you should embed store paths' (subsub)section, but rather, 'if you
> go embedding store paths (at least for fixing a technical issue), do
> it in a phase'.
>
> I'm not following what the complaint is, I suppose a section could be
> added somewhere to properly document the 'embedding store file names'
> practice, and insert a cross-reference, but that wasn't the purpose
> of the patch and going by later responses, you seem opposed to making
> things longer.
>
> The alternative would be to remove this information, but then
> valuable information would be lost (there had been some cases where
> store file names were embedded in origin).
I think my version at least hinted at this practice in a more concise
way, so it's not impossible to mention. Not embedding store paths *is*
a technical issue, because it'll cause the installed program to fail
and most people new to Guix will then just go "oh, let's propagate gcc-
toolchain".
> > > Otherwise, if the store
> > > +file name were embedded in the source, the result of
> > > @command{guix build
> > > +--source} would be unusable on non-Guix systems and also likely
> > > unusable
> > > +on Guix systems of another architecture.
> > Why are you repeating a guiding principle?
> I'm showing why, in this case, a phase must be used, by noting that
> not doing so would be contrary to one of the principles.
>
> If not repeating the principle is desired, I could perhaps number
> them, and refer to the principles by number instead of restating
> them? Would reduce the length a little.
I think calling back to a guiding principle in and of itself shows that
the section has grown too long to remember it by the point you come to
this example, and I think that's more problematic than merely the
callback. If you didn't need to divide this into subsubsections, you
could introduce the guiding principles in a way that feels more
natural.
> > > +@subsubsection Adding new functionality
> > > +To add new functionality, a patch is almost always the most
> > > convenient
> > > +choice of the three -- patches are usually multi-line changes,
> > > which
> > > are
> > > +convenient to do with patches and inconvenient to do with phases
> > > or
> > > +snippets.
> > Uhm, what? Patches are the preferred form of patches?
>
> No, I meant that patches are (usually) the preferred method for
> adding new functionality, and that multi-line changes are convenient
> to do with patches. ‘which’ refers to the ‘multi-line changes’ here,
> not ‘patches’.
I still find this wording very confusing. Perhaps "To add new
functionality, a patch is almost always the best choice. For one, it
is likely that the new functionality requires changing multiple lines
of source code, which is more convenient to do with a patch than with a
snippet. Further, patches can be taken from and submitted to upstreams
more easily. If your patch has not been submitted to upstream,
consider doing so."
> >
> > [...]
> > Overall, I'm not convinced that we have enough guiding principles
> > to call them that,
>
> I don't think there's any lower limit on how many guiding principles
> to have, except for perhaps 2 (because otherwise it should have been
> singular or there aren't any). At how few guiding principles stop
> the guiding principles from being guiding principles for you, and
> why?
>
> For example, on <https://www.gnu.org/philosophy/free-sw.html>, four
> guiding principles are mentioned (which are named 'essential
> freedoms' there), and
> <https://en.wikipedia.org/wiki/Guiding_Principles> has 5 ‘Guiding
> Principles’.
An enumeration ought to have at least three elements (otherwise it's
just a pair), and I think if we do proper counting and omit no-
brainers, such as the "only free software" part that has already been
mentioned, we come very close to skirting that line.
> > which (along with its sheer length) is my main
> > complaint with the way you've phrased things.
>
> (I'm assuming "its = the patch as a whole" here)
>
> I could remove another section of the manual to compensate for the
> additional length, but I doubt that's what you intended. I do not
> see the problem with the sheer length -- we have a bit of a
> documentation problem in Guix, there is lots of useful information
> that is currently undocumented.
> I do not think there have been any complaints about the manual being
> too long, if anything, it's too short.
I personally tend towards "less verbose", hence my complaint of
describing something with many words that could be described with
fewer. A section can still be too long while the chapter around it is
too short.
> I've written some documentation, it was originally a bit hard to
> follow so in a next version I've restructured it a bit and explained
> more, this restructuring and explanation entailed some additional
> length.
>
> There had been some proposals for additional cases to document, so
> they were added, increasing the length. You have added new
> information is your patch, it was considered useful so I've
> integrated some of it in my patch, increasing the length. (I didn't
> integrate all of the new parts, if I did, it would increase even
> further. (If desired, in can integrate the rest, at cost of some
> time.)).
My patch did not just state some things you missed, it also omitted
things that I think are either not necessary or probably better
documented elsewhere.
> I do not see what the problem is with additional length as long as
> this additional length comes with additional useful information and
> the manual is well-structured (e.g. with (sub)(sub)sections, chapters
> and indices) -- we do not have a page limit.
>
> At worst, perhaps the same information could perhaps be encoded with
> fewer words? I could compare the two patches to see which one
> formulates certain information in the fewest words, and choose the
> least verbose of the two for each piece of information that is
> present in both?
>
> Also, comparing the two patches, my patch has 40 more lines, but
> about 25 of them are for noting the guiding principles (which are
> absent in your patch).
> Compensating for that, the patches are about the same length, so I do
> not think that 'sheer length' is accurate here.
25 lines calling back to earlier information are, imho, an indicator
that the section is too long. Imagine you'd have twenty-five function
calls to guiding_principles(n) in your program – at some point, you'd
try to cache those.
> > Going down to subsubsections just to find out where patches are
> > appropriate, is imho overkill.
>
> The 'going down to subsubsection' is the case for your patch too,
> though? In my case, it's a subsubsection, in your case it's a table
> entry inside a subsection, both are the same level of nesting.
These are still two very different kinds of nesting. A table fits onto
a (virtual) page more easily than several subsections.
> Also, it's a matter of different structure -- in my v2 and v3 patch,
> I have a 'problem -> solution' structure -- the idea is that the
> packages has a problem, they look at the section, they read the
> subsubsection names, select the
> subsubsection that matches their problem and read the solution -- in
> short, the idea is to provide a solution to the problem.
>
> Your structure is the other way around -- for solutions (patches,
> snippets, phases), it gives the permitted problems to apply it to.
>
> So yes, your patch is more convenient for finding out where patches
> are appropriate. I do not see the benefit of that though -- a new
> contributor packaging a thing wouldn't know in advance which
> solutions could be appropriate for them (your 'solution -> problem'
> patch?), rather, they start with a problem and are searching for an
> appropriate solution (my problem->solution patch).
I think this idea can be debunked pretty easily. If I give you a
hammer and I tell you "this is a hammer, you can use it to put nails
into a wall", and you have a nail and you want to put it into a wall,
you won't go "oh no, however will I put this nail into a wall?" – you
will simply use the hammer to do so. Of course, for this to work I
also have to tell you *how* to use a hammer to put nails into a wall,
but that's exactly what I did in my patch by inserting the right notes
into the Guix manual.
My solution->problem approach has the benefit, that folks can just go
over all the solutions, check if their problem fits, and apply the one
that says "here, use this". And if they don't find anything, they see
the handy little line at the bottom saying "use whatever you think is
convenient". I also expand a little on the benefits and drawbacks of
these approaches as you would when describing design patterns.
Your problem->solution approach instead leaves people wondering when
their particular use case has not been described. It gives them a
solution rather than the tools to build solutions with.
Cheers
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.Received: (at 57598) by debbugs.gnu.org; 6 Sep 2022 20:21:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 16:21:18 2022 Received: from localhost ([127.0.0.1]:52801 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oVf4P-0000XW-2v for submit <at> debbugs.gnu.org; Tue, 06 Sep 2022 16:21:18 -0400 Received: from michel.telenet-ops.be ([195.130.137.88]:39050) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <maximedevos@HIDDEN>) id 1oVf4M-0000XM-9f for 57598 <at> debbugs.gnu.org; Tue, 06 Sep 2022 16:21:16 -0400 Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16] ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]) by michel.telenet-ops.be with bizsmtp id GkMB2800H20ykKC06kMBVn; Tue, 06 Sep 2022 22:21:12 +0200 Message-ID: <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN> Date: Tue, 6 Sep 2022 22:21:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Content-Language: en-US To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 57598 <at> debbugs.gnu.org References: <20220905160048.18173-1-maximedevos@HIDDEN> <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN> From: Maxime Devos <maximedevos@HIDDEN> Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc. In-Reply-To: <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------NLNRqI000ekw60aGGVxBGoXf" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1662495672; bh=tr8EL3KA3vekhc/xYcxJ8meZq/gKoXYrOpKkpe/CptY=; h=Date:To:References:From:Subject:In-Reply-To; b=KMD1/DEbTAQ7r2FxcZHUlcqMOdVcFTMvPtyxJ6EQtXWSe+ASvR+U/kfPInNHximKt yqtkyMOyqE33UB/xtv75mwgKkhAMZKLodnFPPvAcmdoOk6Wv+B8VR0ZC/mMxTXyLwV qNg+f475gniCm3tLwLE0y9/06CyEaBh7oslbUvx6p8d6yssbYjdTNbdqv4fd4vxdJJ QJOqXPCBXkHIh0pZXr2YszmZOdDzbezwmYygQErU81L7BEWinGBF9NMz6wmPB1viy2 X95ux8xGNHzXpSwO53JesOi1p3iKudzmpne1tsb50jk3OQGknj87eV9V4TRjRE6Yv2 VQ1KOTCznpDhg== X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57598 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------NLNRqI000ekw60aGGVxBGoXf Content-Type: multipart/mixed; boundary="------------mg1vH0aCGVVMzb0Ns8xAZUcB"; protected-headers="v1" From: Maxime Devos <maximedevos@HIDDEN> To: Liliana Marie Prikler <liliana.prikler@HIDDEN>, 57598 <at> debbugs.gnu.org Message-ID: <d0a48b72-c62b-cc97-e399-22abc0af182d@HIDDEN> Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc. References: <20220905160048.18173-1-maximedevos@HIDDEN> <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN> In-Reply-To: <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN> --------------mg1vH0aCGVVMzb0Ns8xAZUcB Content-Type: multipart/mixed; boundary="------------8K9TKb9cQWdHijgVuosbMcLl" --------------8K9TKb9cQWdHijgVuosbMcLl Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDYtMDktMjAyMiAxMzozMywgTGlsaWFuYSBNYXJpZSBQcmlrbGVyIHdyb3RlOg0KDQo+ IEFtIE1vbnRhZywgZGVtIDA1LjA5LjIwMjIgdW0gMTg6MDAgKzAyMDAgc2NocmllYiBNYXhp bWUgRGV2b3M6DQo+PiArR3VpeCBoYXMgdHJlZSBtYWluIHdheXMgb2YgbW9kaWZ5aW5nIHRo ZSBzb3VyY2UgY29kZSBvZiBhIHBhY2thZ2UsDQo+PiB0aGF0DQo+PiAreW91IGFzIGEgcGFj a2FnZXIgbWF5IHVzZS7CoCBUaGVzZSBhcmUgcGF0Y2hlcywgc25pcHBldHMgYW5kIHBoYXNl cy4NCj4+ICtFYWNoIG9uZSBoYXMgaXRzIHN0cmVuZ3RocyBhbmQgZHJhd2JhY2tzLsKgIFRv IGRlY2lkZSBiZXR3ZWVuIHRoZSB0cmVlLA0KPiB0aHJlZQ0KUmlnaHQuDQo+PiArdGhlcmUg YXJlIGEgZmV3IGd1aWRpbmcgcHJpbmNpcGxlcyB0aGF0IHRvIHNhdGlzZnkgc2ltdWx0YW51 b3VzbHkNCj4+IHdoZXJlDQo+PiArcG9zc2libGU6DQo+ICJ0aGVyZSBhcmUgYSBmZXcgZ3Vp ZGluZyBwcmluY2lwbGVzIHRvIHNhdGlzZnkgc2ltdWx0YW5lb3VzbHkiLA0KPiAidGhlcmUg YXJlIHNvbWUgZ3VpZGluZyBwcmluY2lwbGVzLCBvZiB3aGljaCBhcyBtYW55IGFzIHBvc3Np YmxlIHNob3VsZA0KPiBiZSBzYXRpc2ZpZWQiLg0KPj4gKw0KPj4gK0BpdGVtaXplDQo+PiAr QGl0ZW0NCj4+ICtJbiBwcmluY2lwbGUsIEd1aXggb25seSBoYXMgZnJlZSBzb2Z0d2FyZTsg d2hlbiB0aGUgdXBzdHJlYW0gc291cmNlDQo+PiArY29udGFpbnMgc29tZSBub24tZnJlZSBz b2Z0d2FyZSwgaXQgaGFzIHRvIGJlIHJlbW92ZWQgc3VjaCB0aGF0DQo+PiArQGNvbW1hbmR7 Z3VpeCBidWlsZCAtLXNvdXJjZX0gcmV0dXJucyB0aGUg4oCYZnJlZWTigJkgc291cmNlIGNv ZGUgcmF0aGVyDQo+PiB0aGFuDQo+PiArdGhlIHVubW9kaWZpZWQgdXBzdHJlYW0gc291cmNl IChAcHhyZWZ7U29mdHdhcmUgRnJlZWRvbX0pLg0KPiBJZiB0aGUgbGF0dGVyIHdvcmRpbmcg YWJvdmUgaXMgY2hvc2VuLCB0aGlzIGlzIG5vdCBhICJndWlkaW5nDQo+IHByaW5jaXBsZSIs IGJlY2F1c2UgaXQgaXMgbm9uLW5lZ290aWFibGUuDQpJJ2xsIGdvIGZvciBmaXJzdCBvcHRp b24sICJ0aGVyZSBhcmUgYSBmZXcgZ3VpZGluZyBwcmluY2lwbGVzIHRvIHNhdGlzZnkNCnNp bXVsdGFuZW91c2x5IHdoZXJlIHBvc3NpYmxlIiwgZHJvcHBpbmcgdGhlIG1pc3BsYWNlZCAi dG8iLg0KPj4gK0BpdGVtDQo+PiArVGhlIHNvdXJjZSBvZiB0aGUgcGFja2FnZSBuZWVkcyB0 byBjb3JyZXNwb25kIHRvIHdoYXQgaXMgYWN0dWFsbHkNCj4+IGJ1aWx0DQo+PiArKGkuZS4s IGFjdCBhcyB0aGUgY29ycmVzcG9uZGluZyBzb3VyY2UpLCB0byBmdWxmaWxsIG91ciBldGhp Y2FsIGFuZA0KPj4gK2xlZ2FsIG9ibGlnYXRpb25zLg0KPj4gK0BpdGVtDQo+PiArSXQgaXMg Y29udmVuaWVudCBmb3IgdGhlIHNvdXJjZSBkZXJpdmVkIGZyb20gYW4gb3JpZ2luIHRvIGJ1 aWxkIG9uIGFueQ0KPj4gK3N5c3RlbSB0aGF0IHRoZSB1cHN0cmVhbSBwYWNrYWdlIHN1cHBv cnRzLg0KPj4gK0BpdGVtDQo+PiArVGhlIHNvdXJjZSBuZWVkcyB0byBhY3R1YWxseSB3b3Jr LCBub3Qgb25seSBvbiB5b3VyIEd1aXggc3lzdGVtIGJ1dA0KPj4gYWxzbw0KPj4gK2ZvciBv dGhlciBzeXN0ZW1zOyB0aGlzIHJlcXVpcmVzIHNvbWUgY2FyZSBmb3Igc3Vic3RpdHV0aW9u cyBpbnZvbHZpbmcNCj4+ICtzdG9yZSBpdGVtcyBhbmQgb3RoZXIgYXJjaGl0ZWN0dXJlLXNw ZWNpZmljIGNoYW5nZXMuDQo+IElmIHlvdSBlbWJlZCBzdG9yZSBpdGVtcywgaXQgd29uJ3Qg ZXZlbiB3b3JrIG9uIEd1aXggU3lzdGVtIPCfmJvvuI8NCg0KSXQgZG9lcywgdGhvdWdoPyBD b25kaXRpb25hbCBvbiBubyAtLXN5c3RlbSBhbmQgbm8gLS10YXJnZXQuIFRob3VnaCBnaXZl bg0KdGhlIHRoaXJkIEBpdGVtLCBkb2Vzbid0IG1hdHRlci4NCg0KPiBBbHNvLCB0aGlzIGFw cGVhcnMgdG8gYmUgYSByYXRoZXIgY29udmVuaWVudCByZXdvcmRpbmcgb2YgdGhlIHByZXZp b3VzDQo+IGl0ZW0sIGRvZXMgaXQgbm90Pw0KSSB0aGluayB0aGF0IHdpdGggdGhlIGZpcnN0 LCBJIHJlZmVycmVkIHRvIHN5c3RlbXMgaW4gdGhlIHNlbnNlIG9mDQotLXN5c3RlbSAvIC0t dGFyZ2V0LCBhbmQgdGhhdCB3aXRoIHRoZSBzZWNvbmQgSSBtZWFudCBkaXN0cmlidXRpb25z LA0KdGhvdWdoIHllcy4gSSdsbCBsb29rIGludG8gdW5pZnlpbmcgdGhlIHR3by4NCj4+ICtA aXRlbQ0KPj4gK1doZW4gdGhlcmUgaXMgbW9yZSB0aGFuIG9uZSB3YXkgdG8gZG8gc29tZXRo aW5nLCBjaG9vc2Ugd2hpY2hldmVyDQo+PiBtZXRob2QNCj4+ICtpcyB0aGUgc2ltcGxlc3Qu wqAgU29tZXRpbWVzIHRoaXMgaXMgc3ViamVjdGl2ZSwgd2hpY2ggaXMgYWxzbyBmaW5lLg0K Pj4gK1doYXQgbWF0dGVycyBpcyB0aGF0IHlvdSB1c2UgdGVjaG5pcXVlcyB0aGF0IGFyZSBj b21tb24gd2l0aGluIHRoZQ0KPj4gK2NvbW11bml0eSAoaS5lLiwgcGF0dGVybnMgdGhhdCBh cHBlYXIgdGhyb3VnaG91dA0KPj4gQGNvZGV7Z251L3BhY2thZ2VzLy4uLn0pDQo+PiArYW5k IGFyZSB0aHVzIGNsZWFybHkgbGVnaWJsZSBmb3IgcmV2aWV3ZXJzLg0KPj4gK0BlbmQgaXRl bWl6ZQ0KPj4gKw0KPj4gK1RvIG1ha2UgdGhpbmdzIG1vcmUgY29uY3JldGUgYW5kIHRvIHJl c29sdmUgY29uZmxpY3RzIGJldHdlZW4gdGhlDQo+PiArcHJpbmNpcGxlcywgYSBmZXcgY2Fz ZXMgaGF2ZSBiZWVuIHdvcmtlZCBvdXQ6DQo+PiArDQo+PiArQHN1YnN1YnNlY3Rpb24gUmVt b3Zpbmcgbm9uLWZyZWUgc29mdHdhcmUNCj4+ICtOb24tZnJlZSBzb2Z0d2FyZSBoYXMgdG8g YmUgcmVtb3ZlZCBpbiBzbmlwcGV0czsgdGhlIHJlYXNvbiBpcyB0aGF0DQo+PiArcGF0Y2hl cyBvciBwaGFzZXMgd2lsbCBub3Qgd29yay4NCj4+ICsNCj4+ICtGb3IgcGF0Y2hlcywgdGhl IHByb2JsZW0gaXMgdGhhdCBhIHBhdGNoIHJlbW92aW5nIGEgbm9uLWZyZWUgZmlsZQ0KPj4g K2F1dG9tYXRpY2FsbHkgY29udGFpbnMgdGhlIG5vbi1mcmVlIGZpbGVAZm9vdG5vdGV7SXQg aGFzIGJlZW4gbm90ZWQNCj4+IHRoYXQNCj4+ICtnaXQgcGF0Y2hlcyBzdXBwb3J0IHJlbW92 aW5nIGZpbGVzIHdpdGhvdXQgaW5jbHVkaW5nIHRoZSBmaWxlIGluIHRoZQ0KPj4gK3BhdGNo IGluDQo+PiArQHVybHsNCj4+IGh0dHBzOi8veWhldGlsLm9yZy9ndWl4LzhiMTNlODk5LWVi NjAtNDkwYi1hMjY4LTYzOTI0OTY5OGM4MUBAd3d3LmZhc3RtYWlsLmNvbS8NCj4+IH0uIElm DQo+PiAraXQgaXMgdmVyaWZpZWQgdGhhdCB0aGUgQGNvbW1hbmR7cGF0Y2h9IHV0aWxpdHkg c3VwcG9ydHMgc3VjaCBwYXRjaGVzLA0KPj4gK3RoaXMgbWV0aG9kIGNhbiBiZSB1c2VkIGFu ZCB0aGlzIHBvbGljeSBhZGp1c3RlZCBhcHByb3ByaWF0ZWx5Ln0sIGFuZA0KPj4gd2UNCj4+ ICtkbyBub3Qgd2FudCBhbnl0aGluZyBub24tZnJlZSBpbiBHdWl4IGV2ZW4gaWYgb25seSBp biBpdHMgcGF0Y2hlcy4NCj4gV2UgYWxzbyBhdm9pZCBzcGVsbGluZyBvdXQgdGhlIG5vbi1m cmVlIGZpbGVuYW1lIHdoZXJlIHBvc3NpYmxlLA0KPiBwcmVmZXJyaW5nIGtlZXAgbGlzdHMg b3ZlciByZW1vdmUgbGlzdHMsIHdoaWNoIHRoaXMga2luZCBvZiBwYXRjaGVzDQo+IHdvdWxk IGJlLg0KU2hvdWxkIHdlPyBJJ20gbm90IHNlZWluZyB0aGUgcG9pbnQgb2YgdGhhdC4gSSBo YXZlIG5vdCBleHBlcmllbmNlZCBhbnkNCnN1Y2ggYXZvaWRhbmNlIG15c2VsZiwgc2VlIGUu Zy4gJ3Rlbm5peCcsICduZXZlcmJhbGwnIGFuZCAnc2hvZ3VuJy4gSXQgaXMsDQp0byBteSBr bm93bGVkZ2UsIG5vdCBmb3JiaWRkZW4gdG8gbWVudGlvbiBub24tZnJlZSBzb2Z0d2FyZSBi eSBuYW1lDQppbiBjb2RlLCBhcyBsb25nIGFzIGl0cyBub3QgYSByZWNvbW1lbmRhdGlvbiAo ZXhwbGljaXQgb3IgaW1wbGllZCkuDQo+PiArRm9yIHBoYXNlcywgdGhlIHByb2JsZW0gaXMg dGhhdCBwaGFzZXMgZG8gbm90IGluZmx1ZW5jZSB0aGUgcmVzdWx0IG9mDQo+PiArQGNvbW1h bmR7Z3VpeCBidWlsZCAtLXNvdXJjZX0uDQo+PiArDQo+PiArQHN1YnN1YnNlY3Rpb24gUmVt b3ZpbmcgYnVuZGxlZCBsaWJyYXJpZXMNCj4+ICtCdW5kbGVkIGxpYnJhcmllcyBzaG91bGQg bm90IGJlIHJlbW92ZWQgd2l0aCBwYXRjaGVzLCBiZWNhdXNlIHRoZW4gdGhlDQo+PiArcGF0 Y2ggd291bGQgY29udGFpbiB0aGUgZnVsbCBidW5kbGVkIGxpYnJhcnksIHdoaWNoIGNhbiBi ZSBsYXJnZS4gVGhleQ0KPj4gK2NhbiBiZSByZW1vdmVkIGVpdGhlciBpbiBzbmlwcGV0cyBv ciBwaGFzZXMsIG9mdGVuIHVzaW5nIHRoZSBwcm9jZWR1cmUNCj4+ICtAY29kZXtkZWxldGUt ZmlsZS1yZWN1cnNpdmVseX0uIFRoZXJlIGFyZSBhIGZldyBiZW5lZml0cyBmb3Igc25pcHBl dHMNCj4+IGhlcmU6DQo+PiArDQo+PiArV2hlbiB1c2luZyBzbmlwcGV0cywgdGhlIGJ1bmRs ZWQgbGlicmFyeSBkb2VzIG5vdCBvY2N1ciBpbiB0aGUgc291cmNlDQo+PiArcmV0dXJuZWQg YnkgQGNvZGV7Z3VpeCBidWlsZCAtLXNvdXJjZX0sIHNvIHVzZXJzIGFuZCByZXZpZXdlcnMg ZG8gbm90DQo+PiAraGF2ZSB0byB3b3JyeSBhYm91dCB3aGV0aGVyIHRoZSBidW5kbGVkIGxp YnJhcnkgY29udGFpbnMgbWFsd2FyZSwNCj4+ICt3aGV0aGVyIGl0IGlzIG5vbi1mcmVlLCBp ZiBpdCBjb250YWlucyBwcmUtY29tcGlsZWQgYmluYXJpZXMgLi4uIFRoZXJlDQo+PiArYXJl IGFsc28gbGVzcyBsaWNlbnNpbmcgY29uY2VybnM6IGlmIHRoZSBidW5kbGVkIGxpYnJhcmll cyBhcmUNCj4+IHJlbW92ZWQsDQo+PiAraXQgYmVjb21lcyBsZXNzIGxpa2VseSB0aGF0IHRo ZSBsaWNlbnNpbmcgY29uZGl0aW9ucyBhcHBseSB0byBwZW9wbGUNCj4+ICtzaGFyaW5nIHRo ZSBzb3VyY2UgcmV0dXJuZWQgYnkgQGNvbW1hbmR7Z3VpeCBidWlsZCAtLXNvdXJjZX0sDQo+ PiBlc3BlY2lhbGx5IGlmDQo+PiArdGhlIGJ1bmRsZWQgbGlicmFyeSBpcyBub3QgYWN0dWFs bHkgdXNlZCBvbiBHdWl4DQo+PiBzeXN0ZW1zLkBmb290bm90ZXtUaGlzDQo+PiAraXMgQGVt cGh7bm90fSBhIGNsYWltIHRoYXQgeW91IGNhbiBzaW1wbHkgaWdub3JlIHRoZSBsaWNlbnNl cyBvZg0KPj4gK2xpYnJhcmllcyB3aGVuIHRoZXkgYXJlIHVuYnVuZGxlZCBhbmQgcmVwbGFj ZWQgYnkgR3VpeCBwYWNrYWdlcyAtLQ0KPj4gdGhlcmUNCj4+ICthcmUgbGVzcyBjb25jZXJu cywgbm90IG5vbmUufQ0KPj4gKw0KPj4gK0FzIHN1Y2gsIHNuaXBwZXRzIGFyZSByZWNvbW1l bmRlZCBoZXJlLg0KPj4gKw0KPj4gK0BzdWJzdWJzZWN0aW9uIEZpeGluZyB0ZWNobmljYWwg aXNzdWVzIChjb21waWxhdGlvbiBlcnJvcnMsIHRlc3QNCj4+IGZhaWx1cmVzLCBvdGhlciBi dWdzIC4uLikNCj4+ICtVc3VhbGx5LCBhIGJ1ZyBmaXggY29tZXMgaW4gdGhlIGZvcm0gb2Yg YSBwYXRjaCBjb3BpZWQgZnJvbSB1cHN0cmVhbQ0KPj4gb3INCj4+ICthbm90aGVyIGRpc3Ry aWJ1dGlvbi7CoCBJbiB0aGF0IGNhc2UsIHNpbXBseSBhZGRpbmcgdGhlIHBhdGNoIHRvIHRo ZQ0KPj4gK0Bjb2Rle3BhdGNoZXN9IGZpZWxkIGlzIHRoZSBtb3N0IGNvbnZlbmllbnQgYW5k IHVzdWFsbHkgZG9lcyBub3QgY2F1c2UNCj4+ICthbnkgcHJvYmxlbXM7IHRoZXJlIGlzIG5v IG5lZWQgdG8gcmV3cml0ZSBpdCBhcyBhIHNuaXBwZXQgb3IgYSBwaGFzZS4NCj4+ICsNCj4+ ICtJZiBubyByZWFkeS1tYWRlIHBhdGNoIGFscmVhZHkgZXhpc3RzLCB0aGVuIGNob29zaW5n IGJldHdlZW4gYSBwYXRjaA0KPj4gb3INCj4+ICthIHNuaXBwZXQgaXMgYSBtYXR0ZXIgb2Yg Y29udmVuaWVuY2UuIEhvd2V2ZXIsIHRoZXJlIGFyZSB0d28gdGhpbmdzIHRvDQo+PiAra2Vl cCBpbiBtaW5kOg0KPj4gKw0KPj4gK0ZpcnN0LCB3aGVuIHRoZSBmaXggaXMgbm90IEd1aXgt c3BlY2lmaWMsIHVwc3RyZWFtaW5nIHRoZSBmaXggaXMNCj4+ICtzdHJvbmdseSBkZXNpcmVk IHRvIGF2b2lkIHRoZSBhZGRpdGlvbmFsIG1haW50ZW5hbmNlIGNvc3QgdG8gR3VpeC7CoCBB cw0KPj4gK3Vwc3RyZWFtcyBjYW5ub3QgYWNjZXB0IHNuaXBwZXRzLCB3cml0aW5nIGEgcGF0 Y2ggY2FuIGJlIGEgbW9yZQ0KPj4gK2VmZmljaWVudCB1c2Ugb2YgdGltZS7CoCBTZWNvbmRs eSwgaWYgdGhlIGZpeCBvZiBhIHRlY2huaWNhbCBpc3N1ZQ0KPj4gZW1iZWRzDQo+PiArYSBz dG9yZSBmaWxlIG5hbWUsIHRoZW4gaXQgaGFzIHRvIGJlIGEgcGhhc2UuDQo+IEkgYW0gcHJl dHR5IHN1cmUgdGhhdCBtb3N0IG9mIHRoZXNlIGFyZSAqbm90KiBkb25lIGluIHNuaXBwZXRz LCBidXQNCj4gcmF0aGVyIHBoYXNlcywgaWYgdGhleSBvbmx5IGFmZmVjdCBHdWl4LiAgSW4g cGFydGljdWxhciwgZ3JlcCBmb3INCj4gZmFpbGluZy10ZXN0cyBhbmQgeW91IHdpbGwgZmlu ZCBhIGZldyBwaGFzZXMgZGlzYWJsaW5nIHRoZW0uDQpJIGRvIG5vdCB0aGluayB0aGF0IGln bm9yaW5nIGEgdGVzdCBjb3VudHMgYXMgYSBidWcgZml4LsKgIEknbGwgYWRkIGl0IHRvIA0K dGhpcw0Kc3Vic3Vic2VjdGlvbiwgYXQgY29zdCBvZiBzb21lIGFkZGl0aW9uYWwgbGVuZ3Ro Lg0KPiAgICBJbiBmYWN0LA0KPiBhcyBmYXIgYXMgZmlsZXMgdGhhdCB3aWxsIG5vdCBiZSBp bnN0YWxsZWQgYXJlIGNvbmNlcm5lZCwgSSB0aGluaw0KPiBwaGFzZXMgb3VnaHQgdG8gYmUg cHJlZmVycmVkLCBiZWNhdXNlIHRoZXkncmUgZWFzaWVyIHRvIHRha2UgYXdheSBpZiBhbg0K PiBhY3R1YWwgZml4IGlzIG1hZGUuDQpJIGRvIG5vdCBzZWUgYSBkaWZmZXJlbmNlIGluIGhh cmRuZXNzL2Vhc3luZXNzIGJldHdlZW4gcmVtb3ZpbmcgYQ0KcGhhc2UgYW5kIHJlbW92aW5n IGEgc25pcHBldCAoYm90aCBhcmUganVzdCBhIG1hdHRlciBvZiBvcGVuaW5nDQphbiBlZGl0 b3IsIHBvaW50aW5nIGl0IGF0IGdudS9wYWNrYWdlcy8uLi4gYW5kIHJlbW92aW5nIGEgZmV3 IGxpbmVzKSwNCnRob3VnaCBJIGRvIGNvbnNpZGVyIHJlbW92aW5nIGEgcGF0Y2ggdG8gYmUg c2xpZ2h0bHkgaGFyZGVyIChiZWNhdXNlDQpnbnUvbG9jYWwubWsgaXMgZWFzeSB0byBmb3Jn ZXQpLg0KPiBGb3IgdGhlIHN0b3JlIHBhdGggZW1iZWRkaW5nLCB0aGF0J3MgYSByYXRoZXIg cm91bmRhYm91dCB3YXkgb2Ygc2F5aW5nDQo+IHRoYXQgY29udHJpYnV0ZXJzICpvdWdodCB0 byogZW1iZWQgc3RvcmUgcGF0aHMgb2YgY2VydGFpbmcgdGhpbmdzLCBzdWNoDQo+IGFzIGNv bW1hbmRzIGludm9rZWQgdmlhIGV4ZWMgZXQgYWwuDQoNCkl0J3Mgbm90PyBJdCdzIGtpbmQg b2YgaW1wbGllZCwgeWVzLCBidXQgdGhlIHB1cnBvc2UgaXNuJ3QgYmVpbmcgYSAneW91DQpz aG91bGQgZW1iZWQgc3RvcmUgcGF0aHMnIChzdWJzdWIpc2VjdGlvbiwgYnV0IHJhdGhlciwg J2lmIHlvdSBnbyANCmVtYmVkZGluZyBzdG9yZQ0KcGF0aHMgKGF0IGxlYXN0IGZvciBmaXhp bmcgYSB0ZWNobmljYWwgaXNzdWUpLCBkbyBpdCBpbiBhIHBoYXNlJy4NCg0KSSdtIG5vdCBm b2xsb3dpbmcgd2hhdCB0aGUgY29tcGxhaW50IGlzLCBJIHN1cHBvc2UgYSBzZWN0aW9uIGNv dWxkIGJlIGFkZGVkDQpzb21ld2hlcmUgdG8gcHJvcGVybHkgZG9jdW1lbnQgdGhlICdlbWJl ZGRpbmcgc3RvcmUgZmlsZSBuYW1lcycgcHJhY3RpY2UsDQphbmQgaW5zZXJ0IGEgY3Jvc3Mt cmVmZXJlbmNlLCBidXQgdGhhdCB3YXNuJ3QgdGhlIHB1cnBvc2Ugb2YgdGhlIHBhdGNoIGFu ZA0KZ29pbmcgYnkgbGF0ZXIgcmVzcG9uc2VzLCB5b3Ugc2VlbSBvcHBvc2VkIHRvIG1ha2lu ZyB0aGluZ3MgbG9uZ2VyLg0KDQpUaGUgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gcmVtb3Zl IHRoaXMgaW5mb3JtYXRpb24sIGJ1dCB0aGVuIHZhbHVhYmxlDQppbmZvcm1hdGlvbiB3b3Vs ZCBiZSBsb3N0ICh0aGVyZSBoYWQgYmVlbiBzb21lIGNhc2VzIHdoZXJlIHN0b3JlIGZpbGUg bmFtZXMNCndlcmUgZW1iZWRkZWQgaW4gb3JpZ2luKS4NCg0KPj4gT3RoZXJ3aXNlLCBpZiB0 aGUgc3RvcmUNCj4+ICtmaWxlIG5hbWUgd2VyZSBlbWJlZGRlZCBpbiB0aGUgc291cmNlLCB0 aGUgcmVzdWx0IG9mIEBjb21tYW5ke2d1aXgNCj4+IGJ1aWxkDQo+PiArLS1zb3VyY2V9IHdv dWxkIGJlIHVudXNhYmxlIG9uIG5vbi1HdWl4IHN5c3RlbXMgYW5kIGFsc28gbGlrZWx5DQo+ PiB1bnVzYWJsZQ0KPj4gK29uIEd1aXggc3lzdGVtcyBvZiBhbm90aGVyIGFyY2hpdGVjdHVy ZS4NCj4gV2h5IGFyZSB5b3UgcmVwZWF0aW5nIGEgZ3VpZGluZyBwcmluY2lwbGU/DQpJJ20g c2hvd2luZyB3aHksIGluIHRoaXMgY2FzZSwgYSBwaGFzZSBtdXN0IGJlIHVzZWQsIGJ5IG5v dGluZyB0aGF0DQpub3QgZG9pbmcgc28gd291bGQgYmUgY29udHJhcnkgdG8gb25lIG9mIHRo ZSBwcmluY2lwbGVzLg0KDQpJZiBub3QgcmVwZWF0aW5nIHRoZSBwcmluY2lwbGUgaXMgZGVz aXJlZCwgSSBjb3VsZCBwZXJoYXBzIG51bWJlciB0aGVtLCBhbmQNCnJlZmVyIHRvIHRoZSBw cmluY2lwbGVzIGJ5IG51bWJlciBpbnN0ZWFkIG9mIHJlc3RhdGluZyB0aGVtPyBXb3VsZCBy ZWR1Y2UNCnRoZSBsZW5ndGggYSBsaXR0bGUuDQoNCj4+ICtAc3Vic3Vic2VjdGlvbiBBZGRp bmcgbmV3IGZ1bmN0aW9uYWxpdHkNCj4+ICtUbyBhZGQgbmV3IGZ1bmN0aW9uYWxpdHksIGEg cGF0Y2ggaXMgYWxtb3N0IGFsd2F5cyB0aGUgbW9zdCBjb252ZW5pZW50DQo+PiArY2hvaWNl IG9mIHRoZSB0aHJlZSAtLSBwYXRjaGVzIGFyZSB1c3VhbGx5IG11bHRpLWxpbmUgY2hhbmdl cywgd2hpY2gNCj4+IGFyZQ0KPj4gK2NvbnZlbmllbnQgdG8gZG8gd2l0aCBwYXRjaGVzIGFu ZCBpbmNvbnZlbmllbnQgdG8gZG8gd2l0aCBwaGFzZXMgb3INCj4+ICtzbmlwcGV0cy4NCj4g VWhtLCB3aGF0PyAgUGF0Y2hlcyBhcmUgdGhlIHByZWZlcnJlZCBmb3JtIG9mIHBhdGNoZXM/ DQoNCk5vLCBJIG1lYW50IHRoYXQgcGF0Y2hlcyBhcmUgKHVzdWFsbHkpIHRoZSBwcmVmZXJy ZWQgbWV0aG9kIGZvciBhZGRpbmcNCm5ldyBmdW5jdGlvbmFsaXR5LCBhbmQgdGhhdCBtdWx0 aS1saW5lIGNoYW5nZXMgYXJlIGNvbnZlbmllbnQgdG8gZG8gd2l0aA0KcGF0Y2hlcy7CoCDi gJh3aGljaOKAmSByZWZlcnMgdG8gdGhlIOKAmG11bHRpLWxpbmUgY2hhbmdlc+KAmSBoZXJl LCBub3Qg4oCYcGF0Y2hlc+KAmS4NCg0KPj4gIMKgIFRoaXMgY2hvaWNlIGlzIHVzdWFsbHkg YWxzbyBjb21wYXRpYmxlIHdpdGggYWxsIHRoZSBndWlkaW5nDQo+PiArcHJpbmNpcGxlcy7C oCBBcyBzdWNoLCBwYXRjaGVzIGFyZSBwcmVmZXJyZWQuwqAgSG93ZXZlciwgYXMgd2l0aCBi dWcNCj4+ICtmaXhlcywgdXBzdHJlYW1pbmcgdGhlIG5ldyBmdW5jdGlvbmFsaXR5IGlzIGRl c2lyZWQuDQo+PiArDQo+PiArQHN1YnNlY3Rpb24gSG93IHRvIGFkZCBwYXRjaGVzDQo+PiAr UmVmZXIgdG8gdGhlIEBjb2Rle29yaWdpbn0gcmVjb3JkIGRvY3VtZW50YXRpb24gKHBhcnRp Y3VsYXJseSB0aGUNCj4+IGZpZWxkcw0KPj4gK0Bjb2Rle3BhdGNoZXN9LCBAY29kZXtwYXRj aC1pbnB1dHN9LCBhbmQgQGNvZGV7cGF0Y2gtZmxhZ3N9KSBmb3INCj4+ICtpbmZvcm1hdGlv biBvbiBob3cgdG8gdXNlIHBhdGNoZXMgKEBweHJlZntvcmlnaW4gUmVmZXJlbmNlfSkuwqAg V2hlbg0KPj4gK2FkZGluZyBhIHBhdGNoLCBkbyBub3QgZm9yZ2V0IHRvIGFsc28gbGlzdCBp dCBpbg0KPj4gQGNvZGV7ZGlzdF9wYXRjaF9EQVRBfQ0KPj4gK29mIEBmaWxle2dudS9sb2Nh bC5ta30uDQo+IEkgZG9uJ3QgdGhpbmsgdGhpcyBzaG91bGQgYmUgYSBzdWJzZWN0aW9uLg0K UmlnaHQsIHNob3VsZCBoYXZlIGJlZW4gYSBzdWJzdWJzZWN0aW9uLg0KPj4gK0BzdWJzZWN0 aW9uIEhvdyB0byBhZGQgZmlsZXMNCj4+ICtOZXcgc291cmNlIGZpbGVzIGNhbiBiZSBhZGRl ZCBpbiBwaGFzZXMgb3Igc25pcHBldHMsIGJ5IHVzaW5nDQo+PiArQGJ7YXV4aWxpYXJyeSBm aWxlc30uwqAgQXV4aWxpYXJ5IGZpbGVzIGFyZSBzdG9yZWQgaW4gdGhlDQo+PiArQGZpbGV7 Z251L3BhY2thZ2VzL2F1eC1maWxlc30gZGlyZWN0b3J5IGFuZCBjYW4gYmUgcmV0cmlldmVk IChpbiBhDQo+PiArc25pcHBldCBvciBhIHBoYXNlKSB3aXRoIEBjb2Rle3NlYXJjaC1hdXhp bGlhcnktZmlsZX0uwqAgV2hlbiBhZGRpbmcgYW4NCj4+ICthdXhpbGlhcnkgZmlsZSwgZG8g bm90IGZvcmdldCB0byBhbHNvIGxpc3QgaXQgaW4gQGNvZGV7QVVYX0ZJTEVTfSBvZg0KPj4g K0BmaWxle01ha2VmaWxlLmFtfS4NCj4+ICsNCj4+ICtBbm90aGVyIG9wdGlvbiBmb3IgYWRk aW5nIG5ldyBmaWxlcywgaXMgdG8gdXNlIHByb2NlZHVyZXMgc3VjaCBhcw0KPj4gK0Bjb2Rl e2Rpc3BsYXl9LCBAY29kZXtmb3JtYXR9IGFuZCBAY29kZXtjYWxsLXdpdGgtb3V0cHV0LWZp bGV9LsKgIEFzIGENCj4+ICttYXR0ZXIgb2YgcHJpbmNpcGxlLCBhdXhpbGlhcnkgZmlsZXMg b3VnaHQgdG8gYmUgcHJlZmVycmVkIG92ZXIgYW4NCj4+ICtlcXVpdmFsZW50IEBjb2Rle2Nh bGwtd2l0aC1vdXRwdXQtZmlsZX0gd2hlbiBjcmVhdGluZyBub24tdHJpdmlsDQo+PiBmaWxl cywNCj4+ICthcyB0aGF0IG1ha2VzIHRoZW0gZWFzaWVyIHRvIGVkaXQuwqAgVGhlIGV4YWN0 IHRocmVzaG9sZCBmb3IgYQ0KPj4gK25vbi10cml2aWFsIGZpbGUgbWlnaHQgYmUgc3ViamVj dGl2ZSwgdGhvdWdoIGl0IHNob3VsZCBsaWUgc29tZXdoZXJlDQo+PiArYmV0d2VlbiAxMC0t MjAgbGluZXMuDQo+PiArDQo+PiArQ3VycmVudGx5LCB0aGVyZSBpcyBubyBwb2xpY3kgb24g ZGVjaWRpbmcgYmV0d2VlbiBwaGFzZSBhbmQgc25pcHBldHMNCj4+IGZvcg0KPj4gK2FkZGlu ZyBuZXcgZmlsZXMsIGV4Y2VwdCBmb3IgdGhlIGd1aWRpbmcgcHJpbmNpcGxlcy4NCj4gVGhp cyBzaG91bGQgcHJvYmFibHkgYmUgYSBzdWJzdWJzZWN0aW9uIGFmdGVyICJBZGRpbmcgbmV3 DQo+IGZ1bmN0aW9uYWxpdHkiIG9yIGV4cGxhaW5lZCB3aXRoaW4gIkFkZGluZyBuZXcgZnVu Y3Rpb25hbGl0eSIuDQo+DQo+IE92ZXJhbGwsIEknbSBub3QgY29udmluY2VkIHRoYXQgd2Ug aGF2ZSBlbm91Z2ggZ3VpZGluZyBwcmluY2lwbGVzIHRvDQo+IGNhbGwgdGhlbSB0aGF0LA0K DQpJIGRvbid0IHRoaW5rIHRoZXJlJ3MgYW55IGxvd2VyIGxpbWl0IG9uIGhvdyBtYW55IGd1 aWRpbmcgcHJpbmNpcGxlcw0KdG8gaGF2ZSwgZXhjZXB0IGZvciBwZXJoYXBzIDIgKGJlY2F1 c2Ugb3RoZXJ3aXNlIGl0IHNob3VsZCBoYXZlIGJlZW4NCnNpbmd1bGFyIG9yIHRoZXJlIGFy ZW4ndCBhbnkpLsKgIEF0IGhvdyBmZXcgZ3VpZGluZyBwcmluY2lwbGVzIHN0b3ANCnRoZSBn dWlkaW5nIHByaW5jaXBsZXMgZnJvbSBiZWluZyBndWlkaW5nIHByaW5jaXBsZXMgZm9yIHlv dSwgYW5kIHdoeT8NCg0KRm9yIGV4YW1wbGUsIG9uIDxodHRwczovL3d3dy5nbnUub3JnL3Bo aWxvc29waHkvZnJlZS1zdy5odG1sPiwgZm91ciANCmd1aWRpbmcgcHJpbmNpcGxlcyBhcmUg bWVudGlvbmVkICh3aGljaCBhcmUgbmFtZWQgJ2Vzc2VudGlhbCBmcmVlZG9tcycgDQp0aGVy ZSksIGFuZA0KPGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0d1aWRpbmdfUHJpbmNp cGxlcz4gaGFzIDUg4oCYR3VpZGluZyANClByaW5jaXBsZXPigJkuDQo+IHdoaWNoIChhbG9u ZyB3aXRoIGl0cyBzaGVlciBsZW5ndGgpIGlzIG15IG1haW4NCj4gY29tcGxhaW50IHdpdGgg dGhlIHdheSB5b3UndmUgcGhyYXNlZCB0aGluZ3MuDQoNCihJJ20gYXNzdW1pbmcgIml0cyA9 IHRoZSBwYXRjaCBhcyBhIHdob2xlIiBoZXJlKQ0KDQpJIGNvdWxkIHJlbW92ZSBhbm90aGVy IHNlY3Rpb24gb2YgdGhlIG1hbnVhbCB0byBjb21wZW5zYXRlIGZvciB0aGUNCmFkZGl0aW9u YWwgbGVuZ3RoLCBidXQgSSBkb3VidCB0aGF0J3Mgd2hhdCB5b3UgaW50ZW5kZWQuwqAgSSBk byBub3Qgc2VlIHRoZQ0KcHJvYmxlbSB3aXRoIHRoZSBzaGVlciBsZW5ndGggLS0gd2UgaGF2 ZSBhIGJpdCBvZiBhIGRvY3VtZW50YXRpb24gcHJvYmxlbQ0KaW4gR3VpeCwgdGhlcmUgaXMg bG90cyBvZiB1c2VmdWwgaW5mb3JtYXRpb24gdGhhdCBpcyBjdXJyZW50bHkgdW5kb2N1bWVu dGVkLg0KSSBkbyBub3QgdGhpbmsgdGhlcmUgaGF2ZSBiZWVuIGFueSBjb21wbGFpbnRzIGFi b3V0IHRoZSBtYW51YWwgYmVpbmcgdG9vIA0KbG9uZywNCmlmIGFueXRoaW5nLCBpdCdzIHRv byBzaG9ydC4NCg0KSSd2ZSB3cml0dGVuIHNvbWUgZG9jdW1lbnRhdGlvbiwgaXQgd2FzIG9y aWdpbmFsbHkgYSBiaXQgaGFyZCB0byBmb2xsb3cgc28NCmluIGEgbmV4dCB2ZXJzaW9uIEkn dmUgcmVzdHJ1Y3R1cmVkIGl0IGEgYml0IGFuZCBleHBsYWluZWQgbW9yZSwgdGhpcw0KcmVz dHJ1Y3R1cmluZyBhbmQgZXhwbGFuYXRpb24gZW50YWlsZWQgc29tZSBhZGRpdGlvbmFsIGxl bmd0aC4NCg0KVGhlcmUgaGFkIGJlZW4gc29tZSBwcm9wb3NhbHMgZm9yIGFkZGl0aW9uYWwg Y2FzZXMgdG8gZG9jdW1lbnQsIHNvIHRoZXkNCndlcmUgYWRkZWQsIGluY3JlYXNpbmcgdGhl IGxlbmd0aC7CoCBZb3UgaGF2ZSBhZGRlZCBuZXcgaW5mb3JtYXRpb24gaXMgeW91cg0KcGF0 Y2gsIGl0IHdhcyBjb25zaWRlcmVkIHVzZWZ1bCBzbyBJJ3ZlIGludGVncmF0ZWQgc29tZSBv ZiBpdCBpbiBteSBwYXRjaCwNCmluY3JlYXNpbmcgdGhlIGxlbmd0aC7CoCAoSSBkaWRuJ3Qg aW50ZWdyYXRlIGFsbCBvZiB0aGUgbmV3IHBhcnRzLCBpZiBJIA0KZGlkLCBpdCB3b3VsZA0K aW5jcmVhc2UgZXZlbiBmdXJ0aGVyLsKgIChJZiBkZXNpcmVkLCBpbiBjYW4gaW50ZWdyYXRl IHRoZSByZXN0LCBhdCBjb3N0IA0Kb2Ygc29tZQ0KdGltZS4pKS4NCg0KSSBkbyBub3Qgc2Vl IHdoYXQgdGhlIHByb2JsZW0gaXMgd2l0aCBhZGRpdGlvbmFsIGxlbmd0aCBhcyBsb25nIGFz IHRoaXMNCmFkZGl0aW9uYWwgbGVuZ3RoIGNvbWVzIHdpdGggYWRkaXRpb25hbCB1c2VmdWwg aW5mb3JtYXRpb24gYW5kIHRoZSBtYW51YWwNCmlzIHdlbGwtc3RydWN0dXJlZCAoZS5nLiB3 aXRoIChzdWIpKHN1YilzZWN0aW9ucywgY2hhcHRlcnMgYW5kIGluZGljZXMpIA0KLS0gd2UN CmRvIG5vdCBoYXZlIGEgcGFnZSBsaW1pdC4NCg0KQXQgd29yc3QsIHBlcmhhcHMgdGhlIHNh bWUgaW5mb3JtYXRpb24gY291bGQgcGVyaGFwcyBiZSBlbmNvZGVkIHdpdGgNCmZld2VyIHdv cmRzPyBJIGNvdWxkIGNvbXBhcmUgdGhlIHR3byBwYXRjaGVzIHRvIHNlZSB3aGljaCBvbmUg Zm9ybXVsYXRlcw0KY2VydGFpbiBpbmZvcm1hdGlvbiBpbiB0aGUgZmV3ZXN0IHdvcmRzLCBh bmQgY2hvb3NlIHRoZSBsZWFzdCB2ZXJib3NlIG9mIHRoZQ0KdHdvIGZvciBlYWNoIHBpZWNl IG9mIGluZm9ybWF0aW9uIHRoYXQgaXMgcHJlc2VudCBpbiBib3RoPw0KDQpBbHNvLCBjb21w YXJpbmcgdGhlIHR3byBwYXRjaGVzLCBteSBwYXRjaCBoYXMgNDAgbW9yZSBsaW5lcywgYnV0 IGFib3V0DQoyNSBvZiB0aGVtIGFyZSBmb3Igbm90aW5nIHRoZSBndWlkaW5nIHByaW5jaXBs ZXMgKHdoaWNoIGFyZSBhYnNlbnQgaW4gDQp5b3VyIHBhdGNoKS4NCkNvbXBlbnNhdGluZyBm b3IgdGhhdCwgdGhlIHBhdGNoZXMgYXJlIGFib3V0IHRoZSBzYW1lIGxlbmd0aCwgc28gSSBk byANCm5vdCB0aGluaw0KdGhhdCAnc2hlZXIgbGVuZ3RoJyBpcyBhY2N1cmF0ZSBoZXJlLg0K DQo+IEdvaW5nIGRvd24gdG8NCj4gc3Vic3Vic2VjdGlvbnMganVzdCB0byBmaW5kIG91dCB3 aGVyZSBwYXRjaGVzIGFyZSBhcHByb3ByaWF0ZSwgaXMgaW1obw0KPiBvdmVya2lsbC4NCg0K VGhlICdnb2luZyBkb3duIHRvIHN1YnN1YnNlY3Rpb24nIGlzIHRoZSBjYXNlIGZvciB5b3Vy IHBhdGNoIHRvbywgdGhvdWdoPw0KSW4gbXkgY2FzZSwgaXQncyBhIHN1YnN1YnNlY3Rpb24s IGluIHlvdXIgY2FzZSBpdCdzIGEgdGFibGUgZW50cnkgaW5zaWRlIGENCnN1YnNlY3Rpb24s IGJvdGggYXJlIHRoZSBzYW1lIGxldmVsIG9mIG5lc3RpbmcuDQoNCkFsc28sIGl0J3MgYSBt YXR0ZXIgb2YgZGlmZmVyZW50IHN0cnVjdHVyZSAtLSBpbiBteSB2MiBhbmQgdjMgcGF0Y2gs IEkgDQpoYXZlIGENCidwcm9ibGVtIC0+IHNvbHV0aW9uJyBzdHJ1Y3R1cmUgLS0gdGhlIGlk ZWEgaXMgdGhhdCB0aGUgcGFja2FnZXMgaGFzIGEgDQpwcm9ibGVtLA0KdGhleSBsb29rIGF0 IHRoZSBzZWN0aW9uLCB0aGV5IHJlYWQgdGhlIHN1YnN1YnNlY3Rpb24gbmFtZXMsIHNlbGVj dCB0aGUNCnN1YnN1YnNlY3Rpb24gdGhhdCBtYXRjaGVzIHRoZWlyIHByb2JsZW0gYW5kIHJl YWQgdGhlIHNvbHV0aW9uIC0tIGluIHNob3J0LA0KdGhlIGlkZWEgaXMgdG8gcHJvdmlkZSBh IHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtLg0KDQpZb3VyIHN0cnVjdHVyZSBpcyB0aGUgb3Ro ZXIgd2F5IGFyb3VuZCAtLSBmb3Igc29sdXRpb25zIChwYXRjaGVzLCBzbmlwcGV0cywNCnBo YXNlcyksIGl0IGdpdmVzIHRoZSBwZXJtaXR0ZWQgcHJvYmxlbXMgdG8gYXBwbHkgaXQgdG8u DQoNClNvIHllcywgeW91ciBwYXRjaCBpcyBtb3JlIGNvbnZlbmllbnQgZm9yIGZpbmRpbmcg b3V0IHdoZXJlIHBhdGNoZXMgYXJlDQphcHByb3ByaWF0ZS7CoCBJIGRvIG5vdCBzZWUgdGhl IGJlbmVmaXQgb2YgdGhhdCB0aG91Z2ggLS0gYSBuZXcgY29udHJpYnV0b3INCnBhY2thZ2lu ZyBhIHRoaW5nIHdvdWxkbid0IGtub3cgaW4gYWR2YW5jZSB3aGljaCBzb2x1dGlvbnMgY291 bGQgYmUNCmFwcHJvcHJpYXRlIGZvciB0aGVtICh5b3VyICdzb2x1dGlvbiAtPiBwcm9ibGVt JyBwYXRjaD8pLCByYXRoZXIsIHRoZXkgc3RhcnQNCndpdGggYSBwcm9ibGVtIGFuZCBhcmUg c2VhcmNoaW5nIGZvciBhbiBhcHByb3ByaWF0ZSBzb2x1dGlvbiAobXkNCnByb2JsZW0tPnNv bHV0aW9uIHBhdGNoKS4NCg0KR3JlZXRpbmdzLA0KTWF4aW1lLg0K --------------8K9TKb9cQWdHijgVuosbMcLl Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc" Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2 ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc /gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4 LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0 k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D =3DOVqp -----END PGP PUBLIC KEY BLOCK----- --------------8K9TKb9cQWdHijgVuosbMcLl-- --------------mg1vH0aCGVVMzb0Ns8xAZUcB-- --------------NLNRqI000ekw60aGGVxBGoXf Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYxertwUDAAAAAAAKCRBJ4+4iGRcl7gK1 AP404PUOiqiRh83oSZGTgC1xGaM3+Yf2cT2uo8ZE+T+0PwEAnTtBSLXNjkFAo8uoJ6MZJiJhWOSy nX/roFyoAOueyQU= =mpfU -----END PGP SIGNATURE----- --------------NLNRqI000ekw60aGGVxBGoXf--
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.
Received: (at 57598) by debbugs.gnu.org; 6 Sep 2022 11:34:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 06 07:34:12 2022
Received: from localhost ([127.0.0.1]:49881 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oVWq5-0002yB-2G
for submit <at> debbugs.gnu.org; Tue, 06 Sep 2022 07:34:12 -0400
Received: from mailrelay.tugraz.at ([129.27.2.202]:15843)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <liliana.prikler@HIDDEN>) id 1oVWq2-0002y1-Io
for 57598 <at> debbugs.gnu.org; Tue, 06 Sep 2022 07:33:56 -0400
Received: from lprikler-laptop.ist.intra (gw.ist.tugraz.at [129.27.202.101])
by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4MMNZ60QrVz3wk1;
Tue, 6 Sep 2022 13:33:49 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at;
s=mailrelay; t=1662464030;
bh=LAYm5HIuwF/zB9QMru6igLB+LSuMQyJA6hrE4W57i1Y=;
h=Subject:From:To:Date:In-Reply-To:References;
b=A5YvNcq+VVxbui4lxT6Sf+/g0ZLZbcIjHtLcJ/oRhTUsohdj1SLuTqiorwkrD7GyL
XUNSd6loyGr6BWuZOPUa0hnGd4scYzvx8bV7cCgc7QOojdKZRBRSUhtZYYtK4i+MOq
cWaxhg9GQ8IxU1GU1iUQPpbc2VmzHH+L6xfZJXr0=
Message-ID: <0f78953d57d8f66a934baf518b7c9e3247b580fd.camel@HIDDEN>
Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc.
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
To: Maxime Devos <maximedevos@HIDDEN>, 57598 <at> debbugs.gnu.org
Date: Tue, 06 Sep 2022 13:33:49 +0200
In-Reply-To: <20220905160048.18173-1-maximedevos@HIDDEN>
References: <20220905160048.18173-1-maximedevos@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ
X-Spam-Scanner: SpamAssassin 3.003001
X-Spam-Score-relay: -0.4
X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 57598
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Am Montag, dem 05.09.2022 um 18:00 +0200 schrieb Maxime Devos:
> +Guix has tree main ways of modifying the source code of a package,
> that
> +you as a packager may use. These are patches, snippets and phases.
> +Each one has its strengths and drawbacks. To decide between the tree,
three
> +there are a few guiding principles that to satisfy simultanuously
> where
> +possible:
"there are a few guiding principles to satisfy simultaneously",
"there are some guiding principles, of which as many as possible should
be satisfied".
> +
> +@itemize
> +@item
> +In principle, Guix only has free software; when the upstream source
> +contains some non-free software, it has to be removed such that
> +@command{guix build --source} returns the ‘freed’ source code rather
> than
> +the unmodified upstream source (@pxref{Software Freedom}).
If the latter wording above is chosen, this is not a "guiding
principle", because it is non-negotiable.
> +@item
> +The source of the package needs to correspond to what is actually
> built
> +(i.e., act as the corresponding source), to fulfill our ethical and
> +legal obligations.
> +@item
> +It is convenient for the source derived from an origin to build on any
> +system that the upstream package supports.
> +@item
> +The source needs to actually work, not only on your Guix system but
> also
> +for other systems; this requires some care for substitutions involving
> +store items and other architecture-specific changes.
If you embed store items, it won't even work on Guix System 😛️
Also, this appears to be a rather convenient rewording of the previous
item, does it not?
> +@item
> +When there is more than one way to do something, choose whichever
> method
> +is the simplest. Sometimes this is subjective, which is also fine.
> +What matters is that you use techniques that are common within the
> +community (i.e., patterns that appear throughout
> @code{gnu/packages/...})
> +and are thus clearly legible for reviewers.
> +@end itemize
> +
> +To make things more concrete and to resolve conflicts between the
> +principles, a few cases have been worked out:
> +
> +@subsubsection Removing non-free software
> +Non-free software has to be removed in snippets; the reason is that
> +patches or phases will not work.
> +
> +For patches, the problem is that a patch removing a non-free file
> +automatically contains the non-free file@footnote{It has been noted
> that
> +git patches support removing files without including the file in the
> +patch in
> +@url{
> https://yhetil.org/guix/8b13e899-eb60-490b-a268-639249698c81@@www.fastmail.com/
> }. If
> +it is verified that the @command{patch} utility supports such patches,
> +this method can be used and this policy adjusted appropriately.}, and
> we
> +do not want anything non-free in Guix even if only in its patches.
We also avoid spelling out the non-free filename where possible,
preferring keep lists over remove lists, which this kind of patches
would be.
> +For phases, the problem is that phases do not influence the result of
> +@command{guix build --source}.
> +
> +@subsubsection Removing bundled libraries
> +Bundled libraries should not be removed with patches, because then the
> +patch would contain the full bundled library, which can be large. They
> +can be removed either in snippets or phases, often using the procedure
> +@code{delete-file-recursively}. There are a few benefits for snippets
> here:
> +
> +When using snippets, the bundled library does not occur in the source
> +returned by @code{guix build --source}, so users and reviewers do not
> +have to worry about whether the bundled library contains malware,
> +whether it is non-free, if it contains pre-compiled binaries ... There
> +are also less licensing concerns: if the bundled libraries are
> removed,
> +it becomes less likely that the licensing conditions apply to people
> +sharing the source returned by @command{guix build --source},
> especially if
> +the bundled library is not actually used on Guix
> systems.@footnote{This
> +is @emph{not} a claim that you can simply ignore the licenses of
> +libraries when they are unbundled and replaced by Guix packages --
> there
> +are less concerns, not none.}
> +
> +As such, snippets are recommended here.
> +
> +@subsubsection Fixing technical issues (compilation errors, test
> failures, other bugs ...)
> +Usually, a bug fix comes in the form of a patch copied from upstream
> or
> +another distribution. In that case, simply adding the patch to the
> +@code{patches} field is the most convenient and usually does not cause
> +any problems; there is no need to rewrite it as a snippet or a phase.
> +
> +If no ready-made patch already exists, then choosing between a patch
> or
> +a snippet is a matter of convenience. However, there are two things to
> +keep in mind:
> +
> +First, when the fix is not Guix-specific, upstreaming the fix is
> +strongly desired to avoid the additional maintenance cost to Guix. As
> +upstreams cannot accept snippets, writing a patch can be a more
> +efficient use of time. Secondly, if the fix of a technical issue
> embeds
> +a store file name, then it has to be a phase.
I am pretty sure that most of these are *not* done in snippets, but
rather phases, if they only affect Guix. In particular, grep for
failing-tests and you will find a few phases disabling them. In fact,
as far as files that will not be installed are concerned, I think
phases ought to be preferred, because they're easier to take away if an
actual fix is made.
For the store path embedding, that's a rather roundabout way of saying
that contributers *ought to* embed store paths of certaing things, such
as commands invoked via exec et al.
> Otherwise, if the store
> +file name were embedded in the source, the result of @command{guix
> build
> +--source} would be unusable on non-Guix systems and also likely
> unusable
> +on Guix systems of another architecture.
Why are you repeating a guiding principle?
> +@subsubsection Adding new functionality
> +To add new functionality, a patch is almost always the most convenient
> +choice of the three -- patches are usually multi-line changes, which
> are
> +convenient to do with patches and inconvenient to do with phases or
> +snippets.
Uhm, what? Patches are the preferred form of patches?
> This choice is usually also compatible with all the guiding
> +principles. As such, patches are preferred. However, as with bug
> +fixes, upstreaming the new functionality is desired.
> +
> +@subsection How to add patches
> +Refer to the @code{origin} record documentation (particularly the
> fields
> +@code{patches}, @code{patch-inputs}, and @code{patch-flags}) for
> +information on how to use patches (@pxref{origin Reference}). When
> +adding a patch, do not forget to also list it in
> @code{dist_patch_DATA}
> +of @file{gnu/local.mk}.
I don't think this should be a subsection.
> +@subsection How to add files
> +New source files can be added in phases or snippets, by using
> +@b{auxiliarry files}. Auxiliary files are stored in the
> +@file{gnu/packages/aux-files} directory and can be retrieved (in a
> +snippet or a phase) with @code{search-auxiliary-file}. When adding an
> +auxiliary file, do not forget to also list it in @code{AUX_FILES} of
> +@file{Makefile.am}.
> +
> +Another option for adding new files, is to use procedures such as
> +@code{display}, @code{format} and @code{call-with-output-file}. As a
> +matter of principle, auxiliary files ought to be preferred over an
> +equivalent @code{call-with-output-file} when creating non-trivil
> files,
> +as that makes them easier to edit. The exact threshold for a
> +non-trivial file might be subjective, though it should lie somewhere
> +between 10--20 lines.
> +
> +Currently, there is no policy on deciding between phase and snippets
> for
> +adding new files, except for the guiding principles.
This should probably be a subsubsection after "Adding new
functionality" or explained within "Adding new functionality".
Overall, I'm not convinced that we have enough guiding principles to
call them that, which (along with its sheer length) is my main
complaint with the way you've phrased things. Going down to
subsubsections just to find out where patches are appropriate, is imho
overkill.
Cheers
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.Received: (at 57598) by debbugs.gnu.org; 5 Sep 2022 16:04:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Sep 05 12:04:36 2022 Received: from localhost ([127.0.0.1]:48685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oVEaS-000310-9U for submit <at> debbugs.gnu.org; Mon, 05 Sep 2022 12:04:36 -0400 Received: from michel.telenet-ops.be ([195.130.137.88]:44400) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <maximedevos@HIDDEN>) id 1oVEaQ-00030q-4z for 57598 <at> debbugs.gnu.org; Mon, 05 Sep 2022 12:04:34 -0400 Received: from [IPV6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16] ([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16]) by michel.telenet-ops.be with bizsmtp id GG4Y2800820ykKC06G4YWw; Mon, 05 Sep 2022 18:04:32 +0200 Message-ID: <af31b3f4-b3da-6037-0232-ce18cc315847@HIDDEN> Date: Mon, 5 Sep 2022 18:04:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc. Content-Language: en-US To: 57598 <at> debbugs.gnu.org References: <20220905160048.18173-1-maximedevos@HIDDEN> From: Maxime Devos <maximedevos@HIDDEN> In-Reply-To: <20220905160048.18173-1-maximedevos@HIDDEN> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------9PE0NeYvpkrEq4ClQkcSqD9K" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1662393872; bh=hnk2WgffFcJR4jv001NrSILY2Sie5l0UpvNNDezf7Gg=; h=Date:Subject:To:References:From:In-Reply-To; b=hp8or0ROJ58z/RwwS/0P+rU96EkSnh+ofUVfbNEYXY+AwH6S9QR8UdCIAOZfsnqtU wzUDPxr1cFkygKsDXgdK5mI6ooQQ3lspq7OIV8ETsF2kTXSEVqpj+wRsG+/M8/Iqh+ takoBxuz8sZ9HnDR5rjmBosDO1fHA4EAfofz764j3BY/fcgC5HlhqhwLVAA60QmS/N 6fLu+EsA5CN4o6cnbsL7EJ7NKHACiR4JLJIlJD4gjM7mQ5P85M/F8M79E41nhEchzs bFyLrZQxe0LEBvig8dwIBP1kFvD7rSTp8mCteLvY+sGFt+Urei+JCYMevoO/j8aCfQ BOFTgnNnLEftA== X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57598 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------9PE0NeYvpkrEq4ClQkcSqD9K Content-Type: multipart/mixed; boundary="------------imrO1rPoHPpkXkVxDoogeyWv"; protected-headers="v1" From: Maxime Devos <maximedevos@HIDDEN> To: 57598 <at> debbugs.gnu.org Message-ID: <af31b3f4-b3da-6037-0232-ce18cc315847@HIDDEN> Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc. References: <20220905160048.18173-1-maximedevos@HIDDEN> In-Reply-To: <20220905160048.18173-1-maximedevos@HIDDEN> --------------imrO1rPoHPpkXkVxDoogeyWv Content-Type: multipart/mixed; boundary="------------HS8VwQD1bKu4RzpvrCKxNxhV" --------------HS8VwQD1bKu4RzpvrCKxNxhV Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 U2VlIHRoZSB0aHJlYWQgDQo8aHR0cHM6Ly95aGV0aWwub3JnL2d1aXgvMDNhMjgyNjItMzE2 ZC0yMGZjLWVhOTEtNTM3OWM3NDM2MmIxQHRlbGVuZXQuYmUvPi4NCg0KVGhlcmUgaXMgYWxz byBhbm90aGVyIHBhdGNoIA0KPGh0dHBzOi8veWhldGlsLm9yZy9ndWl4LzFkY2NhNTc1NTgw NjI0ZGRjYzIwODg4M2VlNjJkOGM3NWY5MDgxMzkuY2FtZWxAZ21haWwuY29tLz4sIA0Kd2hp Y2ggZG9jdW1lbnRzIHRoZSBzYW1lIHRoaW5nLCBidXQgZGlmZmVyZW50bHkuDQoNCkdyZWV0 aW5ncywNCk1heGltZQ0K --------------HS8VwQD1bKu4RzpvrCKxNxhV Content-Type: application/pgp-keys; name="OpenPGP_0x49E3EE22191725EE.asc" Content-Disposition: attachment; filename="OpenPGP_0x49E3EE22191725EE.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEX4ch6BYJKwYBBAHaRw8BAQdANPb/d6MrGnGi5HyvODCkBUJPRjiFQcRU5V+m xvMaAa/NL01heGltZSBEZXZvcyA8bWF4aW1lLmRldm9zQHN0dWRlbnQua3VsZXV2 ZW4uYmU+wpAEExYIADgWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCX4ch6AIbAwUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBJ4+4iGRcl7japAQC3opZ2KGWzWmRc /gIWSu0AAcfMwyinFEEPa/QhUt2CogD/e2RdF4CYAgaRHJJmZ9WU7piKbLZ7llB4 LzgezVDHggzNJU1heGltZSBEZXZvcyA8bWF4aW1lZGV2b3NAdGVsZW5ldC5iZT7C kAQTFggAOBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJf56ycAhsDBQsJCAcDBRUK CQgLBRYCAwEAAh4BAheAAAoJEEnj7iIZFyXujpQBAKV1SwDDl4f24rXciDlB9L8W ycZt30CgbewMSRQk4mvbAP9dFMbVVixYBd6C8cfhR+NsOBGiOJnQABlUmgNuqGFJ Dc44BF+HIegSCisGAQQBl1UBBQEBB0BOlzIWiJzgobMF6/cqwLaLk7jIcFSZ++c0 k9cCNT6YXwMBCAfCeAQYFggAIBYhBMHzPuIMUo/bfdcBH0nj7iIZFyXuBQJfhyHo AhsMAAoJEEnj7iIZFyXuMr0BAJc8cl5PGvVmVuSQVKjleNl4DK1/XAaPAYPe34AE fZJPAP9IqLCQhH/FeJanHqBP8gNdGNI2qn8RnnLVfRJgUjZ1BA=3D=3D =3DOVqp -----END PGP PUBLIC KEY BLOCK----- --------------HS8VwQD1bKu4RzpvrCKxNxhV-- --------------imrO1rPoHPpkXkVxDoogeyWv-- --------------9PE0NeYvpkrEq4ClQkcSqD9K Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYxYeEAUDAAAAAAAKCRBJ4+4iGRcl7kJR AQD2D1RcH32u+syWAHDP91rOjDdvl8g+gokXNnISDiEOVwD9FRq8sVXqerK2QdLjKUU8Cu6rdjMy mM0ojNtvoj/8aQI= =k2zR -----END PGP SIGNATURE----- --------------9PE0NeYvpkrEq4ClQkcSqD9K--
guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.
Received: (at submit) by debbugs.gnu.org; 5 Sep 2022 16:01:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Sep 05 12:01:07 2022
Received: from localhost ([127.0.0.1]:48672 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oVEX4-0002uF-JG
for submit <at> debbugs.gnu.org; Mon, 05 Sep 2022 12:01:07 -0400
Received: from lists.gnu.org ([209.51.188.17]:47192)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <maximedevos@HIDDEN>) id 1oVEX2-0002u7-Dp
for submit <at> debbugs.gnu.org; Mon, 05 Sep 2022 12:01:05 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:54508)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <maximedevos@HIDDEN>)
id 1oVEX1-0002eu-O8
for guix-patches@HIDDEN; Mon, 05 Sep 2022 12:01:04 -0400
Received: from laurent.telenet-ops.be ([2a02:1800:110:4::f00:19]:56432)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <maximedevos@HIDDEN>)
id 1oVEWu-0005oG-R3
for guix-patches@HIDDEN; Mon, 05 Sep 2022 12:01:02 -0400
Received: from localhost.localdomain
([IPv6:2a02:1811:8c09:9d00:5dba:d409:33f7:a16])
by laurent.telenet-ops.be with bizsmtp
id GG0q2800B20ykKC01G0qud; Mon, 05 Sep 2022 18:00:50 +0200
From: Maxime Devos <maximedevos@HIDDEN>
To: guix-patches@HIDDEN
Subject: [PATCH] doc: Update contribution guidelines on patches, etc.
Date: Mon, 5 Sep 2022 18:00:48 +0200
Message-Id: <20220905160048.18173-1-maximedevos@HIDDEN>
X-Mailer: git-send-email 2.37.2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22;
t=1662393650; bh=KPB1SsoMTS46gQyNDNiuGhWEicwgcbuMCxn15uCYdD4=;
h=From:To:Cc:Subject:Date;
b=butgFw7JPLgjy5LI96zN20DCLhjISBaU/bRi7uzkf6vFVF7iqVecfClD0r6QPmNtR
M2JmduTUU62kuyfWKIEIwYkHt6q+2OlPqaxYeoF1etX+cTa6F2CNtgOPBtqj0VWipU
rkfNyc/ZlBrHnq9rxPsPvrSWhuAu4x8xQYoeTw3QrxsFCDyTRnijV5OUOx9eqy9KKe
Ht3Engzo5E3KQiC6hTMYYahtF1Tcud9zlYnHeHlF1B4c1c30jhrbGzVVfQKjq3XGUo
RSPk4fwm4Vrqap57rxV7FPphkj695ccZVb4iGzGUe+tRdzF6OCR87nAWuctQbB1Bdw
TBkakAJTsWzVw==
Received-SPF: pass client-ip=2a02:1800:110:4::f00:19;
envelope-from=maximedevos@HIDDEN; helo=laurent.telenet-ops.be
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.1 (/)
X-Debbugs-Envelope-To: submit
Cc: Maxime Devos <maximedevos@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)
* doc/contributing.texi (Modifying Sources): Replaced with ...
("Modifying Sources"): ... this. List more use cases and some principles.
This patch incorporates some tet written by Liliana Marie Prikler. The
structure is based on a proposal by Julien Lepiller. The text has been
revised based on reviews by David Larsson and blake.
---
doc/contributing.texi | 141 +++++++++++++++++++++++++++++++++++++-----
doc/guix.texi | 2 +-
2 files changed, 127 insertions(+), 16 deletions(-)
diff --git a/doc/contributing.texi b/doc/contributing.texi
index 02c7c5ae59..f6bdb8a441 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -441,7 +441,7 @@ needed is to review and apply the patch.
* Package Naming:: What's in a name?
* Version Numbers:: When the name is not enough.
* Synopses and Descriptions:: Helping users find the right package.
-* Snippets versus Phases:: Whether to use a snippet, or a build phase.
+* Modifying Sources:: Whether to use a snippet, or a build phase.
* Emacs Packages:: Your Elisp fix.
* Python Modules:: A touch of British comedy.
* Perl Modules:: Little pearls.
@@ -698,20 +698,131 @@ Gettext}):
for the X11 resize-and-rotate (RandR) extension. @dots{}")
@end lisp
-@node Snippets versus Phases
-@subsection Snippets versus Phases
-
-@cindex snippets, when to use
-The boundary between using an origin snippet versus a build phase to
-modify the sources of a package can be elusive. Origin snippets are
-typically used to remove unwanted files such as bundled libraries,
-nonfree sources, or to apply simple substitutions. The source derived
-from an origin should produce a source that can be used to build the
-package on any system that the upstream package supports (i.e., act as
-the corresponding source). In particular, origin snippets must not
-embed store items in the sources; such patching should rather be done
-using build phases. Refer to the @code{origin} record documentation for
-more information (@pxref{origin Reference}).
+@node Modifying Sources
+@subsection Modifying Sources
+
+Guix has tree main ways of modifying the source code of a package, that
+you as a packager may use. These are patches, snippets and phases.
+Each one has its strengths and drawbacks. To decide between the tree,
+there are a few guiding principles that to satisfy simultanuously where
+possible:
+
+@itemize
+@item
+In principle, Guix only has free software; when the upstream source
+contains some non-free software, it has to be removed such that
+@command{guix build --source} returns the ‘freed’ source code rather than
+the unmodified upstream source (@pxref{Software Freedom}).
+@item
+The source of the package needs to correspond to what is actually built
+(i.e., act as the corresponding source), to fulfill our ethical and
+legal obligations.
+@item
+It is convenient for the source derived from an origin to build on any
+system that the upstream package supports.
+@item
+The source needs to actually work, not only on your Guix system but also
+for other systems; this requires some care for substitutions involving
+store items and other architecture-specific changes.
+@item
+When there is more than one way to do something, choose whichever method
+is the simplest. Sometimes this is subjective, which is also fine.
+What matters is that you use techniques that are common within the
+community (i.e., patterns that appear throughout @code{gnu/packages/...})
+and are thus clearly legible for reviewers.
+@end itemize
+
+To make things more concrete and to resolve conflicts between the
+principles, a few cases have been worked out:
+
+@subsubsection Removing non-free software
+Non-free software has to be removed in snippets; the reason is that
+patches or phases will not work.
+
+For patches, the problem is that a patch removing a non-free file
+automatically contains the non-free file@footnote{It has been noted that
+git patches support removing files without including the file in the
+patch in
+@url{https://yhetil.org/guix/8b13e899-eb60-490b-a268-639249698c81@@www.fastmail.com/}. If
+it is verified that the @command{patch} utility supports such patches,
+this method can be used and this policy adjusted appropriately.}, and we
+do not want anything non-free in Guix even if only in its patches.
+
+For phases, the problem is that phases do not influence the result of
+@command{guix build --source}.
+
+@subsubsection Removing bundled libraries
+Bundled libraries should not be removed with patches, because then the
+patch would contain the full bundled library, which can be large. They
+can be removed either in snippets or phases, often using the procedure
+@code{delete-file-recursively}. There are a few benefits for snippets here:
+
+When using snippets, the bundled library does not occur in the source
+returned by @code{guix build --source}, so users and reviewers do not
+have to worry about whether the bundled library contains malware,
+whether it is non-free, if it contains pre-compiled binaries ... There
+are also less licensing concerns: if the bundled libraries are removed,
+it becomes less likely that the licensing conditions apply to people
+sharing the source returned by @command{guix build --source}, especially if
+the bundled library is not actually used on Guix systems.@footnote{This
+is @emph{not} a claim that you can simply ignore the licenses of
+libraries when they are unbundled and replaced by Guix packages -- there
+are less concerns, not none.}
+
+As such, snippets are recommended here.
+
+@subsubsection Fixing technical issues (compilation errors, test failures, other bugs ...)
+Usually, a bug fix comes in the form of a patch copied from upstream or
+another distribution. In that case, simply adding the patch to the
+@code{patches} field is the most convenient and usually does not cause
+any problems; there is no need to rewrite it as a snippet or a phase.
+
+If no ready-made patch already exists, then choosing between a patch or
+a snippet is a matter of convenience. However, there are two things to
+keep in mind:
+
+First, when the fix is not Guix-specific, upstreaming the fix is
+strongly desired to avoid the additional maintenance cost to Guix. As
+upstreams cannot accept snippets, writing a patch can be a more
+efficient use of time. Secondly, if the fix of a technical issue embeds
+a store file name, then it has to be a phase. Otherwise, if the store
+file name were embedded in the source, the result of @command{guix build
+--source} would be unusable on non-Guix systems and also likely unusable
+on Guix systems of another architecture.
+
+@subsubsection Adding new functionality
+To add new functionality, a patch is almost always the most convenient
+choice of the three -- patches are usually multi-line changes, which are
+convenient to do with patches and inconvenient to do with phases or
+snippets. This choice is usually also compatible with all the guiding
+principles. As such, patches are preferred. However, as with bug
+fixes, upstreaming the new functionality is desired.
+
+@subsection How to add patches
+Refer to the @code{origin} record documentation (particularly the fields
+@code{patches}, @code{patch-inputs}, and @code{patch-flags}) for
+information on how to use patches (@pxref{origin Reference}). When
+adding a patch, do not forget to also list it in @code{dist_patch_DATA}
+of @file{gnu/local.mk}.
+
+@subsection How to add files
+New source files can be added in phases or snippets, by using
+@b{auxiliarry files}. Auxiliary files are stored in the
+@file{gnu/packages/aux-files} directory and can be retrieved (in a
+snippet or a phase) with @code{search-auxiliary-file}. When adding an
+auxiliary file, do not forget to also list it in @code{AUX_FILES} of
+@file{Makefile.am}.
+
+Another option for adding new files, is to use procedures such as
+@code{display}, @code{format} and @code{call-with-output-file}. As a
+matter of principle, auxiliary files ought to be preferred over an
+equivalent @code{call-with-output-file} when creating non-trivil files,
+as that makes them easier to edit. The exact threshold for a
+non-trivial file might be subjective, though it should lie somewhere
+between 10--20 lines.
+
+Currently, there is no policy on deciding between phase and snippets for
+adding new files, except for the guiding principles.
@node Emacs Packages
@subsection Emacs Packages
diff --git a/doc/guix.texi b/doc/guix.texi
index 7bce8a567c..042ab3bd8a 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -70,7 +70,7 @@ Copyright @copyright{} 2019 Jakob L. Kreuze@*
Copyright @copyright{} 2019 Kyle Andrews@*
Copyright @copyright{} 2019 Alex Griffin@*
Copyright @copyright{} 2019, 2020, 2021, 2022 Guillaume Le Vaillant@*
-Copyright @copyright{} 2020 Liliana Marie Prikler@*
+Copyright @copyright{} 2020, 2022 Liliana Marie Prikler@*
Copyright @copyright{} 2019, 2020, 2021, 2022 Simon Tournier@*
Copyright @copyright{} 2020 Wiktor Żelazny@*
Copyright @copyright{} 2020 Damien Cassou@*
base-commit: 57f8f69562e942557e3331bb81c7e4acd973d189
prerequisite-patch-id: 78c06b38a189109a5108a157d39ffe7eab8be109
prerequisite-patch-id: aaf0731113d36df901ed2186975e3bb872ec22c0
prerequisite-patch-id: 28e8223cfd59adf84007db9ceefd8a78c41fd10d
prerequisite-patch-id: fb73228d99c36f50e2959c2303c7c707460fd147
prerequisite-patch-id: 7626f1464f4926416fb13daf3d846176aa93f51b
prerequisite-patch-id: 445c6f624e99627959f2e54a6ee97337c44d9ea6
prerequisite-patch-id: 7a16c500faec9d58700a2b50b26bded079e9c3ac
prerequisite-patch-id: f7d406c61e069c04c3b7da453192f51c04763db1
prerequisite-patch-id: 4674bf40052d97215f837c9dfd4e7e1ae999492d
prerequisite-patch-id: 6259468375bfa157277521b17fdd97d6ab0748b7
prerequisite-patch-id: 9d14b38a33b68883c43d6b26dcdbdf7c28e417e7
prerequisite-patch-id: f0e3faffe768e9c660b0a9340042acfa0f790308
prerequisite-patch-id: 550485506255a67c0a1cb9ede7778d4d538b6e2a
prerequisite-patch-id: 9282e95ff076cc2c742be8d2fede83ac14006f6f
prerequisite-patch-id: 1503aa5c698f72ee47b7a987a95c0919efb203c4
prerequisite-patch-id: 24297940086a3780fd7e2e7fa345f262b12efb6f
prerequisite-patch-id: c5f647b5472465666328b123f0f314a6138d6293
prerequisite-patch-id: 56386c4df9130221cad664ec161d1ad9713f4dc3
prerequisite-patch-id: f09ccfb7e53bc7934326af603a197344f4ef53f3
prerequisite-patch-id: 0c18c83d1f2da4639b43861103a028706a147022
prerequisite-patch-id: 066bfca8bf0c3d3bc57a14b48aa1e241555c1e86
prerequisite-patch-id: 13d9ac7b0fadc92b9351409df26b41443497a964
prerequisite-patch-id: ad831a04543475288aba1c938078dcc5ad05870e
prerequisite-patch-id: ed9ec2d0bea23c2c2dbfa4c62290893f1a938f7f
prerequisite-patch-id: 335ce9dbbb2b36b960203a79fdc8f6033ebda2fb
prerequisite-patch-id: f2ca362056369913d0b8319187a8f46ea78b6dc7
prerequisite-patch-id: c02a17479ad4e01837fc307cf6defe0ae92e2435
prerequisite-patch-id: 3a794307f3bbd3641023d978f4b359eb2f5a46e4
prerequisite-patch-id: c545007535db365a29dc3a86e10866f5eef7b7d5
prerequisite-patch-id: 8b8fd18762282129e2d034f7cdceb368f53295d6
prerequisite-patch-id: d435d42bafa65f14049740a3d6cf1a163f855f97
prerequisite-patch-id: 27da1b857019b217b25b6795b84577fdc992a84c
prerequisite-patch-id: aef95e76144ae5e92a41f81b11e84ddc7ececd91
prerequisite-patch-id: 95aa6b45d93026e4375b53a471f0f96e2016914e
prerequisite-patch-id: 715d2bb93fe711e72388458846a0afde6babdc97
prerequisite-patch-id: 63422b710539c3eeac249bf0201107914a215d16
prerequisite-patch-id: 53c9d2236538f9a9009b5b7b2455ef4875d0e31a
prerequisite-patch-id: 37df0e9658435e0a5e2b49fe54a69b91385fb596
prerequisite-patch-id: d2ecaf3439d153de1d53f608e7f5815c73d7b93c
--
2.37.2
Maxime Devos <maximedevos@HIDDEN>:guix-patches@HIDDEN.
Full text available.guix-patches@HIDDEN:bug#57598; Package guix-patches.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.