From unknown Mon Aug 18 08:54:06 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#65206 <65206@debbugs.gnu.org> To: bug#65206 <65206@debbugs.gnu.org> Subject: Status: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain Reply-To: bug#65206 <65206@debbugs.gnu.org> Date: Mon, 18 Aug 2025 15:54:06 +0000 retitle 65206 29.1; [windows][patch] build-deps-zips.py is broken and hard = to maintain reassign 65206 emacs submitter 65206 Corwin Brust severity 65206 normal tag 65206 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 10 08:41:13 2023 Received: (at submit) by debbugs.gnu.org; 10 Aug 2023 12:41:13 +0000 Received: from localhost ([127.0.0.1]:41654 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU4yX-0000Bt-21 for submit@debbugs.gnu.org; Thu, 10 Aug 2023 08:41:13 -0400 Received: from lists.gnu.org ([2001:470:142::17]:44664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU4yT-0000Be-FA for submit@debbugs.gnu.org; Thu, 10 Aug 2023 08:41:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qU4yO-00016s-4C for bug-gnu-emacs@gnu.org; Thu, 10 Aug 2023 08:41:04 -0400 Received: from mail-ot1-f44.google.com ([209.85.210.44]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qU4yL-000422-UM for bug-gnu-emacs@gnu.org; Thu, 10 Aug 2023 08:41:03 -0400 Received: by mail-ot1-f44.google.com with SMTP id 46e09a7af769-6bca38a6618so784398a34.3 for ; Thu, 10 Aug 2023 05:41:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691671259; x=1692276059; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=LQhZyRu8o0PEvtFN1PFwJjG8KYT4uDaSTCjCWy7SnZQ=; b=Qgt9iRbn0sq0P52keEjXp29z+dN9Ktz4YGq+2x9QKxCCI5nXZeiDsnU2JmDQt6tqrP y+0saUrr7dsMxneG0xUZMDn5DjStmra5ukZ9nsGvp36vudxKPeKeiyFac7K9P91mRoex U3jJnPoXm9VrWPOYpUeIjnZRo9IyTIDfLj2NGy5zNUBz6pCk0VwrQu+XBrcB6/mizO+L RvA6AkAdxboFtxtgyjMKN2kxEUflOFQnVX8Am2ZCb4inaFeFOS8ItPmQv87FrfDQl0N/ gVsAw1lXcRv1W7QmH6P9qpYz87tyCX1G3B7zeTPktqWQ+XJqUQu3NlEzqMHg2U/mXDBM H5eg== X-Gm-Message-State: AOJu0Yy0pz8gXWEsuP0DLtyXbA6dDuFJ/WLyET8yUWLirYQOS+SvwWQl DVcxKzd9q1sB//VT003yc+z59P9LTo8W7olaQ0+SylCfImw= X-Google-Smtp-Source: AGHT+IHPdFB61Xcz927zlNI3a4qtcIAwKOiQMiXlp25kmRGuweQG5ify5hbNPLBVEbhZmTh7r2EZxx0MlZjRuQGle/k= X-Received: by 2002:a05:6830:607:b0:6bb:1036:67f2 with SMTP id w7-20020a056830060700b006bb103667f2mr2470905oti.6.1691671259439; Thu, 10 Aug 2023 05:40:59 -0700 (PDT) MIME-Version: 1.0 From: Corwin Brust Date: Thu, 10 Aug 2023 07:40:48 -0500 Message-ID: Subject: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain To: bug-gnu-emacs@gnu.org Content-Type: multipart/mixed; boundary="0000000000007f05ae060290e81e" Received-SPF: pass client-ip=209.85.210.44; envelope-from=mplscorwin@gmail.com; helo=mail-ot1-f44.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.5 (+) 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: The script nt/admin/dist-build/build-deps-zips.py needs help. This is the script that I use to collect and package dependencies and sources for dependencies on Microsoft Windows, as part of releasing [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mplscorwin[at]gmail.com) 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 T_SCC_BODY_TEXT_LINE No description available. X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) --0000000000007f05ae060290e81e Content-Type: text/plain; charset="UTF-8" The script nt/admin/dist-build/build-deps-zips.py needs help. This is the script that I use to collect and package dependencies and sources for dependencies on Microsoft Windows, as part of releasing Emacs binaries for Windows. It is a python script that runs under MSYS2 MSYS console (not MinGW). Neither the version currently in the emacs-29 nor in the master branches will work for the given Emacs version without changes. The attached patch would make emacs-29 match what I am using locally. In addition to other changes, the patch reflects my current "transformation map" approach to deal with MSYS source package paths change, which seems to be happening quite a bit upstream. In case it may not be clear, my process is to run the script after updating local MSYS packages that are dependencies (optional or no), or edit and run it when Emacs' dependencies have changed. The patch reflects the script as I have been using it during the Emacs 29 release process. I'm sure there's general room for improvement (editing this script is literally my only python coding credit), I'm opening this bug report because bug#65188 (a packaging error preventing WEBP from working for people using the Windows binaries) has called attention to the importance of having additional eyes on build tooling (especially when it so far contains hard-coded lists of upstream deps). In GNU Emacs 29.1 (build 2, x86_64-w64-mingw32) of 2023-08-02 built on AVALON Windowing system distributor 'Microsoft Corp.', version 10.0.19045 System Description: Microsoft Windows 10 Home (v10.0.2009.19045.3324) Configured using: 'configure --with-modules --without-dbus --with-native-compilation=aot --without-compress-install --with-tree-sitter CFLAGS=-O2' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB Important settings: value of $LANG: ENU locale-coding-system: cp1252 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra help-mode bytecomp byte-compile cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 80415 13861) (symbols 48 7175 0) (strings 32 21269 1764) (string-bytes 1 617449) (vectors 16 16398) (vector-slots 8 334731 15794) (floats 8 29 46) (intervals 56 238 0) (buffers 984 10)) --0000000000007f05ae060290e81e Content-Type: application/octet-stream; name="0001-Fix-Windows-build-dependancy-packaging-for-Emacs-29-.patch" Content-Disposition: attachment; filename="0001-Fix-Windows-build-dependancy-packaging-for-Emacs-29-.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ll559pnv0 RnJvbSA5MzIzMjBjZGE0ZDc2MzNjYjQ4YmI4OTE2M2ZiOWNmNjJjNWUyMDhkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBDb3J3aW4gQnJ1c3QgPGNvcndpbkBicnUuc3Q+CkRhdGU6IFRo dSwgMTAgQXVnIDIwMjMgMDc6MTk6NDEgLTA1MDAKU3ViamVjdDogW1BBVENIXSA7IEZpeCBXaW5k b3dzIGJ1aWxkIGRlcGVuZGFuY3kgcGFja2FnaW5nIGZvciBFbWFjcyAyOSBhbmQgMzAKCiogbnQv YWRtaW4vZGlzdC1idWlsZC9idWlsZC1kZXBzLXppcHMucHkgKHNjcmlwdCk6IGFkZCB3ZWJwLApY cG0sIFhwbS1ub1g0LCB0cmVlc2l0dGVyLCBhbmQgc3FsaXRlNCwgYnVtcCBFTUFDU19NQUpPUl9W RVJTSU9OLApyZW1vdmUgdW5uZWVkZWQgaW1wb3J0cywgY2hhbmdlIHZlbmRvciBzbHVnIGZyb20g bXN5czY0IHRvIG1pbmd3NjQsCnNraXAgc29tZSBhbmNpZW50IGNlcnRpZmljYXRlcywgYWRkIFNS Q19FWFQgdG8gbWFwIHRyYW5zZm9ybWF0aW9uCnNvdXJjZSBwYWNrYWdlIG5hbWUgdHJhbnNmb3Jt YXRpb25zIHZzIGhpc3RvcmljYWwgY29udmVudGlvbi4KLS0tCiBhZG1pbi9udC9kaXN0LWJ1aWxk L2J1aWxkLWRlcC16aXBzLnB5IHwgODQgKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tCiAxIGZp bGUgY2hhbmdlZCwgNTcgaW5zZXJ0aW9ucygrKSwgMjcgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0 IGEvYWRtaW4vbnQvZGlzdC1idWlsZC9idWlsZC1kZXAtemlwcy5weSBiL2FkbWluL250L2Rpc3Qt YnVpbGQvYnVpbGQtZGVwLXppcHMucHkKaW5kZXggNzExMDVhMDcxZWMuLmE3YzExNmQ5YjQxIDEw MDc1NQotLS0gYS9hZG1pbi9udC9kaXN0LWJ1aWxkL2J1aWxkLWRlcC16aXBzLnB5CisrKyBiL2Fk bWluL250L2Rpc3QtYnVpbGQvYnVpbGQtZGVwLXppcHMucHkKQEAgLTIwLDEzICsyMCwxMSBAQAog aW1wb3J0IG9zCiBpbXBvcnQgc2h1dGlsCiBpbXBvcnQgcmUKLWltcG9ydCBmdW5jdG9vbHMKLWlt cG9ydCBvcGVyYXRvcgogCiBmcm9tIHN1YnByb2Nlc3MgaW1wb3J0IGNoZWNrX291dHB1dAogCiAj IyBDb25zdGFudHMKLUVNQUNTX01BSk9SX1ZFUlNJT049IjI4IgorRU1BQ1NfTUFKT1JfVkVSU0lP Tj0iMjkiCiAKICMgVGhpcyBsaXN0IGRlcml2ZXMgZnJvbSB0aGUgZmVhdHVyZXMgd2Ugd2FudCBF bWFjcyB0byBjb21waWxlIHdpdGguCiBQS0dfUkVRPScnJ21pbmd3LXc2NC14ODZfNjQtZ2lmbGli CkBAIC0zNyw5ICszNSwxMyBAQAogbWluZ3ctdzY0LXg4Nl82NC1saWJqcGVnLXR1cmJvCiBtaW5n dy13NjQteDg2XzY0LWxpYnBuZwogbWluZ3ctdzY0LXg4Nl82NC1saWJyc3ZnCittaW5ndy13NjQt eDg2XzY0LWxpYndlYnAKIG1pbmd3LXc2NC14ODZfNjQtbGlidGlmZgogbWluZ3ctdzY0LXg4Nl82 NC1saWJ4bWwyCi1taW5ndy13NjQteDg2XzY0LXhwbS1ub3gnJycuc3BsaXQoKQorbWluZ3ctdzY0 LXg4Nl82NC1nbXAKK21pbmd3LXc2NC14ODZfNjQteHBtLW5veAorbWluZ3ctdzY0LXg4Nl82NC10 cmVlLXNpdHRlcgorbWluZ3ctdzY0LXg4Nl82NC1zcWxpdGUzJycnLnNwbGl0KCkKIAogRExMX1JF UT0nJydsaWJnaWYKIGxpYmdudXRscwpAQCAtNDksOSArNTEsMTQgQEAKIGxpYnR1cmJvanBlZwog bGlicG5nCiBsaWJyc3ZnCitsaWJ3ZWJwCiBsaWJ0aWZmCiBsaWJ4bWwKLWxpYlhwbScnJy5zcGxp dCgpCitsaWJnbXAKK2xpYlhwbQorbGliWHBtLW5vWDQKK2xpYnRyZWUtc2l0dGVyCitsaWJzcWxp dGUzLTAnJycuc3BsaXQoKQogCiAKICMjIE9wdGlvbnMKQEAgLTEwMyw3ICsxMTAsNyBAQCBkZWYg bnRsZGRfbXVuZ2Uob3V0KToKIAogICAgICAgICAjIyBpZiBpdCdzIHRoZSBmb3JtZXIsIHdlIHdh bnQgaXQsIGlmIGl0cyB0aGUgbGF0ZXIgd2UgZG9uJ3QKICAgICAgICAgc3BsdCA9IGRlcC5zcGxp dCgpCi0gICAgICAgIGlmIGxlbihzcGx0KSA+IDIgYW5kICJtc3lzNjQiIGluIHNwbHRbMl06Cisg ICAgICAgIGlmIGxlbihzcGx0KSA+IDIgYW5kICJtaW5ndzY0IiBpbiBzcGx0WzJdOgogICAgICAg ICAgICAgcHJpbnQoIkFkZGluZyBkZXAiLCBzcGx0WzBdKQogICAgICAgICAgICAgcnRuLmFwcGVu ZChzcGx0WzBdLnNwbGl0KCIuIilbMF0pCiAKQEAgLTExNCwyNiArMTIxLDQ1IEBAIGRlZiBudGxk ZF9tdW5nZShvdXQpOgogIyMgUGFja2FnZXMgdG8gZmlkZGxlIHdpdGgKICMjIFNvdXJjZSBmb3Ig Z2NjLWxpYnMgaXMgcGFydCBvZiBnY2MKIFNLSVBfU1JDX1BLR1M9WyJtaW5ndy13NjQtZ2NjLWxp YnMiXQotU0tJUF9ERVBfUEtHUz1mcm96ZW5zZXQoWyJtaW5ndy13NjQteDg2XzY0LWdsaWIyIl0p CitTS0lQX0RFUF9QS0dTPVsibWluZ3ctdzY0LWdsaWIyIiAibWluZ3ctdzY0LWNhLWNlcnRpZmlj YXRlcy0yMDIxMTAxNi0zIl0KIE1VTkdFX1NSQ19QS0dTPXsibWluZ3ctdzY0LWxpYndpbnB0aHJl YWQtZ2l0IjoibWluZ3ctdzY0LXdpbnB0aHJlYWRzLWdpdCJ9CiBNVU5HRV9ERVBfUEtHUz17CiAg ICAgIm1pbmd3LXc2NC14ODZfNjQtbGlid2lucHRocmVhZCI6Im1pbmd3LXc2NC14ODZfNjQtbGli d2lucHRocmVhZC1naXQiLAogICAgICJtaW5ndy13NjQteDg2XzY0LWxpYnRyZSI6ICJtaW5ndy13 NjQteDg2XzY0LWxpYnRyZS1naXQiLAogfQorU1JDX0VYVD17CisgICAgIm1pbmd3LXc2NC1mcmVl dHlwZSI6ICIuc3JjLnRhci56c3QiLAorICAgICJtaW5ndy13NjQtZnJpYmlkaSI6ICIuc3JjLnRh ci56c3QiLAorICAgICJtaW5ndy13NjQtZ2xpYjIiOiAiLnNyYy50YXIuenN0IiwKKyAgICAibWlu Z3ctdzY0LWhhcmZidXp6IjogIi5zcmMudGFyLnpzdCIsCisgICAgIm1pbmd3LXc2NC1saWJ1bmlz dHJpbmciOiAiLnNyYy50YXIuenN0IiwKKyAgICAibWluZ3ctdzY0LXdpbnB0aHJlYWRzLWdpdCI6 ICIuc3JjLnRhci56c3QiLAorICAgICJtaW5ndy13NjQtY2EtY2VydGlmaWNhdGVzIjogIi5zcmMu dGFyLnpzdCIsCisgICAgIm1pbmd3LXc2NC1saWJ4bWwyIjogIi5zcmMudGFyLnpzdCIsCisgICAg Im1pbmd3LXc2NC1uY3Vyc2VzIjogIi5zcmMudGFyLnpzdCIsCisgICAgIm1pbmd3LXc2NC1vcGVu c3NsIjogIi5zcmMudGFyLnpzdCIsCisgICAgIm1pbmd3LXc2NC1wYW5nbyI6ICIuc3JjLnRhci56 c3QiLAorICAgICJtaW5ndy13NjQtcHl0aG9uIjogIi5zcmMudGFyLnpzdCIsCisgICAgIm1pbmd3 LXc2NC1zcWxpdGUzIjogIi5zcmMudGFyLnpzdCIsCisgICAgIm1pbmd3LXc2NC14cG0tbm94Ijog Ii5zcmMudGFyLnpzdCIsCisgICAgIm1pbmd3LXc2NC14eiI6ICIuc3JjLnRhci56c3QiLAorfQog CiAjIyBDdXJyZW50bHkgbm8gcGFja2FnZXMgc2VlbSB0byByZXF1aXJlIHRoaXMhCiBBUkNIX1BL R1M9W10KIFNSQ19SRVBPPSJodHRwczovL3JlcG8ubXN5czIub3JnL21pbmd3L3NvdXJjZXMiCiAK IAotZGVmIGltbWVkaWF0ZV9kZXBzKHBrZ3MpOgotICAgIHBhY2thZ2VfaW5mbyA9IGNoZWNrX291 dHB1dChbInBhY21hbiIsICItU2kiXSArIHBrZ3MpLmRlY29kZSgidXRmLTgiKS5zcGxpdGxpbmVz KCkKK2RlZiBpbW1lZGlhdGVfZGVwcyhwa2cpOgorICAgIHBhY2thZ2VfaW5mbyA9IGNoZWNrX291 dHB1dChbInBhY21hbiIsICItU2kiLCBwa2ddKS5kZWNvZGUoInV0Zi04Iikuc3BsaXQoIlxuIikK KworICAgICMjIEV4dHJhY3QgdGhlICJEZXBlbmRzIE9uIiBsaW5lCisgICAgZGVwZW5kc19vbiA9 IFt4IGZvciB4IGluIHBhY2thZ2VfaW5mbyBpZiB4LnN0YXJ0c3dpdGgoIkRlcGVuZHMgT24iKV1b MF0KKyAgICAjIyBSZW1vdmUgIkRlcGVuZHMgT24iIHByZWZpeAorICAgIGRlcGVuZGVuY2llcyA9 IGRlcGVuZHNfb24uc3BsaXQoIjoiKVsxXQogCi0gICAgIyMgRXh0cmFjdCB0aGUgcGFja2FnZXMg bGlzdGVkIGZvciAiRGVwZW5kcyBPbjoiIGxpbmVzLgotICAgIGRlcGVuZGVuY2llcyA9IFtsaW5l LnNwbGl0KCI6IilbMV0uc3BsaXQoKSBmb3IgbGluZSBpbiBwYWNrYWdlX2luZm8KLSAgICAgICAg ICAgICAgICAgICAgaWYgbGluZS5zdGFydHN3aXRoKCJEZXBlbmRzIE9uIildCi0gICAgIyMgRmxh dHRlbiBkZXBlbmRlbmN5IGxpc3RzIGZyb20gbXVsdGlwbGUgcGFja2FnZXMgaW50byBvbmUgbGlz dC4KLSAgICBkZXBlbmRlbmNpZXMgPSBmdW5jdG9vbHMucmVkdWNlKG9wZXJhdG9yLmljb25jYXQs IGRlcGVuZGVuY2llcywgW10pCisgICAgIyMgU3BsaXQgaW50byBkZXBlbmRlbmNpZXMKKyAgICBk ZXBlbmRlbmNpZXMgPSBkZXBlbmRlbmNpZXMuc3RyaXAoKS5zcGxpdCgiICIpCiAKICAgICAjIyBS ZW1vdmUgPiBzaWducyBUT0RPIGNhbiB3ZSBnZXQgYW55IG90aGVyIHB1bmN0dWF0aW9uIGhlcmU/ CiAgICAgZGVwZW5kZW5jaWVzID0gW2Quc3BsaXQoIj4iKVswXSBmb3IgZCBpbiBkZXBlbmRlbmNp ZXMgaWYgZF0KQEAgLTE0OSwxOCArMTc1LDE2IEBAIGRlZiBleHRyYWN0X2RlcHMoKToKICAgICBw cmludCggIkV4dHJhY3RpbmcgZGVwcyIgKQogCiAgICAgIyBHZXQgYSBsaXN0IG9mIGFsbCBkZXBl bmRlbmNpZXMgbmVlZGVkIGZvciBwYWNrYWdlcyBtZW50aW9uZWQgYWJvdmUuCi0gICAgcGtncyA9 IHNldChQS0dfUkVRKQotICAgIG5ld2RlcHMgPSBwa2dzCi0gICAgcHJpbnQoImFkZGluZy4uLiIp Ci0gICAgd2hpbGUgVHJ1ZToKLSAgICAgICAgc3ViZGVwcyA9IGZyb3plbnNldChpbW1lZGlhdGVf ZGVwcyhsaXN0KG5ld2RlcHMpKSkKLSAgICAgICAgbmV3ZGVwcyA9IHN1YmRlcHMgLSBTS0lQX0RF UF9QS0dTIC0gcGtncwotICAgICAgICBpZiBub3QgbmV3ZGVwczoKLSAgICAgICAgICAgIGJyZWFr Ci0gICAgICAgIHByaW50KCdcbicuam9pbihuZXdkZXBzKSkKLSAgICAgICAgcGtncyB8PSBuZXdk ZXBzCisgICAgcGtncyA9IFBLR19SRVFbOl0KKyAgICBuID0gMAorICAgIHdoaWxlIG4gPCBsZW4o cGtncyk6CisgICAgICAgIHN1YmRlcHMgPSBpbW1lZGlhdGVfZGVwcyhwa2dzW25dKQorICAgICAg ICBmb3IgcCBpbiBzdWJkZXBzOgorICAgICAgICAgICAgaWYgbm90IChwIGluIHBrZ3Mgb3IgcCBp biBTS0lQX0RFUF9QS0dTKToKKyAgICAgICAgICAgICAgICBwa2dzLmFwcGVuZChwKQorICAgICAg ICBuID0gbiArIDEKIAotICAgIHJldHVybiBsaXN0KHBrZ3MpCisgICAgcmV0dXJuIHNvcnRlZChw a2dzKQogCiAKIGRlZiBkb3dubG9hZF9zb3VyY2UodGFyYmFsbCk6CkBAIC0yMDgsNyArMjMyLDEz IEBAIGRlZiBnYXRoZXJfc291cmNlKGRlcHMpOgogICAgICAgICAjIyBTd2l0Y2ggbmFtZXMgaWYg bmVjZXNzYXJ5CiAgICAgICAgIHBrZ19uYW1lID0gTVVOR0VfU1JDX1BLR1MuZ2V0KHBrZ19uYW1l LHBrZ19uYW1lKQogCi0gICAgICAgIHRhcmJhbGwgPSAie30te30uc3JjLnRhci5neiIuZm9ybWF0 KHBrZ19uYW1lLHBrZ192ZXJzaW9uKQorICAgICAgICAjIyBzcmMgYXJjaGl2ZSBpcyB1c3VhbGx5 IGEgLnRhci5negorICAgICAgICBpZiBwa2dfbmFtZSBpbiBTUkNfRVhULmtleXMoKToKKyAgICAg ICAgICAgIHNyY19leHQgPSBTUkNfRVhUW3BrZ19uYW1lXQorICAgICAgICBlbHNlOgorICAgICAg ICAgICAgc3JjX2V4dCA9ICIuc3JjLnRhci5neiIKKworICAgICAgICB0YXJiYWxsID0gInt9LXt9 e30iLmZvcm1hdChwa2dfbmFtZSxwa2dfdmVyc2lvbixzcmNfZXh0KQogCiAgICAgICAgIGRvd25s b2FkX3NvdXJjZSh0YXJiYWxsKQogCkBAIC0yNTcsNyArMjg3LDcgQEAgZGVmIGNsZWFuKCk6CiAK IGlmKCBhcmdzLmwgKToKICAgICBwcmludCgiTGlzdCBvZiBkZXBlbmRlbmNpZXMiKQotICAgIHBy aW50KCBkZXBzICkKKyAgICBwcmludCggZXh0cmFjdF9kZXBzKCkgKQogICAgIGV4aXQoMCkKIAog aWYgYXJncy5zOgotLSAKMi40MS4wLndpbmRvd3MuMQoK --0000000000007f05ae060290e81e-- From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 10 09:28:56 2023 Received: (at 65206) by debbugs.gnu.org; 10 Aug 2023 13:28:56 +0000 Received: from localhost ([127.0.0.1]:41705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU5ii-0001Tf-9Z for submit@debbugs.gnu.org; Thu, 10 Aug 2023 09:28:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55928) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU5if-0001TS-D6 for 65206@debbugs.gnu.org; Thu, 10 Aug 2023 09:28:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qU5iW-0001ts-Vo; Thu, 10 Aug 2023 09:28:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=0UTuCkHrHvdvTi1LcvUGZMf4sKU4GRjqsUr/BN6VQAk=; b=M+Y44p8TJOI9 oevUTWa5LHRucGRYjW9wc0cs3YQ4yaCCdZyj1qVGbxI48Bqf1JDrvFNW5U/F7VtEtCQN54MZtJJho ltiNF5khOvnTrzuLENXOx/hku/5Ztis/8zVgI6asnRJkygoA5KNRo3OXgxmpAviksnviEmFrTcxZI RzxgMWS61sG4gw8k7OMXj8gVxRBI1lkZkJKFYsmQWSIlmXBh0CLI3RDgHewCHgPXcvPOgTBE5H61Z CsJFfGfMcWSThBKU/T07AK32CTBTuxriGq8HkFIGTS/7cuLSTng/wzBahaBHMJGsCsZ2XHj2pEuks pfegMPMQ4dXUzVJEp7+T2Q==; Date: Thu, 10 Aug 2023 16:29:12 +0300 Message-Id: <83msyzhvpz.fsf@gnu.org> From: Eli Zaretskii To: Corwin Brust In-Reply-To: (message from Corwin Brust on Thu, 10 Aug 2023 07:40:48 -0500) Subject: Re: bug#65206: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65206 Cc: 65206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Corwin Brust > Date: Thu, 10 Aug 2023 07:40:48 -0500 > > The script nt/admin/dist-build/build-deps-zips.py needs help. This is > the script that I use to collect and package dependencies and sources > for dependencies on Microsoft Windows, as part of releasing Emacs > binaries for Windows. It is a python script that runs under MSYS2 > MSYS console (not MinGW). > > Neither the version currently in the emacs-29 nor in the master > branches will work for the given Emacs version without changes. The > attached patch would make emacs-29 match what I am using locally. > > In addition to other changes, the patch reflects my current "transformation map" > approach to deal with MSYS source package paths change, which seems to > be happening quite a bit upstream. > > In case it may not be clear, my process is to run the script > after updating local MSYS packages that are dependencies (optional or > no), or edit and run it when Emacs' dependencies have changed. > > The patch reflects the script as I have been using it during the Emacs > 29 release process. I'm sure there's general room for improvement > (editing this script is literally my only python coding credit), I'm > opening this bug report because bug#65188 (a packaging error preventing > WEBP from working for people using the Windows binaries) has called > attention to the importance of having additional eyes on build tooling > (especially when it so far contains hard-coded lists of upstream deps). Would you mind providing an overview of the process by which the script (and maybe some additional measures) collect(s) the list of the dependency packages for the binary distro, including the main ideas and information sources? It is hard to glean all that from just a patch, or even by reading the script, and I think that, given the pains this gives, perhaps some new ideas are in order. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 10 17:09:34 2023 Received: (at 65206) by debbugs.gnu.org; 10 Aug 2023 21:09:34 +0000 Received: from localhost ([127.0.0.1]:44185 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUCuU-0001GO-0T for submit@debbugs.gnu.org; Thu, 10 Aug 2023 17:09:34 -0400 Received: from mail-ot1-f46.google.com ([209.85.210.46]:47495) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUCuS-0001G8-3O for 65206@debbugs.gnu.org; Thu, 10 Aug 2023 17:09:33 -0400 Received: by mail-ot1-f46.google.com with SMTP id 46e09a7af769-6bcbb0c40b1so1239092a34.3 for <65206@debbugs.gnu.org>; Thu, 10 Aug 2023 14:09:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691701766; x=1692306566; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=aPc0c1qMDTT86yPHrVahUz2mOV6ad7xf7LgJUajqfgo=; b=AbbvRhf+ZFPHXgtXWVwUZBo8r2g7RD3C4ycSwLhm91BlezZsyQN+zl/XEl0Q9JWsgH qwOuawRTcfVADBbJdILbMfCRs5J2qK8YNx/XSzwQbzNS3dtnXvNepRrjlSfeclezfL16 eCNmcgfnyM+zDXgisgL73W9/VPVvaKw5JIkvDBgP5/r4p319Ipyy1Ssh5HIHAl3CDvED Hx0wZFUhA/DrzDjFbxPuZZV1wT9hX8SWh7qUa4WBImS6d083+3BvOAO77kCtSk/uTHys 0tAwMSxX3tgFxgE/q+3Gf193efcjO0Lk9S2WOF+jEGjB3qi7wSDSEzMfv/p0OHVLEHpa 11/A== X-Gm-Message-State: AOJu0YyKnbu1tvlmMs3OaYtAnDPp8G6RY021lkK2RLfon6HwvgyGmB3S OC0PT/yrJ8V+eqffdHmxtBC8CQTVrx0TGXJqW18= X-Google-Smtp-Source: AGHT+IEqdNhWOOp+/1hDdw258srHuFOjkWXu5EBp12khCdfGUDw5WMK4o5pn1QVIP239rAITAH1MXG5Q1Mx3kENZ+2E= X-Received: by 2002:a9d:7551:0:b0:6ab:27b5:d202 with SMTP id b17-20020a9d7551000000b006ab27b5d202mr3201498otl.37.1691701766173; Thu, 10 Aug 2023 14:09:26 -0700 (PDT) MIME-Version: 1.0 References: <83msyzhvpz.fsf@gnu.org> In-Reply-To: <83msyzhvpz.fsf@gnu.org> From: Corwin Brust Date: Thu, 10 Aug 2023 16:09:15 -0500 Message-ID: Subject: Re: bug#65206: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 65206 Cc: 65206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On Thu, Aug 10, 2023 at 8:29=E2=80=AFAM Eli Zaretskii wrote: > > > Would you mind providing an overview of the process by which the > script (and maybe some additional measures) collect(s) the list of the > dependency packages for the binary distro, including the main ideas > and information sources? It is hard to glean all that from just a > patch, or even by reading the script, and I think that, given the > pains this gives, perhaps some new ideas are in order. I will happily try my best; sorry that it cannot be immediately/today. In any case, I completely agree with you. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 15 03:40:06 2023 Received: (at 65206) by debbugs.gnu.org; 15 Aug 2023 07:40:06 +0000 Received: from localhost ([127.0.0.1]:34940 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVoer-0002or-7h for submit@debbugs.gnu.org; Tue, 15 Aug 2023 03:40:05 -0400 Received: from mail-ot1-f41.google.com ([209.85.210.41]:58824) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVoeo-0002oE-9H for 65206@debbugs.gnu.org; Tue, 15 Aug 2023 03:40:03 -0400 Received: by mail-ot1-f41.google.com with SMTP id 46e09a7af769-6bcf2fd5d69so4654296a34.1 for <65206@debbugs.gnu.org>; Tue, 15 Aug 2023 00:40:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692085196; x=1692689996; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vA0W9Sd9ah3CjlPd3yh/p1V2jlei0VMHVgbY1hTrQWM=; b=dBNXdZCp4E0E44dAd1Zy0MFEY03HupibU1ZwJ+whMG6DG2/uyb0t/dzHEVZk/e7LdY FAw3kssyKJnx19CfYknjQGheHvX/Iy8sFRn7zmSkvL7vveFN5DVWFttKZmSsgx86AbrY /jRY8Xy5IWA8gux9NEDw0sRqt+XT6Tuzsckj4JdWbJvSPAgw0Jf7Apu5CwGQ2eaZasy1 tFyI3G5UQC196/QcYlZCtdZCVI1+/2HDXPC1oTgZ3Mw6uhuATpsfP1htiIyxOEiJeuG+ +WoZ2XAQpfijTMIyIRxsySEfWVBPA2KUJLoIJggWoGZcnZhIcX/j1wfhflkXx5HAP9bQ LN/w== X-Gm-Message-State: AOJu0Ywkj/An3L1Y9tUTFWfzscV4RuRsAW+hR5J+DOJtQM3NMUPLVC4f K8KPJf71en9GEZfpBFfLdf17O4DXDQKuWHjI57o= X-Google-Smtp-Source: AGHT+IH7BJUo1E2WgJSAyqYc9b0D1GHjtI7ntCK0jzZ5+Do+mSQwYxAoauAJhRHxbsqJTtJ7yItDgB0p+hAdOJYRtSc= X-Received: by 2002:a9d:6c9a:0:b0:6b9:6663:4648 with SMTP id c26-20020a9d6c9a000000b006b966634648mr10177585otr.3.1692085196530; Tue, 15 Aug 2023 00:39:56 -0700 (PDT) MIME-Version: 1.0 References: <83msyzhvpz.fsf@gnu.org> In-Reply-To: <83msyzhvpz.fsf@gnu.org> From: Corwin Brust Date: Tue, 15 Aug 2023 02:39:45 -0500 Message-ID: Subject: Re: bug#65206: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 65206 Cc: 65206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On Thu, Aug 10, 2023 at 8:29=E2=80=AFAM Eli Zaretskii wrote: > > [Provide] an overview of the process by which nt/admin/dist-build/build-dep-zips.py - it's really just that, as far as how I collect the deps presently To be clear, by "deps", I'm referring to DLLs that are not built with Emacs but which we should (optionally) include when distributing binary versions of Emacs for Windows. Similarly pedantically, here are the files I (might) include for a given release of Windows binaries for Emacs: FULL ZIP: emacs-${VER}.zip - the "full zip", includes the deps DLLs this script packages NO DEPS ZIP: emacs-${VER}-no-deps.zip - specifically without the deps DLLs this script packages INSTALLER EXE: emacs-${VERION}-installer.exe - a self-installer including the deps DLLs (and it compresses stuff even more than zip -9. nice) DEPS ZIP: emacs-${MAJOR_VERSION}-${DEPS_CREATE_DATE_IF_NOT_FIRST_AND_ONLY_F= OR_MAJOR_VERSION}.zip - contains only the deps DLLs. Created when changes are needed, more to come on this. DEPS SOURCES ZIP: the MSYS2/MINGW64 source code for all DLLs in DEPS ZIP. Created only when a new DEPS ZIP is created Finally (I swear, I'm going to answer your actual question), to place the script in context of my present "use-case" (release and release-similar builds specifically, here): 0. PREREQ: I have various folders setup, a working MSYS/MINGW64 that has recently built me a working Emacs, I've been watching mailing lists, I have ACLs going for me, etc. 1. A (pre)release tarball is pushed to GNU (alpha) FTP. 2. Skip this step if a "last good" deps and deps source file exist and it is current (i.e. when there are not known new or updated --including optional-- dependendencies for Emacs to include for the first time), Otherwise, update and run the script (more on this below, obviously) in question to create (new) deps and deps source archives containing, respectively, a bunch of DLLs we plan to distribute (nominally) with Emacs (this is the deps archive), and the MSYS2/MINGW64 sources for these DLLs and their compile time dependencies (the deps sources archive). 3. Download and unpack the tarball manually 4. Configure && make install to ${PREFIX}. Note, I have a tedious pipeline command I like for this; I'm not currently using "build-zips.sh" from the same folder as the build-dep-zips.sh script in question. 5. Create a no-deps archive, essentially: zip -r9 ${PREFIX} emacs-${TARGET_VERSION_NAME}-no-deps.zip 6. Unpack the deps archive created in step #2 (or the "last good", if that step was skipped), something like: unzip -d ${PREFIX}/bin ${LAST_GOOD_DEPS_ZIP_FOR_EMACS_MAJOR_VERSION} 7. Create a "full" zip of Emacs (now including those "extra" DLLs), essentially repeating step #5 with a different archive file name (in fact, I copy no-deps and re-add bin to it) 8. Create the installer 9. Perform certain rights and incantations to cause files to appear on GNU (alpha) FTP servers. Notably, include new deps files ONLY when they have been newly created along with the release being published. These files have historically changed only rarely within a given Emacs major version. > collect(s) the list of the dependency packages for the binary distro, Ignoring my patch for the moment, the script contains two hard-coded lists that represent our first likely source of breakage: DLL_REQ lists specific DLLs that should be copied into ${PREFIX}/bin, after make install, to get a "complete" Emacs installation. During the Emacs 29 pre-release cycle I added sqlite3 and tree-sitter to this list, enabling those features to work "out of the box". In some cases, such as these two in fact, Emacs would likely function correctly under Windows if we chose not to distribute a particular DLL; however, I believe this is not the case for all of DLLs included and, moreover (in my opinion) would tend to make Emacs to less viable as a means of drawing Windows users closer to Free Software by virtue of Just Being Better, which would be a bit sad. PKG_REQ lists the mingw-w64-x86_64 source package name for each item in the first list. These two variables are coordinated lists and so obviously could be refactored (e.g. into an associative array) that I suspect historical raisins (meaning, perhaps once these lists were not so coordinated; I didn't research this so far). In addition to these "main lists" there are a few other vars/lines to study (now taking from my patched version): SKIP_SRC_PKGS=3D["mingw-w64-gcc-libs"] SKIP_DEP_PKGS=3D["mingw-w64-glib2" "mingw-w64-ca-certificates-20211016-3"] We'll come to the logic -where all of these are used-- next. > including the main ideas and information sources[. ...] Ignoring as much complexity as possible by focusing on the release(like) use-case, we can ignore the arguments and conditions and, finally, we can reduce the the script to: 2.1 evaluate above mentioned vars 2.2 collect all DLLs mentioned in DLL_REQ 2.3 collect the DLLs that are unique dependencies the DLLs collected in 2.2 skipping any which appear in SKIP_DEP_PKGS 2.4 collect the source for all DLLs from 2.2 and 2.3 unless the source package is listed in SKIP_SRC_PKGS I hope I did cover information sources well enough, but to put a fine point on it: I watch Emacs devel, bug reports, IRC, reddit, ..., for information leading to updates to this script. Developers and others using Emacs on Windows are the main "information sources", at least speaking from developing that patch :) > > Thanks. > From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 15 11:43:52 2023 Received: (at 65206) by debbugs.gnu.org; 15 Aug 2023 15:43:53 +0000 Received: from localhost ([127.0.0.1]:36514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVwD2-00018D-E2 for submit@debbugs.gnu.org; Tue, 15 Aug 2023 11:43:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49990) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVwD0-00017z-07 for 65206@debbugs.gnu.org; Tue, 15 Aug 2023 11:43:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qVwCs-0000lq-Ru; Tue, 15 Aug 2023 11:43:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=/sGqzSX6Ku0HJgfnyXSuLglkPWRubr+LhDwdDYLyCqY=; b=DduEROPcTqsV eg3HAHFH02dPB/gtVAofsrNf/9UpsrX+8oOSAugMD3QsDl1524JQZjrus1bi3Cvq3imPsL4qm53Lg 7kDqVO5UfAlFz7rAEEZND+UDGmfnJl1K2azlEVrTC4dYMW7HcrqziVAd1gHNoafYHXZ46AlRUj2qW mhWhjZGyx/VGy09C9TRPyoz7CKY1/2f07MObximUOtyku2UUOVhUIT2UhkXnv4UxKM40fblDuOo0F dWbs9jg3exxmw73jcrXOEoh31ho0EiAreaInahxYbVQCM1l5jwEqzB5A6iSPyvwQFIvz4d4jcpa6o 6ESAma6BHylxFcV96RP6Tw==; Date: Tue, 15 Aug 2023 18:43:45 +0300 Message-Id: <837cpw9uq6.fsf@gnu.org> From: Eli Zaretskii To: Corwin Brust In-Reply-To: (message from Corwin Brust on Tue, 15 Aug 2023 02:39:45 -0500) Subject: Re: bug#65206: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain References: <83msyzhvpz.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65206 Cc: 65206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Corwin Brust > Date: Tue, 15 Aug 2023 02:39:45 -0500 > Cc: 65206@debbugs.gnu.org > > 5. Create a no-deps archive, essentially: > > zip -r9 ${PREFIX} emacs-${TARGET_VERSION_NAME}-no-deps.zip > > 6. Unpack the deps archive created in step #2 (or the "last good", if > that step was skipped), something like: > > unzip -d ${PREFIX}/bin ${LAST_GOOD_DEPS_ZIP_FOR_EMACS_MAJOR_VERSION} > > 7. Create a "full" zip of Emacs (now including those "extra" DLLs), > essentially repeating step #5 with a different archive file name (in > fact, I copy no-deps and re-add bin to it) > > 8. Create the installer > > 9. Perform certain rights and incantations to cause files to appear on > GNU (alpha) FTP servers. Notably, include new deps files ONLY when > they have been newly created along with the release being published. > These files have historically changed only rarely within a given Emacs > major version. > > > collect(s) the list of the dependency packages for the binary distro, > > Ignoring my patch for the moment, the script contains two hard-coded > lists that represent our first likely source of breakage: > > DLL_REQ lists specific DLLs that should be copied into ${PREFIX}/bin, > after make install, to get a "complete" Emacs installation. During > the Emacs 29 pre-release cycle I added sqlite3 and tree-sitter to this > list, enabling those features to work "out of the box". In some > cases, such as these two in fact, Emacs would likely function > correctly under Windows if we chose not to distribute a particular > DLL; however, I believe this is not the case for all of DLLs included > and, moreover (in my opinion) would tend to make Emacs to less viable > as a means of drawing Windows users closer to Free Software by virtue > of Just Being Better, which would be a bit sad. > > PKG_REQ lists the mingw-w64-x86_64 source package name for each item > in the first list. > > These two variables are coordinated lists and so obviously could be > refactored (e.g. into an associative array) that I suspect historical > raisins (meaning, perhaps once these lists were not so coordinated; I > didn't research this so far). > > In addition to these "main lists" there are a few other vars/lines to > study (now taking from my patched version): > > SKIP_SRC_PKGS=["mingw-w64-gcc-libs"] > SKIP_DEP_PKGS=["mingw-w64-glib2" "mingw-w64-ca-certificates-20211016-3"] > > We'll come to the logic -where all of these are used-- next. > > > including the main ideas and information sources[. ...] > > Ignoring as much complexity as possible by focusing on the > release(like) use-case, we can ignore the arguments and conditions > and, finally, we can reduce the the script to: > > 2.1 evaluate above mentioned vars > 2.2 collect all DLLs mentioned in DLL_REQ > 2.3 collect the DLLs that are unique dependencies the DLLs collected > in 2.2 skipping any which appear in SKIP_DEP_PKGS > 2.4 collect the source for all DLLs from 2.2 and 2.3 unless the source > package is listed in SKIP_SRC_PKGS > > I hope I did cover information sources well enough, but to put a fine > point on it: I watch Emacs devel, bug reports, IRC, reddit, ..., for > information leading to updates to this script. Developers and others > using Emacs on Windows are the main "information sources", at least > speaking from developing that patch :) Thanks. What I still don't think I understand is how do you make sure you have a full list of first-order dependencies? I understand that you mostly build on the "last good" list from previous release, but since the list grows from time to time, what is the procedure for finding the new dependencies, adding them to the list, and making sure they all are there? I'm asking because this is exactly where the procedure broke down when we added WebP image support in Emacs 29. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 15 11:54:15 2023 Received: (at 65206) by debbugs.gnu.org; 15 Aug 2023 15:54:15 +0000 Received: from localhost ([127.0.0.1]:36535 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVwN4-0001TY-MD for submit@debbugs.gnu.org; Tue, 15 Aug 2023 11:54:15 -0400 Received: from mail-ot1-f44.google.com ([209.85.210.44]:62910) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVwN1-0001TH-OS for 65206@debbugs.gnu.org; Tue, 15 Aug 2023 11:54:13 -0400 Received: by mail-ot1-f44.google.com with SMTP id 46e09a7af769-6bd06470b68so3864169a34.1 for <65206@debbugs.gnu.org>; Tue, 15 Aug 2023 08:54:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692114846; x=1692719646; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=53YjDZYkn6+sey0jNO2m/0aR0/Czr7zXeKTefma7DEw=; b=JAt3stdRHBMuBib3wHcpPeTqNDtR4IfweHgcyrsERzeKfcP1R2tpZyZcGiq9TH7tO5 lBw6TGFgyJqPOpwOgolSaCiEFbeU6QZlQRnNmaLf5xXPrWnnPUkYWRz/zZKTz5cemUfC 2uRYQ0/k22rP32uaZzXE5+mDSL1UEUGf9XT4z0xfj5h+ag+ilhDsfOgiNWQtAQQe8N3V R170dZeys/S/Td9uwB4LmNpmsEzQvOzBXFQAivZdiTzgJNA39vzlk9buWKdB2rdPPWxR Qu9dLgN+vaCo7P6lxgN/kDXwQESiaA6j4kB8bgbQhiedg8ww+ofZqbWOn6IRYPfjPmCE 5SCw== X-Gm-Message-State: AOJu0YzT8gILVrHK/5Jl0jrcsI9ipnR6WLqGTMRYU4zK45cZDHc9OKcS Wk769Muh/QbHn3fucwGkGb4GhOnvtgOAZEEBXgQ= X-Google-Smtp-Source: AGHT+IE+pZH19Kb4zBDUKK4mp55CyWjfP64/jCEjfnsSr0NCxq+9BZ9eXrj9FOxi8onxB3ax8FvLngItoHqJkF2Oqxw= X-Received: by 2002:a9d:6c07:0:b0:6bc:cde2:3038 with SMTP id f7-20020a9d6c07000000b006bccde23038mr1747321otq.11.1692114845946; Tue, 15 Aug 2023 08:54:05 -0700 (PDT) MIME-Version: 1.0 References: <83msyzhvpz.fsf@gnu.org> <837cpw9uq6.fsf@gnu.org> In-Reply-To: <837cpw9uq6.fsf@gnu.org> From: Corwin Brust Date: Tue, 15 Aug 2023 10:53:55 -0500 Message-ID: Subject: Re: bug#65206: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 65206 Cc: 65206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On Tue, Aug 15, 2023 at 10:43=E2=80=AFAM Eli Zaretskii wrote= : > > > From: Corwin Brust > > > > I hope I did cover information sources well enough, but to put a fine > > point on it: I watch Emacs devel, bug reports, IRC, reddit, ..., for > > information leading to updates to this script. Developers and others > > using Emacs on Windows are the main "information sources", at least > > speaking from developing that patch :) > > Thanks. What I still don't think I understand is how do you make sure > you have a full list of first-order dependencies? I understand that > you mostly build on the "last good" list from previous release, but > since the list grows from time to time, what is the procedure for > finding the new dependencies, adding them to the list, and making sure > they all are there? > > I'm asking because this is exactly where the procedure broke down when > we added WebP image support in Emacs 29. The above quote from myself I retained is my best/only answer: I update the script as issues are reported or when I somehow otherwise learn that changes are needed. I have no real process for this, and nothing in the tooling is helping me with it, so far. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 15 12:02:02 2023 Received: (at 65206) by debbugs.gnu.org; 15 Aug 2023 16:02:02 +0000 Received: from localhost ([127.0.0.1]:36540 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVwUb-0001fd-Ng for submit@debbugs.gnu.org; Tue, 15 Aug 2023 12:02:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33832) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVwUW-0001fH-MB for 65206@debbugs.gnu.org; Tue, 15 Aug 2023 12:02:00 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qVwUR-0004h3-4W; Tue, 15 Aug 2023 12:01:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=QuGWuOQj72bVRXO3SyG4cEJNk0xazMrx0fc7bJvdpQ4=; b=Vbb2Op66pK+P ZImPfFAx/sekqr/c5aO6JuQ8RU4KPD/UAP/yIxNO7YKk7JVszDn7JDOtYa8Bfp3Q+TvTpSoGb4+Q6 N6ZEn8ty6Zx2zMCDJ1Cap3XR3P/74L6PmmrJY3zaAbDasGEmfOgkINU4LV+zuwC+z1C0qc1QL2deT YGrgvbs8oxv8mQEMiR01hgTbFJvkGWEyNF2P0aL4ZaT6Uz69CucaD/OoofWxqLx1XpCmeL4OTCAr4 46liNA7yH38EdjVHelx8zguSkSqi4cjjPPnL4M8VOYgCOfy/xLMnrmBf3RmgbMePrJhohd8qgE/oL FVnQojlOmiM4zPdyyXaD6A==; Date: Tue, 15 Aug 2023 19:01:53 +0300 Message-Id: <834jl09tvy.fsf@gnu.org> From: Eli Zaretskii To: Corwin Brust In-Reply-To: (message from Corwin Brust on Tue, 15 Aug 2023 10:53:55 -0500) Subject: Re: bug#65206: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain References: <83msyzhvpz.fsf@gnu.org> <837cpw9uq6.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65206 Cc: 65206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Corwin Brust > Date: Tue, 15 Aug 2023 10:53:55 -0500 > Cc: 65206@debbugs.gnu.org > > > Thanks. What I still don't think I understand is how do you make sure > > you have a full list of first-order dependencies? I understand that > > you mostly build on the "last good" list from previous release, but > > since the list grows from time to time, what is the procedure for > > finding the new dependencies, adding them to the list, and making sure > > they all are there? > > > > I'm asking because this is exactly where the procedure broke down when > > we added WebP image support in Emacs 29. > > The above quote from myself I retained is my best/only answer: > > I update the script as issues are reported or when I somehow otherwise > learn that changes are needed. I have no real process for this, and > nothing in the tooling is helping me with it, so far. OK, so here's a suggestion which might improve that crucial part: scan the list in dynamic-library-alist, on lisp/term/w32-win.el. Every dependency that is loaded dynamically (i.e., Emacs is not linked against it when it is built) must be in that list. So when we add dependencies, we add them there. I believe that given a full and complete lest of first-order dependencies, those which Emacs actually loads, all the higher-order dependencies can be found by following the MSYS2 pacman etc., is that right? From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 15 21:24:04 2023 Received: (at 65206) by debbugs.gnu.org; 16 Aug 2023 01:24:04 +0000 Received: from localhost ([127.0.0.1]:38388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qW5GV-0001UL-My for submit@debbugs.gnu.org; Tue, 15 Aug 2023 21:24:04 -0400 Received: from mail-ot1-f52.google.com ([209.85.210.52]:61870) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qW5GS-0001Tl-ST for 65206@debbugs.gnu.org; Tue, 15 Aug 2023 21:24:02 -0400 Received: by mail-ot1-f52.google.com with SMTP id 46e09a7af769-6b9cf1997c4so5033819a34.3 for <65206@debbugs.gnu.org>; Tue, 15 Aug 2023 18:24:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692149035; x=1692753835; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Wog7t8R3yygqrGXiubVy3KgYuW7TiWoAr+GNTcxFR9I=; b=IdIK3ekYDEXa5uTYtHaa3cE4abMYdPxTcj9iKfBrMDT5UI6cm8RefdsXQTRJ07sIZ3 zeT/65/5X2MXibhUnOf03jj9rLzNK3bzwef2T0aXnbvYV19WgJ6IFWTiXIS3/lhs2DIE F3rQTfdJRgr+OQ8XL+lOvNOYv5H0Y8EYy9xw+YdrKS3LeuxCBPv0mEW1L11yKg7r9VH9 4VBPOqHkbsz1fEnd4du4zN7MOulmymxeEv2JGw+HqdZueNV+CXOZDI2VFLY6T/idtrV0 lANW7dbeedA17jg0HcG01NVM6Rb4q360Iht1ZyV+59IfMpYkrXaTZ+FTYtqjXDjl++TQ ymHw== X-Gm-Message-State: AOJu0YxZ3+7D/U8ZwAK+IXq8eaBzD8+o0695FOk0INw53l0EcrvmMITb Jzo6CfYPdX2G5w988t5q0ciY2xI/ClEb2txIc6NDiOxD58Q= X-Google-Smtp-Source: AGHT+IGvCe75tGWUGiIh1y5/rknQaVUhVlYHKkWl75RJLA29VSIuZA3zOamLA4829GCijj83F/tZ/cVAeRELKwTY5NA= X-Received: by 2002:a9d:6c9a:0:b0:6b9:68fb:5b73 with SMTP id c26-20020a9d6c9a000000b006b968fb5b73mr424213otr.1.1692149035284; Tue, 15 Aug 2023 18:23:55 -0700 (PDT) MIME-Version: 1.0 References: <83msyzhvpz.fsf@gnu.org> <837cpw9uq6.fsf@gnu.org> <834jl09tvy.fsf@gnu.org> In-Reply-To: <834jl09tvy.fsf@gnu.org> From: Corwin Brust Date: Tue, 15 Aug 2023 20:23:44 -0500 Message-ID: Subject: Re: bug#65206: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 65206 Cc: 65206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On Tue, Aug 15, 2023 at 11:01=E2=80=AFAM Eli Zaretskii wrote= : > > > > > I update the script as issues are reported or when I somehow otherwise > > learn that changes are needed. I have no real process for this, and > > nothing in the tooling is helping me with it, so far. > > OK, so here's a suggestion which might improve that crucial part: scan > the list in dynamic-library-alist, on lisp/term/w32-win.el. Every > dependency that is loaded dynamically (i.e., Emacs is not linked > against it when it is built) must be in that list. So when we add > dependencies, we add them there. I looked at the variable. OT1H, it serves a very different use-case ("what are valid DLL names for a given library?" in the run-time, vs "what DLLs should be sent along with Emacs?" in the build-time). This means that meaningful hackery would likely be needed to contemplate removing the hard-coded list completely, or even that we would not be able to device any means of parsing this and choosing the correct sent among DLLs present on the build system, to include. OTOH, and more directly to the point of this bug report: > > I believe that given a full and complete lest of first-order > dependencies, those which Emacs actually loads, all the higher-order > dependencies can be found by following the MSYS2 pacman etc., is that > right? > Right, that is how the script presently works: package_info =3D check_output(["pacman", "-Si", pkg]).decode("utf-8").split("\n") Thus, if we are content to have the script detect, and error demanding correction when out of sync wrt `dynamic-library-alist', I believe it can be done. Moreover, IMO this will definitely help. One process note is that I would likely switch to (maybe) generating new DEPS right after creating NO DEPS, so the script can count on invoking the freshly compiled and locally installed Emacs. This also seems much easier and also more proper vs anything to parse it "the hard way". (Especially so, considering complexities such as format strings and the libpng version comment on the source setting up the default value of dynamic-module-alist.) Does a "invokes Emacs now and errors out if stuff is missing" approach sound right/good? Is it too soon for me to try making a new patch that explores this idea fur= ther? From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 08:08:46 2023 Received: (at 65206) by debbugs.gnu.org; 16 Aug 2023 12:08:46 +0000 Received: from localhost ([127.0.0.1]:39005 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWFKP-00059R-R8 for submit@debbugs.gnu.org; Wed, 16 Aug 2023 08:08:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45382) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWFKN-000599-U9 for 65206@debbugs.gnu.org; Wed, 16 Aug 2023 08:08:45 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qWFKI-0001ON-Hl; Wed, 16 Aug 2023 08:08:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=JSK8payd4uDf1J8IfIpDpJwro18743Gn3cB71SLQzrg=; b=qBUikWceDWAKW7sQXrJp OteeOsUMHf1/WU93kphI1+s/zdvDdgzMtrUx5ufMOPNqBM14/67Kf8ztlMqkJbRSFkVwCnGjEFLfx cPnwP7ZkiebXrkFQcM7QNVWemhwByDkgITF/4718hXYVk8IGzM2u4PnJm5/vZnQvJ2j06XDQs6F5T p0Js9fJFlfMPN19tit7I/QrIO56KF1v1e7vfjnmOxWRVhkHvDI10VgX1f+qHOL1JjGa7CGmy7n69Z IgSNPKC932R6eXnV69AlYG1wo1UlRvq1rEgS3d/aHRSrvmqLHNReS1FctQ29FJXZrCAaoRiAswUH+ DoF2BbaREHrXlg==; Date: Wed, 16 Aug 2023 15:08:44 +0300 Message-Id: <83leeb8a0j.fsf@gnu.org> From: Eli Zaretskii To: Corwin Brust In-Reply-To: (message from Corwin Brust on Tue, 15 Aug 2023 20:23:44 -0500) Subject: Re: bug#65206: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain References: <83msyzhvpz.fsf@gnu.org> <837cpw9uq6.fsf@gnu.org> <834jl09tvy.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65206 Cc: 65206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Corwin Brust > Date: Tue, 15 Aug 2023 20:23:44 -0500 > Cc: 65206@debbugs.gnu.org > > On Tue, Aug 15, 2023 at 11:01 AM Eli Zaretskii wrote: > > > > OK, so here's a suggestion which might improve that crucial part: scan > > the list in dynamic-library-alist, on lisp/term/w32-win.el. Every > > dependency that is loaded dynamically (i.e., Emacs is not linked > > against it when it is built) must be in that list. So when we add > > dependencies, we add them there. > > I looked at the variable. OT1H, it serves a very different use-case > ("what are valid DLL names for a given library?" in the run-time, vs > "what DLLs should be sent along with Emacs?" in the build-time). > This means that meaningful hackery would likely be needed to > contemplate removing the hard-coded list completely, or even that we > would not be able to device any means of parsing this and choosing the > correct sent among DLLs present on the build system, to include. I'm not sure I understand the reservation. That list mentions every single DLL that we know can be used for each optional feature. If a feature has more than one DLL listed, the first one is usually the most popular, and should be tried first. Given this, what problems do you envision with using that list? > Thus, if we are content to have the script detect, and error demanding > correction when out of sync wrt `dynamic-library-alist', I believe it > can be done. Moreover, IMO this will definitely help. Great, that's what I hoped to achieve: a way of verifying that your list of first-order dependencies is complete. > Does a "invokes Emacs now and errors out if stuff is missing" approach > sound right/good? I'm not sure I understand how would you force Emacs to "error out" when we are talking about optional dependencies. They are optional so that Emacs could run even if they are not present. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 09:41:49 2023 Received: (at 65206) by debbugs.gnu.org; 16 Aug 2023 13:41:49 +0000 Received: from localhost ([127.0.0.1]:39562 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWGmS-0002Pj-Dd for submit@debbugs.gnu.org; Wed, 16 Aug 2023 09:41:49 -0400 Received: from mail-oo1-f50.google.com ([209.85.161.50]:55591) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWGmL-0002PG-Rj for 65206@debbugs.gnu.org; Wed, 16 Aug 2023 09:41:43 -0400 Received: by mail-oo1-f50.google.com with SMTP id 006d021491bc7-56dd683e9b3so3401907eaf.3 for <65206@debbugs.gnu.org>; Wed, 16 Aug 2023 06:41:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692193296; x=1692798096; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0BszWpAlRj9oYE/QC2GJHksLNh6+NRFwQJgrYHgcaEE=; b=b5pf/Ej7e5+2zBHCV0D7ioFlFXgppaZdGCsclmNNgIzN/GVGIvg9JRMryVuTPrdFBd Cv3Lzb1aM2kNxkHXur5QZ3BT947BOyCfvXzmVd1QEP4o11XnLB6rxSBQjJvpTklkV5Pe ke01DbpZ6U6gt1t+zpJS72W3ANetawBcUvUyAX2ghSwOH1riLrPbRxOvJA9LdeEjVtjq MlCqy+q0XkseJwKT0zI/HKLJKOSwuS94VK5Xy6w1inPvf2oagimgBiFvzSj2jP5fyZpJ tF02Nm6ewkju33g9McLbbsqEYwekEk6db7e7EBQQ10k3JVY7olgNKUjFfpgqmzAac03m yuOA== X-Gm-Message-State: AOJu0YzKWq4oDKXiOyPch2e48b7rk67h7sOH3aaPlOSS3CaU+x+QTvf6 IxcrEXpeVqRRMOTk4GNUpFJEgXmIXIOmK2GTuYE= X-Google-Smtp-Source: AGHT+IGIMEGmwVRQr7BR43SMk43fWhoxKbe2Y+ITvksfGsoCwez34EE4HkRN7wnU9OT13zrBwQYB3F//lL+h6W1Bd18= X-Received: by 2002:a05:6870:a194:b0:1bf:11f1:4729 with SMTP id a20-20020a056870a19400b001bf11f14729mr2002839oaf.56.1692193296151; Wed, 16 Aug 2023 06:41:36 -0700 (PDT) MIME-Version: 1.0 References: <83msyzhvpz.fsf@gnu.org> <837cpw9uq6.fsf@gnu.org> <834jl09tvy.fsf@gnu.org> <83leeb8a0j.fsf@gnu.org> In-Reply-To: <83leeb8a0j.fsf@gnu.org> From: Corwin Brust Date: Wed, 16 Aug 2023 08:41:25 -0500 Message-ID: Subject: Re: bug#65206: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 65206 Cc: 65206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On Wed, Aug 16, 2023 at 7:08=E2=80=AFAM Eli Zaretskii wrote: > > > From: Corwin Brust > > Date: Tue, 15 Aug 2023 20:23:44 -0500 > > Cc: 65206@debbugs.gnu.org > > > > On Tue, Aug 15, 2023 at 11:01=E2=80=AFAM Eli Zaretskii w= rote: > > > > > > the list in dynamic-library-alist, on lisp/term/w32-win.el. > > I'm not sure I understand the reservation. That list mentions every > single DLL that we know can be used for each optional feature. If a > feature has more than one DLL listed, the first one is usually the > most popular, and should be tried first. This solves my worry completely, or nearly so. To confirm: when walking the list, I will want to take the first DLL mentioned that actually exists for each entry. Is that right? > Given this, what problems do you envision with using that list? There might not be a problem (except the one we are trying to fix). The alist contains 22 entries, while var DLL_REQ contains 14 entries. The five on the alist but on mentioned in the script (so far) are: gdiplus shlwapi gobject gio webpdemux - this is pretty obviously a miss in the script; it does get however because it's required by webp which is listed in DLL_REQ Are all of these errors with the script (so, the corresponding DLLs should be included)? If not, I think we will need a way for the script to know which alist entries to skip/ignore. > > Does a "invokes Emacs now and errors out if stuff is missing" approach > > sound right/good? > > I'm not sure I understand how would you force Emacs to "error out" > when we are talking about optional dependencies. They are optional so > that Emacs could run even if they are not present. > Oops, badly said: I mean that my build and packaging process should stop and report an error if it cannot create a "complete" DEPS ZIP. Nothing affecting the Emacs run-time. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 10:49:34 2023 Received: (at 65206) by debbugs.gnu.org; 16 Aug 2023 14:49:34 +0000 Received: from localhost ([127.0.0.1]:41824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWHq1-0007Wl-M7 for submit@debbugs.gnu.org; Wed, 16 Aug 2023 10:49:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34880) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWHpz-0007WY-Sj for 65206@debbugs.gnu.org; Wed, 16 Aug 2023 10:49:32 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qWHpu-0000af-Ho; Wed, 16 Aug 2023 10:49:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=R6RhRz2o801EOMAyLl+N/eWaZJfoOgMP/o+q0ub3vGc=; b=jdz4OuOP801hsNIGcqSv Lyt9yCHidmFAkvLaANED1TLn+T2/clCvbhVZ2ARDuV/+YtrjmDF0HwAtpblh20x39JQnDWIitl3w2 71ZzjwdV3TjT6e3X0p2sB+FWasmQFgamU+/2/mHs/2yUaFNapgOucPZYOzDxV6Ha5SCO52ZdgSt+F J8kgzGpQnrkvtjDEisN0ywl++eRbfx0xVIPJKvwzy1tgRXD5y6cK5CPYMD5vZ31/TGSDIwBeEBsTf nclUamEGSJ+/OjK6mBmgAIRbfNLoobyUBCBYMWEx3GTYVpmNH4lCLRks/mMovNBbCQSOCewN1kPvM q/sTx2CCs5b7Vg==; Date: Wed, 16 Aug 2023 17:49:28 +0300 Message-Id: <834jkz82kn.fsf@gnu.org> From: Eli Zaretskii To: Corwin Brust In-Reply-To: (message from Corwin Brust on Wed, 16 Aug 2023 08:41:25 -0500) Subject: Re: bug#65206: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain References: <83msyzhvpz.fsf@gnu.org> <837cpw9uq6.fsf@gnu.org> <834jl09tvy.fsf@gnu.org> <83leeb8a0j.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65206 Cc: 65206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Corwin Brust > Date: Wed, 16 Aug 2023 08:41:25 -0500 > Cc: 65206@debbugs.gnu.org > > On Wed, Aug 16, 2023 at 7:08 AM Eli Zaretskii wrote: > > > > I'm not sure I understand the reservation. That list mentions every > > single DLL that we know can be used for each optional feature. If a > > feature has more than one DLL listed, the first one is usually the > > most popular, and should be tried first. > > This solves my worry completely, or nearly so. > > To confirm: when walking the list, I will want to take the first DLL > mentioned that actually exists for each entry. Is that right? Yes. > There might not be a problem (except the one we are trying to fix). > The alist contains 22 entries, while var DLL_REQ contains 14 entries. > The five on the alist but on mentioned in the script (so far) are: > > gdiplus > shlwapi You can ignore those: they are for Windows 9X, and they are system DLLs. > gobject > gio These are needed for librsvg. You might get away with them because librsvg pulls them in as second-order dependencies. > webpdemux - this is pretty obviously a miss in the script; it does get > however because it's required by webp which is listed in DLL_REQ Yes, this is required by libwebp, since some of the library functions are in lobwebpdemux. > Are all of these errors with the script (so, the corresponding DLLs > should be included)? If not, I think we will need a way for the > script to know which alist entries to skip/ignore. You should only skip the first two, which are Windows system DLLs. > > > Does a "invokes Emacs now and errors out if stuff is missing" approach > > > sound right/good? > > > > I'm not sure I understand how would you force Emacs to "error out" > > when we are talking about optional dependencies. They are optional so > > that Emacs could run even if they are not present. > > > > Oops, badly said: I mean that my build and packaging process should > stop and report an error if it cannot create a "complete" DEPS ZIP. > Nothing affecting the Emacs run-time. OK. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 17 03:25:47 2023 Received: (at 65206) by debbugs.gnu.org; 17 Aug 2023 07:25:47 +0000 Received: from localhost ([127.0.0.1]:42692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWXO6-0005HS-UI for submit@debbugs.gnu.org; Thu, 17 Aug 2023 03:25:47 -0400 Received: from mail-ot1-f42.google.com ([209.85.210.42]:55297) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWXO4-0005HF-E3 for 65206@debbugs.gnu.org; Thu, 17 Aug 2023 03:25:45 -0400 Received: by mail-ot1-f42.google.com with SMTP id 46e09a7af769-6bd066b0fd4so5120663a34.2 for <65206@debbugs.gnu.org>; Thu, 17 Aug 2023 00:25:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692257138; x=1692861938; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=j4c0QCVngaTHDsiEmGcZIddvMVz+6yBLRQEns1F9h5I=; b=HaW0WWBlnaJ+Ko0KnACARtob9Y1Fec/aEQ6FybSZb4B0xzt2OE27YVLxgsTEDFaZrD H7B5HsTVBoVHIpX2mnixnazi42DPcNEz38/3jdDfjEupzhgyIkL60WS14+EFEXRvtWvt WqhkXdzLrEXBfhXCWWuhcL8aMo7PE2ldhbO387SkvcgD0paiBKpoCioflxv5KHXIp7Ph CFFbWHMe7PumGlCVjguvt6bcZYLU3J7og96S732WLKgAB3UYUu7noS14GGjt340Uo2VH +bEPacdBnnqy0zwOciwBiobJDb8cB+eGcPoxyqjJK1dUeNJ97CM0SDDF2GYIXOQmuR17 1HYw== X-Gm-Message-State: AOJu0YwUuA5FsJoEv8SildPAedsvEnCfIwcns+a4kjKnzehSOec6UlkH kc1ZXm8BpYX2FJOrV9yBtsDxjQi8rmheM2nBCB8= X-Google-Smtp-Source: AGHT+IGt1JbTvRommuQDf+L72D6jr5+9a6LrsZchgzMA1BD74TZjNUhPb/VjwV9i/8QcjQU8YRZV4oy5DDFBiRIJlk8= X-Received: by 2002:a05:6830:18b:b0:6b9:c5b5:6a96 with SMTP id q11-20020a056830018b00b006b9c5b56a96mr3884551ota.6.1692257138470; Thu, 17 Aug 2023 00:25:38 -0700 (PDT) MIME-Version: 1.0 References: <83msyzhvpz.fsf@gnu.org> <837cpw9uq6.fsf@gnu.org> <834jl09tvy.fsf@gnu.org> <83leeb8a0j.fsf@gnu.org> <834jkz82kn.fsf@gnu.org> In-Reply-To: <834jkz82kn.fsf@gnu.org> From: Corwin Brust Date: Thu, 17 Aug 2023 02:25:27 -0500 Message-ID: Subject: Re: bug#65206: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain To: Eli Zaretskii Content-Type: multipart/mixed; boundary="0000000000009b89e106031951f6" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 65206 Cc: 65206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) --0000000000009b89e106031951f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 16, 2023 at 9:49=E2=80=AFAM Eli Zaretskii wrote: > > > > To confirm: when walking the list, I will want to take the first DLL > > mentioned that actually exists for each entry. Is that right? > > Yes. > The attached patch replaces DLL_REQ (the var holding the "starting" list of DLLs) with an invocation of emacs batch, as described above. Once this patch is installed, the script will require the (path to the) nominally newly created Emacs binary as an argument. I'm still looking at the differences between outputs from this and from the script as from my prior patch; however, this runs without error which will improve the situation if it is applied. (The patch is for emacs-29 because I expect Emacs 29.2 will be the next release packaged.) > > You should only skip the first two, which are Windows system DLLs. > > > > > Does a "invokes Emacs now and errors out if stuff is missing" appro= ach > > > > sound right/good? > > > > > > I'm not sure I understand how would you force Emacs to "error out" > > > when we are talking about optional dependencies. They are optional s= o > > > that Emacs could run even if they are not present. > > > > > > > Oops, badly said: I mean that my build and packaging process should > > stop and report an error if it cannot create a "complete" DEPS ZIP. > > Nothing affecting the Emacs run-time. > > OK. > The patch does not attempt this: I simply remove nil from the "first present DLL" sweep. I did verify, currently, only gdiplus and shlwapi return nil, thus the rest mentioned here are being included (except libgccjig which the script --still-- expressly omits). (mapcar (lambda(lib) (list (car lib) (seq-find (lambda(file) (file-exists-p (file-name-concat "c:/msys2/mingw64/bin" file))) (cdr lib)))) dynamic-library-alist) ((gdiplus nil) (shlwapi nil) (xpm "libXpm-nox4.dll") (png "libpng16-16.dll") (tiff "libtiff-5.dll") (jpeg "libjpeg-8.dll") (gif "libgif-7.dll") (svg "librsvg-2-2.dll") (webp "libwebp-7.dll") (webpdemux "libwebpdemux-2.dll") (sqlite3 "libsqlite3-0.dll") (gdk-pixbuf "libgdk_pixbuf-2.0-0.dll") (glib "libglib-2.0-0.dll") (gio "libgio-2.0-0.dll") (gobject "libgobject-2.0-0.dll") (gnutls "libgnutls-30.dll") (libxml2 "libxml2-2.dll") (zlib "zlib1.dll") (lcms2 "liblcms2-2.dll") (json "libjansson-4.dll") (gccjit "libgccjit-0.dll") (tree-sitter "libtree-sitter.dll")) --0000000000009b89e106031951f6 Content-Type: application/octet-stream; name="0001-Replace-hard-coded-DLL-list-with-emacs-batch-for-nt.patch" Content-Disposition: attachment; filename="0001-Replace-hard-coded-DLL-list-with-emacs-batch-for-nt.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lleu3h2e0 RnJvbSBhNDRmMDY5MDBlZmEzMzYzNWUxZTllNGJmY2JmNTRjOTA0NWUwYWJmIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBDb3J3aW4gQnJ1c3QgPGNvcndpbkBicnUuc3Q+CkRhdGU6IFRo dSwgMTcgQXVnIDIwMjMgMDE6Mjg6MTkgLTA1MDAKU3ViamVjdDogW1BBVENIXSBSZXBsYWNlIERM TCBsaXN0IHdpdGggZW1hY3MgLS1iYXRjaCBmb3IgbnQgcGFja2FnaW5nCgpUaGUgc2NyaXB0IG5v dyByZXF1aXJlcyB0aGUgcGF0aCB0byAodGhlIG5ld2x5IGJ1aWx0KSBFbWFjcyBhcyBhCmNvbW1h bmQgbGluZSBhcmd1bWVudC4gIFJ1biB0aGUgc2NyaXB0IHdpdGggLWggZm9yIGFkZGl0aW9uYWwg b3B0aW9ucy4KRW1hY3MgaXMgaW52b2tlZCB0byBwcmludCBhIGxpc3QgY29udGFpbmluZyB0aGUg Zmlyc3QgRExMIGZvdW5kIHRvCmV4aXN0IHdoaWxlIHdhbGtpbmcgdGhlIENEUiBvZiBlYWNoIGl0 ZW0gaW4gYGR5bmFtaWMtbGlicmFyeS1hbGlzdCcsCmFuZCBvdGhlciBjcml0aWNhbCBtYWludGVu YW5jZS4gKEJ1ZyM2NTIwNikKKiBudC9hZG1pbi9kaXN0LWJ1aWxkL2J1aWxkLWRlcHMtemlwcy5w eShzY3JpcHQpOiByZW1vdmUgRExMX1JFUQppbiBmYXZvciBvZiBjYWxsaW5nIGVtYWNzLCBjaGFu Z2UgdmVuZG9yIHNsdWcgZnJvbSBtc3lzNjQgdG8gbWluZ3c2NCwKc2tpcCBzb21lIGFuY2llbnQg Y2VydGlmaWNhdGVzLCBhZGQgU1JDX0VYVCB0byBtYXAgdHJhbnNmb3JtYXRpb24Kc291cmNlIHBh Y2thZ2UgbmFtZSB0cmFuc2Zvcm1hdGlvbnMgdnMgaGlzdG9yaWNhbCBjb252ZW50aW9uLgotLS0K IGFkbWluL250L2Rpc3QtYnVpbGQvYnVpbGQtZGVwLXppcHMucHkgfCAxNTEgKysrKysrKysrKysr KysrKystLS0tLS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCA5OCBpbnNlcnRpb25zKCspLCA1MyBkZWxl dGlvbnMoLSkKCmRpZmYgLS1naXQgYS9hZG1pbi9udC9kaXN0LWJ1aWxkL2J1aWxkLWRlcC16aXBz LnB5IGIvYWRtaW4vbnQvZGlzdC1idWlsZC9idWlsZC1kZXAtemlwcy5weQppbmRleCA3MTEwNWEw NzFlYy4uZmRkNzRhNjBlMmIgMTAwNzU1Ci0tLSBhL2FkbWluL250L2Rpc3QtYnVpbGQvYnVpbGQt ZGVwLXppcHMucHkKKysrIGIvYWRtaW4vbnQvZGlzdC1idWlsZC9idWlsZC1kZXAtemlwcy5weQpA QCAtMjAsMTUgKzIwLDE3IEBACiBpbXBvcnQgb3MKIGltcG9ydCBzaHV0aWwKIGltcG9ydCByZQot aW1wb3J0IGZ1bmN0b29scwotaW1wb3J0IG9wZXJhdG9yCitpbXBvcnQgc3VicHJvY2VzcwogCiBm cm9tIHN1YnByb2Nlc3MgaW1wb3J0IGNoZWNrX291dHB1dAogCiAjIyBDb25zdGFudHMKLUVNQUNT X01BSk9SX1ZFUlNJT049IjI4IgorRU1BQ1NfTUFKT1JfVkVSU0lPTj0iMjkiCiAKLSMgVGhpcyBs aXN0IGRlcml2ZXMgZnJvbSB0aGUgZmVhdHVyZXMgd2Ugd2FudCBFbWFjcyB0byBjb21waWxlIHdp dGguCisjIEJhc2UgVVJJIGZvciB0aGUgcGFja2FnZSBzb3VyY2VzIG1hcHBlZCBpbiBQS0dfUkVR CitTUkNfUkVQTz0iaHR0cHM6Ly9yZXBvLm1zeXMyLm9yZy9taW5ndy9zb3VyY2VzIgorCisjIE1h cCBpdGVtcyBpbiBgZHluYW1pYy1saWJyYXJ5LWFsaXN0JyB0byBzb3VyY2UgcGFrYWdlcwogUEtH X1JFUT0nJydtaW5ndy13NjQteDg2XzY0LWdpZmxpYgogbWluZ3ctdzY0LXg4Nl82NC1nbnV0bHMK IG1pbmd3LXc2NC14ODZfNjQtaGFyZmJ1enoKQEAgLTM3LDI2ICszOSwzNCBAQAogbWluZ3ctdzY0 LXg4Nl82NC1saWJqcGVnLXR1cmJvCiBtaW5ndy13NjQteDg2XzY0LWxpYnBuZwogbWluZ3ctdzY0 LXg4Nl82NC1saWJyc3ZnCittaW5ndy13NjQteDg2XzY0LWxpYndlYnAKIG1pbmd3LXc2NC14ODZf NjQtbGlidGlmZgogbWluZ3ctdzY0LXg4Nl82NC1saWJ4bWwyCi1taW5ndy13NjQteDg2XzY0LXhw bS1ub3gnJycuc3BsaXQoKQotCi1ETExfUkVRPScnJ2xpYmdpZgotbGliZ251dGxzCi1saWJoYXJm YnV6egotbGliamFuc3NvbgotbGlibGNtczIKLWxpYnR1cmJvanBlZwotbGlicG5nCi1saWJyc3Zn Ci1saWJ0aWZmCi1saWJ4bWwKLWxpYlhwbScnJy5zcGxpdCgpCi0KK21pbmd3LXc2NC14ODZfNjQt Z21wCittaW5ndy13NjQteDg2XzY0LXhwbS1ub3gKK21pbmd3LXc2NC14ODZfNjQtdHJlZS1zaXR0 ZXIKK21pbmd3LXc2NC14ODZfNjQtc3FsaXRlMycnJy5zcGxpdCgpCisKKyMgRW1hY3Mgc3R5bGUg cGF0aCB0byBkZXBlbmRhbmN5IERMTHMgb24gYnVpbGQgc3lzdGVtCitETExfU1JDPSJjOi9tc3lz Mi9taW5ndzY0L2JpbiIKKworIyBSZXBvcnQgZmlyc3QgZXhpc3RpbmcgZmlsZSBmb3IgZW50cmll cyBpbiBkeW5hbWljLWxpYnJhcnktYWxpc3QKK0VMSVNQX1BST0c9IiIiCisobWVzc2FnZSAiJXMi IChtYXBjb25jYXQgJ2lkZW50aXR5IChyZW1vdmUgbmlsCisJKG1hcGNhciAobGFtYmRhKGxpYikK KwkJICAoc2VxLWZpbmQKKwkJICAgKGxhbWJkYShmaWxlKQorCQkgICAgIChmaWxlLWV4aXN0cy1w CisJCSAgICAgIChmaWxlLW5hbWUtY29uY2F0ICJ7fSIKKwkJCQkJZmlsZSkpKQorCQkgICAoY2Ry IGxpYikpKQorCQlkeW5hbWljLWxpYnJhcnktYWxpc3QpCisJKSAiXFxuIikpCisiIiIuZm9ybWF0 KERMTF9TUkMpCiAKICMjIE9wdGlvbnMKIERSWV9SVU49RmFsc2UKLQorTkVXX0VNQUNTPSJiaW4v ZW1hY3MuZXhlIgogCiBkZWYgY2hlY2tfb3V0cHV0X21heWJlKCphcmdzLCoqa3dhcmdzKToKICAg ICBpZihEUllfUlVOKToKQEAgLTY0LDE1ICs3NCwxNyBAQCBkZWYgY2hlY2tfb3V0cHV0X21heWJl KCphcmdzLCoqa3dhcmdzKToKICAgICBlbHNlOgogICAgICAgICByZXR1cm4gY2hlY2tfb3V0cHV0 KCphcmdzLCoqa3dhcmdzKQogCisjIyMjIyMjIyMjIyMjIyMjIyMjIwogIyMgRExMIENhcHR1cmUK KworIyBlbnRyeSBwb2ludAogZGVmIGdhdGhlcl9kZXBzKCk6CiAKICAgICBvcy5ta2RpcigieDg2 XzY0IikKICAgICBvcy5jaGRpcigieDg2XzY0IikKIAotICAgIGZvciBkZXAgaW4gZnVsbF9kbGxf ZGVwZW5kZW5jeSgpOgotICAgICAgICBjaGVja19vdXRwdXRfbWF5YmUoWyJjcCAvbWluZ3c2NC9i aW4ve30qLmRsbCAuIi5mb3JtYXQoZGVwKV0sCi0gICAgICAgICAgICAgICAgICAgICAgICAgICBz aGVsbD1UcnVlKQorICAgIGZvciBkZXAgaW4gZnVsbF9kbGxfZGVwZW5kZW5jeShpbml0X2RlcHMo KSk6CisgICAgICAgIGNoZWNrX291dHB1dF9tYXliZShbImNwIC9taW5ndzY0L2Jpbi97fSAuIi5m b3JtYXQoZGVwKV0sIHNoZWxsPVRydWUpCiAKICAgICBwcmludCgiWmlwcGluZyIpCiAgICAgY2hl Y2tfb3V0cHV0X21heWJlKCJ6aXAgLTlyIC4uL2VtYWNzLXt9LXt9ZGVwcy56aXAgKiIKQEAgLTgw LDE1ICs5MiwyMyBAQCBkZWYgZ2F0aGVyX2RlcHMoKToKICAgICAgICAgICAgICAgICAgICAgICAg c2hlbGw9VHJ1ZSkKICAgICBvcy5jaGRpcigiLi4vIikKIAotIyMgUmV0dXJuIGFsbCBFbWFjcyBk ZXBlbmRlbmNpZXMKLWRlZiBmdWxsX2RsbF9kZXBlbmRlbmN5KCk6Ci0gICAgZGVwcyA9IFtkbGxf ZGVwZW5kZW5jeShkZXApIGZvciBkZXAgaW4gRExMX1JFUV0KLSAgICByZXR1cm4gc2V0KHN1bShk ZXBzLCBbXSkgKyBETExfUkVRKQorIyBSZXR1cm4gZGVwZW5kYW5jaWVzIGxpc3RlZCBpbiBFbWFj cworZGVmIGluaXRfZGVwcygpOgorICAgIGpvYl9hcmdzPVtORVdfRU1BQ1MsICItLWJhdGNoIiwg Ii0tZXZhbCIsIEVMSVNQX1BST0ddCisgICAgcHJpbnQoImFyZ3M6ICIsIGpvYl9hcmdzKQorICAg IHJldHVybiBzdWJwcm9jZXNzLmNoZWNrX291dHB1dChqb2JfYXJncywgc3RkZXJyPXN1YnByb2Nl c3MuU1RET1VUCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICkuZGVjb2RlKCd1 dGYtOCcpLnNwbGl0bGluZXMoKQorCisjIFJldHVybiBhbGwgc2Vjb25kIG9yZGVyIGRlcGVuZGVu Y2llcworZGVmIGZ1bGxfZGxsX2RlcGVuZGVuY3koZGxscyk6CisgICAgZGVwcyA9IFtkbGxfZGVw ZW5kZW5jeShkZXApIGZvciBkZXAgaW4gZGxsc10KKyAgICByZXR1cm4gc2V0KHN1bShkZXBzLCBb XSkgKyBkbGxzKQogCi0jIyBEZXBlbmRlbmNpZXMgZm9yIGEgZ2l2ZW4gRExMCisjIERlcGVuZGVu Y2llcyBmb3IgYSBnaXZlbiBETEwKIGRlZiBkbGxfZGVwZW5kZW5jeShkbGwpOgogICAgIG91dHB1 dCA9IGNoZWNrX291dHB1dChbIi9taW5ndzY0L2Jpbi9udGxkZCIsICItLXJlY3Vyc2l2ZSIsCi0g ICAgICAgICAgICAgICAgICAgICAgICAgICAiL21pbmd3NjQvYmluL3t9Ki5kbGwiLmZvcm1hdChk bGwpXSkuZGVjb2RlKCJ1dGYtOCIpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAiL21pbmd3 NjQvYmluL3t9Ii5mb3JtYXQoZGxsKV0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgKS5kZWNv ZGUoInV0Zi04IikKICAgICAjIyBtdW5nZSBvdXRwdXQKICAgICByZXR1cm4gbnRsZGRfbXVuZ2Uo b3V0cHV0KQogCkBAIC0xMDMsOSArMTIzLDkgQEAgZGVmIG50bGRkX211bmdlKG91dCk6CiAKICAg ICAgICAgIyMgaWYgaXQncyB0aGUgZm9ybWVyLCB3ZSB3YW50IGl0LCBpZiBpdHMgdGhlIGxhdGVy IHdlIGRvbid0CiAgICAgICAgIHNwbHQgPSBkZXAuc3BsaXQoKQotICAgICAgICBpZiBsZW4oc3Bs dCkgPiAyIGFuZCAibXN5czY0IiBpbiBzcGx0WzJdOgorICAgICAgICBpZiBsZW4oc3BsdCkgPiAy IGFuZCAibWluZ3c2NCIgaW4gc3BsdFsyXToKICAgICAgICAgICAgIHByaW50KCJBZGRpbmcgZGVw Iiwgc3BsdFswXSkKLSAgICAgICAgICAgIHJ0bi5hcHBlbmQoc3BsdFswXS5zcGxpdCgiLiIpWzBd KQorICAgICAgICAgICAgcnRuLmFwcGVuZChzcGx0WzBdKQogCiAgICAgcmV0dXJuIHJ0bgogCkBA IC0xMTQsMjYgKzEzNCw0MyBAQCBkZWYgbnRsZGRfbXVuZ2Uob3V0KToKICMjIFBhY2thZ2VzIHRv IGZpZGRsZSB3aXRoCiAjIyBTb3VyY2UgZm9yIGdjYy1saWJzIGlzIHBhcnQgb2YgZ2NjCiBTS0lQ X1NSQ19QS0dTPVsibWluZ3ctdzY0LWdjYy1saWJzIl0KLVNLSVBfREVQX1BLR1M9ZnJvemVuc2V0 KFsibWluZ3ctdzY0LXg4Nl82NC1nbGliMiJdKQorU0tJUF9ERVBfUEtHUz1bIm1pbmd3LXc2NC1n bGliMiIsICJtaW5ndy13NjQtY2EtY2VydGlmaWNhdGVzLTIwMjExMDE2LTMiXQogTVVOR0VfU1JD X1BLR1M9eyJtaW5ndy13NjQtbGlid2lucHRocmVhZC1naXQiOiJtaW5ndy13NjQtd2lucHRocmVh ZHMtZ2l0In0KIE1VTkdFX0RFUF9QS0dTPXsKICAgICAibWluZ3ctdzY0LXg4Nl82NC1saWJ3aW5w dGhyZWFkIjoibWluZ3ctdzY0LXg4Nl82NC1saWJ3aW5wdGhyZWFkLWdpdCIsCiAgICAgIm1pbmd3 LXc2NC14ODZfNjQtbGlidHJlIjogIm1pbmd3LXc2NC14ODZfNjQtbGlidHJlLWdpdCIsCiB9CitT UkNfRVhUPXsKKyAgICAibWluZ3ctdzY0LWZyZWV0eXBlIjogIi5zcmMudGFyLnpzdCIsCisgICAg Im1pbmd3LXc2NC1mcmliaWRpIjogIi5zcmMudGFyLnpzdCIsCisgICAgIm1pbmd3LXc2NC1nbGli MiI6ICIuc3JjLnRhci56c3QiLAorICAgICJtaW5ndy13NjQtaGFyZmJ1enoiOiAiLnNyYy50YXIu enN0IiwKKyAgICAibWluZ3ctdzY0LWxpYnVuaXN0cmluZyI6ICIuc3JjLnRhci56c3QiLAorICAg ICJtaW5ndy13NjQtd2lucHRocmVhZHMtZ2l0IjogIi5zcmMudGFyLnpzdCIsCisgICAgIm1pbmd3 LXc2NC1jYS1jZXJ0aWZpY2F0ZXMiOiAiLnNyYy50YXIuenN0IiwKKyAgICAibWluZ3ctdzY0LWxp YnhtbDIiOiAiLnNyYy50YXIuenN0IiwKKyAgICAibWluZ3ctdzY0LW5jdXJzZXMiOiAiLnNyYy50 YXIuenN0IiwKKyAgICAibWluZ3ctdzY0LW9wZW5zc2wiOiAiLnNyYy50YXIuenN0IiwKKyAgICAi bWluZ3ctdzY0LXBhbmdvIjogIi5zcmMudGFyLnpzdCIsCisgICAgIm1pbmd3LXc2NC1weXRob24i OiAiLnNyYy50YXIuenN0IiwKKyAgICAibWluZ3ctdzY0LXNxbGl0ZTMiOiAiLnNyYy50YXIuenN0 IiwKKyAgICAibWluZ3ctdzY0LXhwbS1ub3giOiAiLnNyYy50YXIuenN0IiwKKyAgICAibWluZ3ct dzY0LXh6IjogIi5zcmMudGFyLnpzdCIsCit9CiAKICMjIEN1cnJlbnRseSBubyBwYWNrYWdlcyBz ZWVtIHRvIHJlcXVpcmUgdGhpcyEKIEFSQ0hfUEtHUz1bXQotU1JDX1JFUE89Imh0dHBzOi8vcmVw by5tc3lzMi5vcmcvbWluZ3cvc291cmNlcyIKIAorZGVmIGltbWVkaWF0ZV9kZXBzKHBrZyk6Cisg ICAgcGFja2FnZV9pbmZvID0gY2hlY2tfb3V0cHV0KFsicGFjbWFuIiwgIi1TaSIsIHBrZ10pLmRl Y29kZSgidXRmLTgiKS5zcGxpdCgiXG4iKQogCi1kZWYgaW1tZWRpYXRlX2RlcHMocGtncyk6Ci0g ICAgcGFja2FnZV9pbmZvID0gY2hlY2tfb3V0cHV0KFsicGFjbWFuIiwgIi1TaSJdICsgcGtncyku ZGVjb2RlKCJ1dGYtOCIpLnNwbGl0bGluZXMoKQorICAgICMjIEV4dHJhY3QgdGhlICJEZXBlbmRz IE9uIiBsaW5lCisgICAgZGVwZW5kc19vbiA9IFt4IGZvciB4IGluIHBhY2thZ2VfaW5mbyBpZiB4 LnN0YXJ0c3dpdGgoIkRlcGVuZHMgT24iKV1bMF0KKyAgICAjIyBSZW1vdmUgIkRlcGVuZHMgT24i IHByZWZpeAorICAgIGRlcGVuZGVuY2llcyA9IGRlcGVuZHNfb24uc3BsaXQoIjoiKVsxXQogCi0g ICAgIyMgRXh0cmFjdCB0aGUgcGFja2FnZXMgbGlzdGVkIGZvciAiRGVwZW5kcyBPbjoiIGxpbmVz LgotICAgIGRlcGVuZGVuY2llcyA9IFtsaW5lLnNwbGl0KCI6IilbMV0uc3BsaXQoKSBmb3IgbGlu ZSBpbiBwYWNrYWdlX2luZm8KLSAgICAgICAgICAgICAgICAgICAgaWYgbGluZS5zdGFydHN3aXRo KCJEZXBlbmRzIE9uIildCi0gICAgIyMgRmxhdHRlbiBkZXBlbmRlbmN5IGxpc3RzIGZyb20gbXVs dGlwbGUgcGFja2FnZXMgaW50byBvbmUgbGlzdC4KLSAgICBkZXBlbmRlbmNpZXMgPSBmdW5jdG9v bHMucmVkdWNlKG9wZXJhdG9yLmljb25jYXQsIGRlcGVuZGVuY2llcywgW10pCisgICAgIyMgU3Bs aXQgaW50byBkZXBlbmRlbmNpZXMKKyAgICBkZXBlbmRlbmNpZXMgPSBkZXBlbmRlbmNpZXMuc3Ry aXAoKS5zcGxpdCgiICIpCiAKICAgICAjIyBSZW1vdmUgPiBzaWducyBUT0RPIGNhbiB3ZSBnZXQg YW55IG90aGVyIHB1bmN0dWF0aW9uIGhlcmU/CiAgICAgZGVwZW5kZW5jaWVzID0gW2Quc3BsaXQo Ij4iKVswXSBmb3IgZCBpbiBkZXBlbmRlbmNpZXMgaWYgZF0KQEAgLTE0OSwxOCArMTg2LDE2IEBA IGRlZiBleHRyYWN0X2RlcHMoKToKICAgICBwcmludCggIkV4dHJhY3RpbmcgZGVwcyIgKQogCiAg ICAgIyBHZXQgYSBsaXN0IG9mIGFsbCBkZXBlbmRlbmNpZXMgbmVlZGVkIGZvciBwYWNrYWdlcyBt ZW50aW9uZWQgYWJvdmUuCi0gICAgcGtncyA9IHNldChQS0dfUkVRKQotICAgIG5ld2RlcHMgPSBw a2dzCi0gICAgcHJpbnQoImFkZGluZy4uLiIpCi0gICAgd2hpbGUgVHJ1ZToKLSAgICAgICAgc3Vi ZGVwcyA9IGZyb3plbnNldChpbW1lZGlhdGVfZGVwcyhsaXN0KG5ld2RlcHMpKSkKLSAgICAgICAg bmV3ZGVwcyA9IHN1YmRlcHMgLSBTS0lQX0RFUF9QS0dTIC0gcGtncwotICAgICAgICBpZiBub3Qg bmV3ZGVwczoKLSAgICAgICAgICAgIGJyZWFrCi0gICAgICAgIHByaW50KCdcbicuam9pbihuZXdk ZXBzKSkKLSAgICAgICAgcGtncyB8PSBuZXdkZXBzCisgICAgcGtncyA9IFBLR19SRVFbOl0KKyAg ICBuID0gMAorICAgIHdoaWxlIG4gPCBsZW4ocGtncyk6CisgICAgICAgIHN1YmRlcHMgPSBpbW1l ZGlhdGVfZGVwcyhwa2dzW25dKQorICAgICAgICBmb3IgcCBpbiBzdWJkZXBzOgorICAgICAgICAg ICAgaWYgbm90IChwIGluIHBrZ3Mgb3IgcCBpbiBTS0lQX0RFUF9QS0dTKToKKyAgICAgICAgICAg ICAgICBwa2dzLmFwcGVuZChwKQorICAgICAgICBuID0gbiArIDEKIAotICAgIHJldHVybiBsaXN0 KHBrZ3MpCisgICAgcmV0dXJuIHNvcnRlZChwa2dzKQogCiAKIGRlZiBkb3dubG9hZF9zb3VyY2Uo dGFyYmFsbCk6CkBAIC0yMDgsNyArMjQzLDEzIEBAIGRlZiBnYXRoZXJfc291cmNlKGRlcHMpOgog ICAgICAgICAjIyBTd2l0Y2ggbmFtZXMgaWYgbmVjZXNzYXJ5CiAgICAgICAgIHBrZ19uYW1lID0g TVVOR0VfU1JDX1BLR1MuZ2V0KHBrZ19uYW1lLHBrZ19uYW1lKQogCi0gICAgICAgIHRhcmJhbGwg PSAie30te30uc3JjLnRhci5neiIuZm9ybWF0KHBrZ19uYW1lLHBrZ192ZXJzaW9uKQorICAgICAg ICAjIyBzcmMgYXJjaGl2ZSBpcyB1c3VhbGx5IGEgLnRhci5negorICAgICAgICBpZiBwa2dfbmFt ZSBpbiBTUkNfRVhULmtleXMoKToKKyAgICAgICAgICAgIHNyY19leHQgPSBTUkNfRVhUW3BrZ19u YW1lXQorICAgICAgICBlbHNlOgorICAgICAgICAgICAgc3JjX2V4dCA9ICIuc3JjLnRhci5neiIK KworICAgICAgICB0YXJiYWxsID0gInt9LXt9e30iLmZvcm1hdChwa2dfbmFtZSxwa2dfdmVyc2lv bixzcmNfZXh0KQogCiAgICAgICAgIGRvd25sb2FkX3NvdXJjZSh0YXJiYWxsKQogCkBAIC0yMzMs NiArMjc0LDkgQEAgZGVmIGNsZWFuKCk6CiAKIAogcGFyc2VyID0gYXJncGFyc2UuQXJndW1lbnRQ YXJzZXIoKQorCitwYXJzZXIuYWRkX2FyZ3VtZW50KCJlbWFjcyIsIGhlbHA9ImVtYWNzIGV4ZWN1 dGFibGUiKQorCiBwYXJzZXIuYWRkX2FyZ3VtZW50KCItcyIsIGhlbHA9InNuYXBzaG90IGJ1aWxk IiwKICAgICAgICAgICAgICAgICAgICAgYWN0aW9uPSJzdG9yZV90cnVlIikKIApAQCAtMjUxLDEz ICsyOTUsMTQgQEAgZGVmIGNsZWFuKCk6CiBhcmdzID0gcGFyc2VyLnBhcnNlX2FyZ3MoKQogZG9f YWxsPW5vdCAoYXJncy5jIG9yIGFyZ3MucikKIAotCitORVdfRU1BQ1M9YXJncy5lbWFjcwogCiBE UllfUlVOPWFyZ3MuZAogCiBpZiggYXJncy5sICk6CiAgICAgcHJpbnQoIkxpc3Qgb2YgZGVwZW5k ZW5jaWVzIikKLSAgICBwcmludCggZGVwcyApCisgICAgaW5pdF9kZXBzKCkKKyAgICBwcmludCgg ZXh0cmFjdF9kZXBzKCkgKQogICAgIGV4aXQoMCkKIAogaWYgYXJncy5zOgotLSAKMi4zNi4xCgo= --0000000000009b89e106031951f6-- From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 17 05:55:57 2023 Received: (at 65206) by debbugs.gnu.org; 17 Aug 2023 09:55:57 +0000 Received: from localhost ([127.0.0.1]:42795 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWZjR-0000fj-GF for submit@debbugs.gnu.org; Thu, 17 Aug 2023 05:55:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50122) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWZjQ-0000fX-Io for 65206@debbugs.gnu.org; Thu, 17 Aug 2023 05:55:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qWZjL-0003jd-8l; Thu, 17 Aug 2023 05:55:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=FbOrwceszpzixWKRSuQuPIbY1iGyfBhr/X5hUnaUgk0=; b=HcVU5AuTK5wl YJ80jxva/5/I1xqRPERvBVlr/FJij32yWQQ4aTWdqGS0jK6P1T2tDb3CpuhDIYbFpb4os9/l73TcZ FgjL9buEtWbGYJ9a/I8KCo2xXJDrkKl6r6xrUlPcCoZpb+bfA+PO0rX2G9/W4Cs+ew91vai9/KmVy Wiw4wPRyPpUob6f0hYhzCavG5Xkn2fJC9Rg3IVIfmoIuGVEZYkzl2ppyeB3hujdxKCczs6ROVnYhQ SkrKuIHFUd1bLqv7CEb8ml41zeOwBaAUS5+Z+ckqZuM0m0LbCW5HdWVTv1QqxPTRDwdCG0bE73HfS oi1FtaoCu1RappofZ2/osQ==; Date: Thu, 17 Aug 2023 12:55:55 +0300 Message-Id: <83r0o256xg.fsf@gnu.org> From: Eli Zaretskii To: Corwin Brust In-Reply-To: (message from Corwin Brust on Thu, 17 Aug 2023 02:25:27 -0500) Subject: Re: bug#65206: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain References: <83msyzhvpz.fsf@gnu.org> <837cpw9uq6.fsf@gnu.org> <834jl09tvy.fsf@gnu.org> <83leeb8a0j.fsf@gnu.org> <834jkz82kn.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65206 Cc: 65206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Corwin Brust > Date: Thu, 17 Aug 2023 02:25:27 -0500 > Cc: 65206@debbugs.gnu.org > > The attached patch replaces DLL_REQ (the var holding the "starting" > list of DLLs) with an invocation of emacs batch, as described above. > Once this patch is installed, the script will require the (path to > the) nominally newly created Emacs binary as an argument. > > I'm still looking at the differences between outputs from this and > from the script as from my prior patch; however, this runs without > error which will improve the situation if it is applied. (The patch > is for emacs-29 because I expect Emacs 29.2 will be the next release > packaged.) Hmm... what is the value of libjpeg-version? It's 90 here, so the library for JPEG is libjpeg-9.dll, not libjpeg-8.dll. Otherwise, LGTM, thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 17 09:31:31 2023 Received: (at 65206) by debbugs.gnu.org; 17 Aug 2023 13:31:31 +0000 Received: from localhost ([127.0.0.1]:42972 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWd62-0003BE-V3 for submit@debbugs.gnu.org; Thu, 17 Aug 2023 09:31:31 -0400 Received: from mail-ot1-f41.google.com ([209.85.210.41]:53578) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWd60-0003Ay-FA for 65206@debbugs.gnu.org; Thu, 17 Aug 2023 09:31:29 -0400 Received: by mail-ot1-f41.google.com with SMTP id 46e09a7af769-6bcaa6d5e2cso6500485a34.3 for <65206@debbugs.gnu.org>; Thu, 17 Aug 2023 06:31:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692279083; x=1692883883; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jKkwFJrkyz1f6TA9OYfnY8oWHLVwYLY1FwZ6C73K9Pw=; b=Hdqj+eHY9xyopuIOINxWw5AlR6D/XRE1dE/X0I1/xbEUzrHwJ6WFmTJctp1wSMflAF 9vOdrFADCz5mwZZO22sRteCLncVl7C5vsSb9QyykCPlw3WOHgV/+WVOj4jGsSlUe/pU1 IaFPry5efYt/x5HonHFe7Tq2q1la0lYgFMrXI7o5pJzAvGg1H3LwKkVNvgxuuqNsCxNj QMXl05UxQCU5WLo2kl9sFJnb7ycJBfOqeQBRkWlETjEWEHuCftnNR6KtpbNnNBO4D9Nr LdAOLd9RM96pMW1kf6YFUjaGwu8g8W6lIZQOu3gVQLvOKLx+c8CgdFJhOjZ9heidgwe4 l8fQ== X-Gm-Message-State: AOJu0YwNKR0fTgOjy6+iMCHjgd/5oj8MI/7Zo4rRw/7UUj5qxiGDfhHK aidJGKLvHAaRpc4ide+lDDMbSWX6dzX2qUlqk4M= X-Google-Smtp-Source: AGHT+IFDCzl+j5as2zjAjPLmuKQM9UqK6y0rLVRcxz2L6bqK5gc3YxISHquRacZCoMTtUrIi5OUs1DHLOqki4JdFxYY= X-Received: by 2002:a05:6870:f6a8:b0:1b0:883e:3095 with SMTP id el40-20020a056870f6a800b001b0883e3095mr6115366oab.56.1692279082877; Thu, 17 Aug 2023 06:31:22 -0700 (PDT) MIME-Version: 1.0 References: <83msyzhvpz.fsf@gnu.org> <837cpw9uq6.fsf@gnu.org> <834jl09tvy.fsf@gnu.org> <83leeb8a0j.fsf@gnu.org> <834jkz82kn.fsf@gnu.org> <83r0o256xg.fsf@gnu.org> In-Reply-To: <83r0o256xg.fsf@gnu.org> From: Corwin Brust Date: Thu, 17 Aug 2023 08:31:12 -0500 Message-ID: Subject: Re: bug#65206: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 65206 Cc: 65206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On Thu, Aug 17, 2023 at 4:55=E2=80=AFAM Eli Zaretskii wrote: > > > Hmm... what is the value of libjpeg-version? It's 90 here, so the > library for JPEG is libjpeg-9.dll, not libjpeg-8.dll. I have 80 > > Otherwise, LGTM, thanks. > From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 23 01:17:47 2025 Received: (at 65206) by debbugs.gnu.org; 23 Feb 2025 06:17:47 +0000 Received: from localhost ([127.0.0.1]:58963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tm5JC-0001AM-KO for submit@debbugs.gnu.org; Sun, 23 Feb 2025 01:17:46 -0500 Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]:45175) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tm5JA-0001A1-1G for 65206@debbugs.gnu.org; Sun, 23 Feb 2025 01:17:45 -0500 Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5e04cb346eeso5662250a12.2 for <65206@debbugs.gnu.org>; Sat, 22 Feb 2025 22:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740291458; x=1740896258; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=pNEufxre0tswdSjdG4P1Co4lpArxgOsFqH5Oh4k3AcQ=; b=UV7Xn/fpE8E+6rrOu/PPps/KK3YeFxO9mnG5Fu5Bq4tAi+AJZD94jYkk1NLMYjqw7/ +nx1W8U+HuxK6+u0vhwviRjpTC4BxKW0ZvSqkibU3N3KDYu7Jd66NeINCyCZjVA96l8Q L618baB8bDCx2ZTvMFm5aukhW+UehSj5CW4ge4XCoKzNx3qHjP2fqearWwJVMPpQPH/5 d1AI5U3wx1+11pmC1Y1OzRworwvfABGPzRQAmZ1McCF+4abNZPyaopEVjeNc8KI0POHX WedvD9rukCUe2CbeSP5C78xQDJdDKwyegfzg12ynp7xBdlTVFBE5S8aPSJLNJflKWvoM o5kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740291458; x=1740896258; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pNEufxre0tswdSjdG4P1Co4lpArxgOsFqH5Oh4k3AcQ=; b=LUgExWHVfEvM0H9LXeUOxbwZ644J5xeoPVupInQvDJFERCPY13SLO01qZ9OZ9yXfjT Wx0kc52+vb0w+lf9fWa5bUqAsy7wpzQygR01mdaG2srSNOlzHwUFafXoEdaVm5jfzfBE zbboaKQBoJvGZBPmMljk7DllrhQiErroVDhNk2zeOVoNhnPEsGlyk6U8Em7lrCrgR8zN eFdBjFV15gHoW6FKhaLLRp3nDXIIK9e5r5bzC+WIrnDFulvk4f3+SodOBFUOtFIRGt1H GubZsaqHpPdkbfZjmFsB1xpCCdYIE+ykZmNy4wOzf1K9ykJ5lJq5LBej1E5/eW18FSZe 2XiA== X-Gm-Message-State: AOJu0YyteynSAZpmrwnDHflGAL2GgkvQd8k2t6yd8T37OdNS8R+/5ESW 63nlKod31A3RBczMq2Z/XINUkIQLnGJDaQfDTBz2JkmTCoZW09ElkngOCA4CPuOG3QcPE9dJj19 P92Smzvpf7ejcJSMM9jYRqpuodQZLcwp+bH0= X-Gm-Gg: ASbGnct4IV0spGEsQGJT9m3JOoyLLa+9zLUXnY+g6OkTznTeBz7JMSvJoKqACgqUe91 O3ekNVzcqvY11kzleBrrqML/Na6PxWvJjEp4ZjNLbhV4ZpSXUoSPQHQDkY1qFpcGX42zf0NkJcE Eq6uPasuLi X-Google-Smtp-Source: AGHT+IHYB1nMOYHQAtBhtiZUPwHCb89K2ZyaFoLdb019vyvOTpYEEdB89YeZIvSmEw58qj0VUu844t+mCHIeTS67Z4Y= X-Received: by 2002:a05:6402:388e:b0:5de:de30:dd0d with SMTP id 4fb4d7f45d1cf-5e0b7248363mr7195325a12.32.1740291457864; Sat, 22 Feb 2025 22:17:37 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 23 Feb 2025 06:17:37 +0000 From: Stefan Kangas In-Reply-To: References: MIME-Version: 1.0 Date: Sun, 23 Feb 2025 06:17:37 +0000 X-Gm-Features: AWEUYZkDaoXEkR-bddtJoMb0nFooSZFF3BB3inAAkfAvxNV7Lf6mPD_mAeiP7GE Message-ID: Subject: Re: bug#65206: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain To: Corwin Brust Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 65206 Cc: 65206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Corwin Brust writes: > The script nt/admin/dist-build/build-deps-zips.py needs help. This is > the script that I use to collect and package dependencies and sources > for dependencies on Microsoft Windows, as part of releasing Emacs > binaries for Windows. It is a python script that runs under MSYS2 > MSYS console (not MinGW). > > Neither the version currently in the emacs-29 nor in the master > branches will work for the given Emacs version without changes. The > attached patch would make emacs-29 match what I am using locally. > > In addition to other changes, the patch reflects my current "transformation map" > approach to deal with MSYS source package paths change, which seems to > be happening quite a bit upstream. > > In case it may not be clear, my process is to run the script > after updating local MSYS packages that are dependencies (optional or > no), or edit and run it when Emacs' dependencies have changed. > > The patch reflects the script as I have been using it during the Emacs > 29 release process. I'm sure there's general room for improvement > (editing this script is literally my only python coding credit), I'm > opening this bug report because bug#65188 (a packaging error preventing > WEBP from working for people using the Windows binaries) has called > attention to the importance of having additional eyes on build tooling > (especially when it so far contains hard-coded lists of upstream deps). That was 18 months ago. What's the latest here, did you make any progress? Is this bug report still relevant? Thanks in advance. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 23 12:31:02 2025 Received: (at 65206-done) by debbugs.gnu.org; 23 Feb 2025 17:31:02 +0000 Received: from localhost ([127.0.0.1]:35847 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tmFoj-0004u4-Ua for submit@debbugs.gnu.org; Sun, 23 Feb 2025 12:31:02 -0500 Received: from mail-pj1-f46.google.com ([209.85.216.46]:38159) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tmFoh-0004tY-7s for 65206-done@debbugs.gnu.org; Sun, 23 Feb 2025 12:30:59 -0500 Received: by mail-pj1-f46.google.com with SMTP id 98e67ed59e1d1-2f9b8ef4261so957650a91.1 for <65206-done@debbugs.gnu.org>; Sun, 23 Feb 2025 09:30:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740331853; x=1740936653; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4KOMjqvafSSagxjnO5noPLNMgOPjUTa8tdYO7o37u78=; b=Etphnszp1GQsqmoCC35M2hplXHRHpaKNunitkbGkcwL1GYixWEwHDtZAP7LICkn8xM WNa24p4TnDyCksBDbiUxzB8yaFNW2aVq+C3V8SaD74sx1H4xNFu3652xlmWuHIZgWns3 fRgBFSN5gAjg3qXPGSkUCS1Nyx6WZ7h/c5W2g5LvblEnK0NmX+2VwGYqh6iPYgTVmqOE FfDKV6uhMto0lUuwm3b3AoUMImmn3nBmQGvLVAgFAisA1Z1ygeLKISWB0gAq6Fb2b9bK 65Gk8zs8sxMhOdNuoKt7lB5PQ/PLIY/U9j9kOKf7xkWGqXOux2aLg27rHxVXYruhvdP/ cowA== X-Forwarded-Encrypted: i=1; AJvYcCXIpBpzG/7lqYDY2nvxwGVHgBCVK9TFiPfxYRWUnLdhut5yhbBxWtHJbxYPbfyWiHqCbh9LDwV8r37l@debbugs.gnu.org X-Gm-Message-State: AOJu0Yxa5T+H/y4EwVyOUVL6O6rF6UyYvLzPIYo/VWFrVsg6a+C/jASm FURpsA4pfg25dPWpHLjAQWIlYQY6Im75WjZAdsPQE7nb/6dqS7e/OgA7mMQlM7UOC4BB/NYv18M j1DmGK72J8hmDSXD0hF4g37JlalI= X-Gm-Gg: ASbGncv6DY1ow0d7xj2Ryu91H3SWOhLL9mfPiHRqdPgdZc6Ar0O8X87Be88+e49fP1G WlhevX7BXpbY2igqmnJSYdLXaxnNTwZ/zm0SFwQvGZZXN0VSktuT3O2c62Fw+jy8J50A5xRfoWl Gb1DkKATFk X-Google-Smtp-Source: AGHT+IH8ieAl91gDZkB0T9youXzaN1M+dXnFB+eQjIWY/LBNILGoZyqL89XrDuzs1hLoE7eeGL9a0i+XnGFzhliwiAU= X-Received: by 2002:a17:90b:3848:b0:2ee:6d73:7ae6 with SMTP id 98e67ed59e1d1-2fce7b6adcamr6400721a91.7.1740331852953; Sun, 23 Feb 2025 09:30:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Corwin Brust Date: Sun, 23 Feb 2025 11:30:41 -0600 X-Gm-Features: AWEUYZloHgFOanlgCI6Nh5G0fOvhF0qsAwqL7wEi60kIO7YD2N9-qV5Dvqx7Ztw Message-ID: Subject: Re: bug#65206: 29.1; [windows][patch] build-deps-zips.py is broken and hard to maintain To: Stefan Kangas , 65206-done@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 65206-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Thanks for the nudge! > > That was 18 months ago. What's the latest here, did you make any > progress? Is this bug report still relevant? > > Thanks in advance. > Yes, there has been progress! I believe the most critical issues are resolved --the script works now. I have been working with other contributors to improve what I have, it's pretty messy, but: closing this report now. Things aren't nearly so dire anymore :) Warm regards, Corwin From unknown Mon Aug 18 08:54:06 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 24 Mar 2025 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator