Emacs pretest 28.0.91 is out

Emacs pretest 28.0.91 is out

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

Hi!

The second pretest for what will be the 28.1 release of Emacs (the
extensible text editor) is available at:

  https://alpha.gnu.org/gnu/emacs/pretest/emacs-28.0.91.tar.xz

The tarball is signed; you can get the PGP signature file at:

  https://alpha.gnu.org/gnu/emacs/pretest/emacs-28.0.91.tar.xz.sig

Please give it as much testing as you can.

As always, if you encounter problems building or using Emacs,
send a report to bug-gnu-emacs@gnu.org with full details
(if possible, use M-x report-emacs-bug).

Thanks for helping to test Emacs.

--------------------------------------

To verify that the tarball is intact, download both the .sig and
the tarball, and run this command:

  gpg --verify emacs-28.0.91.tar.xz.sig

If that command fails because you don't have the required public key,
run this command to import it:

  gpg --keyserver pgp.mit.edu --recv-keys \
    CEA1DE21AB108493CC9C65742E82323B8F4353EE

You can also run sha1sum or sha256sum and confirm that these
checksums match:

SHA1  emacs-28.0.91.tar.xz
1da31cce4002ae5a7a662fedd27add98fa8b8738

SHA256  emacs-28.0.91.tar.xz
7a9088567511d88a06dc1e1b12f748a0a26e9dcea594549ab855375225345057

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

RE: [External] : Emacs pretest 28.0.91 is out

[Drew Adams]

> https://alpha.gnu.org/gnu/emacs/pretest/emacs-28.0.91.tar.xz

Any hope there will be something here?

https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-28/

(There wasn't anything for the first 28 pretest, was there?)

Re: [External] : Emacs pretest 28.0.91 is out

[Po Lu]

Drew Adams <drew.adams@oracle.com> writes:

> Any hope there will be something here?

IIRC the person who used to make the MS-Windows prebuilts quit, so maybe
nobody else stepped up.

Re: [External] : Emacs pretest 28.0.91 is out

[Corwin Brust]

Hi!

On Mon, Jan 10, 2022 at 8:29 PM Po Lu <luangruo@yahoo.com> wrote:
>
> Drew Adams <drew.adams@oracle.com> writes:
>
> > Any hope there will be something here?
>
> IIRC the person who used to make the MS-Windows prebuilts quit, so maybe
> nobody else stepped up.
>

I (and others) have volunteered to attempt to come up to speed with
this.  I'm attempting to make dist on windows now but I'm very, very
novice.   I'm optimistic one of us will get there, however.   I'll
share a link to my build artifacts if I do manage to create some.

Regards,
Corwin

Re: Emacs pretest 28.0.91 is out

[Robert Pluim]

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

>>>>> On Mon, 10 Jan 2022 16:39:40 -0600, Stefan Kangas <stefan@marxist.se> said:

    Stefan> Hi!
    Stefan> The second pretest for what will be the 28.1 release of Emacs (the
    Stefan> extensible text editor) is available at:

    Stefan>   https://alpha.gnu.org/gnu/emacs/pretest/emacs-28.0.91.tar.xz

I get three test failures on macOS with this (and zero on
GNU/Linux). The spelling test one is because I think my hunspell
installation is broken, but we can guard against it (see attached
patch). The other two I suspect are because 'gcc' here is 'clang', not
real gcc, so maybe those tests need to check for that. Logs attached.


1 files did not contain any tests:
  lisp/so-long-tests/spelling-tests.log
2 files contained unexpected results:
  lisp/progmodes/flymake-tests.log
  lisp/cedet/semantic/bovine/gcc-tests.log
make[2]: *** [check-doit] Error 2
make[1]: *** [check] Error 2
make: *** [check] Error 2


Robert
-- 


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-spelling-tests.el-trap-error.patch --]
[-- Type: text/x-diff, Size: 1240 bytes --]

From f7129d54b258cfaf5de374e7cc2c678c5bf490eb Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim@gmail.com>
Date: Tue, 11 Jan 2022 12:20:44 +0100
Subject: [PATCH] spelling-tests.el: trap error
To: emacs-devel@gnu.org

'ispell-valid-dictionary-list' can signal an error, so guard against
that.

* test/lisp/so-long-tests/spelling-tests.el (so-long-spelling): Wrap
check for ispell-valid-dictionary-list in condition-case.
---
 test/lisp/so-long-tests/spelling-tests.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/test/lisp/so-long-tests/spelling-tests.el b/test/lisp/so-long-tests/spelling-tests.el
index eb1014dd8a..837ccd5600 100644
--- a/test/lisp/so-long-tests/spelling-tests.el
+++ b/test/lisp/so-long-tests/spelling-tests.el
@@ -40,7 +40,9 @@
            (condition-case ()
                (progn (ispell-check-version) t)
              (error nil))
-           (member "british" (ispell-valid-dictionary-list)))
+           (condition-case ()
+               (member "british" (ispell-valid-dictionary-list))
+             (error nil)))
   (ert-deftest so-long-spelling ()
     "Check the spelling in the source code."
     :tags '(:unstable) ;; It works for me, but I'm not sure about others.
-- 
2.34.0


[-- Attachment #3: spelling-tests.log --]
[-- Type: application/octet-stream, Size: 1437 bytes --]

Debugger entered--Lisp error: (error "Can't find Hunspell dictionary with a .aff affix f...")
  signal(error ("Can't find Hunspell dictionary with a .aff affix f..."))
  error("Can't find Hunspell dictionary with a .aff affix f...")
  ispell-find-hunspell-dictionaries()
  ispell-set-spellchecker-params()
  ispell-valid-dictionary-list()
  byte-code("\301\302!\210\301\303!\210\301\304!\210\10\203>\0\305\10!\203>\0\3061\"\0\307 \210\3100\202&\0\210\202>\0\203>\0\311\312 \235\203>\0\313\314..." [ispell-program-name require ert ispell cl-lib executable-find (error) ispell-check-version t "british" ispell-valid-dictionary-list ert-set-test so-long-spelling record ert-test "Check the spelling in the source code." #f(compiled-function () #<bytecode 0x63d714e81979f10>) nil :passed (:unstable)] 10)
  load("lisp/so-long-tests/spelling-tests" nil t)
  command-line-1(("-L" ":." "-L" "./../../elpa/packages/url-http-ntlm/" "-l" "./../../elpa/packages/url-http-ntlm/url-http-ntlm...." "-L" "./../../elpa/packages/web-server/" "-l" "./../../elpa/packages/web-server/web-server.el" "-l" "ert" "-L" "./../../elpa/packages/url-http-ntlm/" "-l" "./../../elpa/packages/url-http-ntlm/url-http-ntlm...." "-L" "./../../elpa/packages/web-server/" "-l" "./../../elpa/packages/web-server/web-server.el" "-l" "lisp/so-long-tests/spelling-tests" "--eval" "(ert-run-tests-batch-and-exit (quote (not (or (tag..."))
  command-line()
  normal-top-level()


[-- Attachment #4: flymake-tests.log --]
[-- Type: application/octet-stream, Size: 3141 bytes --]

Running 9 tests (2022-01-11 12:26:52+0100, selector `(not (or (tag :expensive-test) (tag :unstable) (tag :nativecomp)))')
Test different-diagnostic-types backtrace:
  signal(ert-test-failed (((should (eq 'flymake-error (face-at-point))
  ert-fail(((should (eq 'flymake-error (face-at-point))) :form (eq fly
  #f(compiled-function () #<bytecode -0x899aa44f89dbfa>)()
  flymake-tests--call-with-fixture(#f(compiled-function () #<bytecode 
  #f(compiled-function () #<bytecode -0x6f84e02efe25893>)()
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name different-diagnostic-types :documenta
  ert-run-or-rerun-test(#s(ert--stats :selector (not (or ... ... ...))
  ert-run-tests((not (or (tag :expensive-test) (tag :unstable) (tag :n
  ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable) (
  ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
  eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
  command-line-1(("-L" ":." "-L" "./../../elpa/packages/url-http-ntlm/
  command-line()
  normal-top-level()
Test different-diagnostic-types condition:
    (ert-test-failed
     ((should
       (eq 'flymake-error
	    (face-at-point)))
      :form
      (eq flymake-error flymake-warning)
      :value nil))
   FAILED  1/9  different-diagnostic-types (1.172453 sec)
   passed  2/9  dummy-backends (1.004546 sec)
   passed  3/9  eob-region-and-trailing-newline (0.000231 sec)
Test included-c-header-files backtrace:
  signal(ert-test-failed (((should (eq 'flymake-error (face-at-point))
  ert-fail(((should (eq 'flymake-error (face-at-point))) :form (eq fly
  #f(compiled-function () #<bytecode 0x6b624c6b834498c>)()
  flymake-tests--call-with-fixture(#f(compiled-function () #<bytecode 
  #f(compiled-function () #<bytecode 0x1b9738f3fe49e06d>)()
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name included-c-header-files :documentatio
  ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
  ert-run-tests((not (or (tag :expensive-test) (tag :unstable) (tag :n
  ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable) (
  ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
  eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
  command-line-1(("-L" ":." "-L" "./../../elpa/packages/url-http-ntlm/
  command-line()
  normal-top-level()
Test included-c-header-files condition:
    (ert-test-failed
     ((should
       (eq 'flymake-error
	    (face-at-point)))
      :form
      (eq flymake-error flymake-warning)
      :value nil))
   FAILED  4/9  included-c-header-files (1.061344 sec)
   passed  5/9  perl-backend (1.037435 sec)
   passed  6/9  recurrent-backend (1.011210 sec)
   passed  7/9  ruby-backend (1.049725 sec)
   passed  8/9  warning-predicate-function-gcc (1.075085 sec)
   passed  9/9  warning-predicate-rx-gcc (1.063238 sec)

Ran 9 tests, 7 results as expected, 2 unexpected (2022-01-11 12:27:01+0100, 8.685472 sec)

2 unexpected results:
   FAILED  different-diagnostic-types
   FAILED  included-c-header-files


[-- Attachment #5: gcc-tests.log --]
[-- Type: application/octet-stream, Size: 1641 bytes --]

Running 2 tests (2022-01-11 12:25:00+0100, selector `(not (or (tag :expensive-test) (tag :unstable) (tag :nativecomp)))')
   passed  1/2  semantic-gcc-test-output-parser (0.000334 sec)
Test semantic-gcc-test-output-parser-this-machine backtrace:
  signal(error ("Test failed on \"Configured with: --prefix=/Library..
  error("Test failed on %S\nV H P:\n%S %S %S" "Configured with: --pref
  semantic-gcc-test-output-parser()
  #f(compiled-function () #<bytecode 0x1f3bfaba4f5f647f>)()
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name semantic-gcc-test-output-parser-this-
  ert-run-or-rerun-test(#s(ert--stats :selector (not (or (tag :expensi
  ert-run-tests((not (or (tag :expensive-test) (tag :unstable) (tag :n
  ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable) (
  ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
  eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
  command-line-1(("-L" ":." "-L" "./../../elpa/packages/url-http-ntlm/
  command-line()
  normal-top-level()
Test semantic-gcc-test-output-parser-this-machine condition:
    (error "Test failed on \"Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1\"\nV H P:\nnil \"x86_64-apple-darwin20.6.0\" nil")
   FAILED  2/2  semantic-gcc-test-output-parser-this-machine (0.029720 sec)

Ran 2 tests, 1 results as expected, 1 unexpected (2022-01-11 12:25:01+0100, 0.114861 sec)

1 unexpected results:
   FAILED  semantic-gcc-test-output-parser-this-machine

Re: Emacs pretest 28.0.91 is out

[Michael Albinus]

Robert Pluim <rpluim@gmail.com> writes:

> +           (condition-case ()
> +               (member "british" (ispell-valid-dictionary-list))
> +             (error nil)))

aka (ignore-errors ...)

Best regards, Michael.

Re: Emacs pretest 28.0.91 is out

[Robert Pluim]

>>>>> On Tue, 11 Jan 2022 13:50:23 +0100, Michael Albinus <michael.albinus@gmx.de> said:

    Michael> Robert Pluim <rpluim@gmail.com> writes:
    >> +           (condition-case ()
    >> +               (member "british" (ispell-valid-dictionary-list))
    >> +             (error nil)))

    Michael> aka (ignore-errors ...)

Sure, but this is an emacs-28 pre-test, so I donʼt want to start
making cleanups :-)

Robert
-- 

Re: Emacs pretest 28.0.91 is out

[Robert Pluim]

>>>>> On Tue, 11 Jan 2022 12:43:55 +0100, Robert Pluim <rpluim@gmail.com> said:

>>>>> On Mon, 10 Jan 2022 16:39:40 -0600, Stefan Kangas <stefan@marxist.se> said:
    Stefan> Hi!
    Stefan> The second pretest for what will be the 28.1 release of Emacs (the
    Stefan> extensible text editor) is available at:

    Stefan> https://alpha.gnu.org/gnu/emacs/pretest/emacs-28.0.91.tar.xz

    Robert> I get three test failures on macOS with this (and zero on
    Robert> GNU/Linux). The spelling test one is because I think my hunspell
    Robert> installation is broken, but we can guard against it (see attached
    Robert> patch). The other two I suspect are because 'gcc' here is 'clang', not
    Robert> real gcc, so maybe those tests need to check for that. Logs attached.

I see the latter two are fixed on master already. I guess since this
is macOS specific weʼre not going to backport those to emacs-28.

Robert
-- 

Re: Emacs pretest 28.0.91 is out

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Tue, 11 Jan 2022 15:14:33 +0100
> Cc: emacs-devel@gnu.org
> 
> I see the latter two are fixed on master already. I guess since this
> is macOS specific weʼre not going to backport those to emacs-28.

If the fixes are simple enough, we could backport them  The test suite
is not really critical for the success of a release, so we can install
changes in it which we won't in the "main" code.

Re: Emacs pretest 28.0.91 is out

[Robert Pluim]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

>>>>> On Tue, 11 Jan 2022 19:06:44 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Date: Tue, 11 Jan 2022 15:14:33 +0100
    >> Cc: emacs-devel@gnu.org
    >> 
    >> I see the latter two are fixed on master already. I guess since this
    >> is macOS specific weʼre not going to backport those to emacs-28.

    Eli> If the fixes are simple enough, we could backport them  The test suite
    Eli> is not really critical for the success of a release, so we can install
    Eli> changes in it which we won't in the "main" code.

It would basically be the attached, although Iʼll note that the tests
theyʼre using to determine if gcc is clang are different.

Robert
-- 


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Don-t-fail-flymake-tests-if-gcc-actually-is-Clang.patch --]
[-- Type: text/x-diff, Size: 1995 bytes --]

From b4632b2afb0aff4d1b2d1c7fd40d7ee26b228eed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mattias=20Engdeg=C3=A5rd?= <mattiase@acm.org>
Date: Sun, 2 Jan 2022 13:00:13 +0100
Subject: [PATCH 1/2] Don't fail flymake-tests if `gcc` actually is Clang
To: emacs-devel@gnu.org

* test/lisp/progmodes/flymake-tests.el (flymake-tests--gcc-is-clang)
(different-diagnostic-types, included-c-header-files): Skip tests that
depend on the `gcc` command really being GCC and not Clang.

(cherry picked from commit b2167d98432a78442522b7564e22f47d75a98b6f)
---
 test/lisp/progmodes/flymake-tests.el | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/test/lisp/progmodes/flymake-tests.el b/test/lisp/progmodes/flymake-tests.el
index 2eb4004f10..45cabf2efb 100644
--- a/test/lisp/progmodes/flymake-tests.el
+++ b/test/lisp/progmodes/flymake-tests.el
@@ -140,9 +140,15 @@ ruby-backend
             (should (eq 'flymake-error (face-at-point)))))
       (delete-directory tempdir t))))
 
+(defun flymake-tests--gcc-is-clang ()
+  "Whether the `gcc' command actually runs the Clang compiler."
+  (string-match "[Cc]lang version "
+                (shell-command-to-string "gcc --version")))
+
 (ert-deftest different-diagnostic-types ()
   "Test GCC warning via function predicate."
   (skip-unless (and (executable-find "gcc")
+                    (not (flymake-tests--gcc-is-clang))
                     (version<=
                      "5" (string-trim
                           (shell-command-to-string "gcc -dumpversion")))
@@ -166,7 +172,9 @@ different-diagnostic-types
 
 (ert-deftest included-c-header-files ()
   "Test inclusion of .h header files."
-  (skip-unless (and (executable-find "gcc") (executable-find "make")))
+  (skip-unless (and (executable-find "gcc")
+                    (not (flymake-tests--gcc-is-clang))
+                    (executable-find "make")))
   (let ((flymake-wrap-around nil))
     (flymake-tests--with-flymake
         ("some-problems.h")
-- 
2.34.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Fix-test-lisp-cedet-semantic-bovine-gcc-tests-on-mac.patch --]
[-- Type: text/x-diff, Size: 1452 bytes --]

From d6c33d55def9f1e3021a418e6e3f3cf4be44cc68 Mon Sep 17 00:00:00 2001
From: Philipp Stephani <phst@google.com>
Date: Tue, 28 Dec 2021 21:05:23 +0100
Subject: [PATCH 2/2] Fix test lisp/cedet/semantic/bovine/gcc-tests on macOS
 (Bug#52431)
To: emacs-devel@gnu.org

* test/lisp/cedet/semantic/bovine/gcc-tests.el
(semantic-gcc-test-output-parser-this-machine): Also detect Apple
clang on macOS Monterey.

(cherry picked from commit 6e52becfbe2a33c025b8c4838b3c8f06ba5a6fb8)
---
 test/lisp/cedet/semantic/bovine/gcc-tests.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/test/lisp/cedet/semantic/bovine/gcc-tests.el b/test/lisp/cedet/semantic/bovine/gcc-tests.el
index 2ebd991679..2e61f91e58 100644
--- a/test/lisp/cedet/semantic/bovine/gcc-tests.el
+++ b/test/lisp/cedet/semantic/bovine/gcc-tests.el
@@ -127,8 +127,9 @@ semantic-gcc-test-output-parser-this-machine
     ;; Some macOS machines run llvm when you type gcc.  (!)
     ;; We can't even check if it's a symlink; it's a binary placed in
     ;; "/usr/bin/gcc".  So check the output and just skip this test if
-    ;; it says "Apple LLVM".
-    (unless (string-match "Apple LLVM" (car semantic-gcc-test-strings))
+    ;; it looks like that's the case.
+    (unless (string-match "Apple \\(LLVM\\|clang\\)\\|Xcode\\.app"
+                          (car semantic-gcc-test-strings))
         (semantic-gcc-test-output-parser))))
 
 ;;; gcc-tests.el ends here
-- 
2.34.0

Re: Emacs pretest 28.0.91 is out

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: stefan@marxist.se,  emacs-devel@gnu.org
> Date: Tue, 11 Jan 2022 18:45:09 +0100
> 
>     Eli> If the fixes are simple enough, we could backport them  The test suite
>     Eli> is not really critical for the success of a release, so we can install
>     Eli> changes in it which we won't in the "main" code.
> 
> It would basically be the attached, although Iʼll note that the tests
> theyʼre using to determine if gcc is clang are different.

I don't object to backporting those.

Re: [External] : Emacs pretest 28.0.91 is out

[H. Dieter Wilhelm]

Hi Corwin

Corwin Brust <corwin@bru.st> writes:

> I (and others) have volunteered to attempt to come up to speed with
> this.  I'm attempting to make dist on windows now but I'm very, very
> novice.   I'm optimistic one of us will get there, however.   I'll
> share a link to my build artifacts if I do manage to create some.

That'd be nice.  I'm able to build Emacs with MinGW2 for myself but I
still don't grok the package building procedure from Phillip Lord.  Did
you find some time to have a look?

    Dieter
-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: [External] : Emacs pretest 28.0.91 is out

[Corwin Brust]

Hi again!

On Tue, Jan 11, 2022 at 3:43 PM H. Dieter Wilhelm
<dieter@duenenhof-wilhelm.de> wrote:
>
> Hi Corwin
>
> Corwin Brust <corwin@bru.st> writes:
>
> > I (and others) have volunteered to attempt to come up to speed with
> > this.  I'm attempting to make dist on windows now but I'm very, very
> > novice.   I'm optimistic one of us will get there, however.   I'll
> > share a link to my build artifacts if I do manage to create some.

I've placed my very first successfully built redistributables for
windows into a repo on sourcehut.  I'd be grateful for any reports of
trouble, suggestions, or confirmation these work for others.

browse the tree:  https://git.sr.ht/~mplscorwin/emacs-w64/tree
clone the repo: https://git.sr.ht/~mplscorwin/emacs-w64

Please note that this build does **not** enable native-compilation nor
does it include gccjit (in deps).  I'm working on the assumption that
the Phillip's build scripts should be enhanced so we can build (and
distribute) windows binaries both with and without native compilation
enabled.

> That'd be nice.  I'm able to build Emacs with MinGW2 for myself but I
> still don't grok the package building procedure from Phillip Lord.  Did
> you find some time to have a look?

I don't have great notes on what I've done but here are a couple notes:

- I ended up creating ~/emacs-build and ~/emacs-upload rather than
messing with the scripts.
- I had to run build-zips and build-deps many, many times
- each failure required finding and install a missing msys package
then trying again
  # pacman -Ss <partial-name>
  # pacman -S <full_x86_64_name>
- this lead me to install sed via:
  # pacman -S mingw64/mingw-w64-x86_64-sed-HMM
- once I installed that version of sed Emacs' configure stopped working
- I "fixed" that by
  # mv /mingw64/bin/sed /mingw64/bin/sed
  # cp /usr/bin/sed /mingw64/bin

Also (as I think you know):
- build-dep-zips.py still has incorrect paths for MINGW sources:

# diff /c/Users/corwi/emacs-build/git/emacs-28/admin/nt/dist-build/build-dep-zips.py
/d/projects/emacs-28/admin/nt/dist-build/build-dep-zips.py
124,125c124,125
< #SRC_REPO="https://sourceforge.net/projects/msys2/files/REPOS/MINGW/Sources"
< SRC_REPO="https://repo.msys2.org/mingw/sources"
---
> SRC_REPO="https://sourceforge.net/projects/msys2/files/REPOS/MINGW/Sources"
>
170c170
<             "wget -a ../download.log -O ../emacs-src-cache/{} {}/{}"
---
>             "wget -a ../download.log -O ../emacs-src-cache/{} {}/{}/download"

> Best wishes

Re: Emacs pretest 28.0.91 is out

[Robert Pluim]

>>>>> On Tue, 11 Jan 2022 20:38:59 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: stefan@marxist.se,  emacs-devel@gnu.org
    >> Date: Tue, 11 Jan 2022 18:45:09 +0100
    >> 
    Eli> If the fixes are simple enough, we could backport them  The test suite
    Eli> is not really critical for the success of a release, so we can install
    Eli> changes in it which we won't in the "main" code.
    >> 
    >> It would basically be the attached, although Iʼll note that the tests
    >> theyʼre using to determine if gcc is clang are different.

    Eli> I don't object to backporting those.

Done. What about trapping errors from ispell-valid-dictionary-list in
lisp/so-long-tests/spelling-tests.el? I mean, my hunspell installation
is borked, because brew on macOS doesnʼt install any dictionaries by
default, so itʼs not entirely a test suite issue.

Robert
-- 

Re: Emacs pretest 28.0.91 is out

[Michael Albinus]

Robert Pluim <rpluim@gmail.com> writes:

Hi Robert,

> +(defun flymake-tests--gcc-is-clang ()
> +  "Whether the `gcc' command actually runs the Clang compiler."
> +  (string-match "[Cc]lang version "
> +                (shell-command-to-string "gcc --version")))

I don't know whether this can happen here, but *if* default-directory is
remote, the test runs on a wrong machine. Therefore, I wrap such calls
always with

(let ((default-directory temporary-file-directory))
  ...)

Best regards, Michael.

Re: [External] : Emacs pretest 28.0.91 is out

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Tue, 11 Jan 2022 22:07:41 -0600
> Cc: Po Lu <luangruo@yahoo.com>, Stefan Kangas <stefan@marxist.se>,
>  Drew Adams <drew.adams@oracle.com>,
>  "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> I've placed my very first successfully built redistributables for
> windows into a repo on sourcehut.  I'd be grateful for any reports of
> trouble, suggestions, or confirmation these work for others.

Thank you for your work on this.

> Please note that this build does **not** enable native-compilation nor
> does it include gccjit (in deps).  I'm working on the assumption that
> the Phillip's build scripts should be enhanced so we can build (and
> distribute) windows binaries both with and without native compilation
> enabled.

I'm not sure this is correct/justified.  Wouldn't it be better to have
just one build that could support both variants?  It is supposed to
work that way, but I don't think anyone tested this in practice.  It
would be good to see if that indeed works as intended, and if not,
report the issues which prevent that.

Specifically, I suggest to build Emacs _with_ native-compilation
support, then try using that on a system that has neither libgccjit
nor gcc/Binutils installed.

Thanks.

Re: Emacs pretest 28.0.91 is out

[Robert Pluim]

>>>>> On Wed, 12 Jan 2022 12:24:28 +0100, Michael Albinus <michael.albinus@gmx.de> said:

    Michael> Robert Pluim <rpluim@gmail.com> writes:
    Michael> Hi Robert,

    >> +(defun flymake-tests--gcc-is-clang ()
    >> +  "Whether the `gcc' command actually runs the Clang compiler."
    >> +  (string-match "[Cc]lang version "
    >> +                (shell-command-to-string "gcc --version")))

    Michael> I don't know whether this can happen here, but *if* default-directory is
    Michael> remote, the test runs on a wrong machine. Therefore, I wrap such calls
    Michael> always with

    Michael> (let ((default-directory temporary-file-directory))
    Michael>   ...)

I canʼt think of a way that default-directory would be remote when
running the test suite (except inside tramp's tests).

Robert
-- 

Re: Emacs pretest 28.0.91 is out

[Michael Albinus]

Robert Pluim <rpluim@gmail.com> writes:

>     Michael> I don't know whether this can happen here, but *if* default-directory is
>     Michael> remote, the test runs on a wrong machine. Therefore, I wrap such calls
>     Michael> always with
>
>     Michael> (let ((default-directory temporary-file-directory))
>     Michael>   ...)
>
> I canʼt think of a way that default-directory would be remote when
> running the test suite (except inside tramp's tests).

Somebody could call the tests interactively, from a buffer with a remote
default-directory. Unlikely, but possible.

> Robert

Best regards, Michael.

Re: Emacs pretest 28.0.91 is out

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: stefan@marxist.se,  emacs-devel@gnu.org
> Date: Wed, 12 Jan 2022 09:28:43 +0100
> 
>     Eli> I don't object to backporting those.
> 
> Done.

Thanks.

> What about trapping errors from ispell-valid-dictionary-list in
> lisp/so-long-tests/spelling-tests.el? I mean, my hunspell installation
> is borked, because brew on macOS doesnʼt install any dictionaries by
> default, so itʼs not entirely a test suite issue.

I'm not sure I understand what errors you allude to.  Can you tell
more?  (spelling-tests.el skips all tests on my machine, it seems
because the test expects Ispell-style dictionary names, which doesn't
work with Hunspell.)

Re: Emacs pretest 28.0.91 is out

[Robert Pluim]

>>>>> On Wed, 12 Jan 2022 15:35:42 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> What about trapping errors from ispell-valid-dictionary-list in
    >> lisp/so-long-tests/spelling-tests.el? I mean, my hunspell installation
    >> is borked, because brew on macOS doesnʼt install any dictionaries by
    >> default, so itʼs not entirely a test suite issue.

    Eli> I'm not sure I understand what errors you allude to.  Can you tell
    Eli> more?  (spelling-tests.el skips all tests on my machine, it seems
    Eli> because the test expects Ispell-style dictionary names, which doesn't
    Eli> work with Hunspell.)

From my original message:

Debugger entered--Lisp error: (error "Can't find Hunspell dictionary with a .aff affix f...")
  signal(error ("Can't find Hunspell dictionary with a .aff affix f..."))
  error("Can't find Hunspell dictionary with a .aff affix f...")
  ispell-find-hunspell-dictionaries()
  ispell-set-spellchecker-params()
  ispell-valid-dictionary-list()
  byte-code("\301\302!\210\301\303!\210\301\304!\210\10\203>\0\305\10!\203>\0\3061\"\0\307 \210\3100\202&\0\210\202>\0\203>\0\311\312 \235\203>\0\313\314..." [ispell-program-name require ert ispell cl-lib executable-find (error) ispell-check-version t "british" ispell-valid-dictionary-list ert-set-test so-long-spelling record ert-test "Check the spelling in the source code." #f(compiled-function () #<bytecode 0x63d714e81979f10>) nil :passed (:unstable)] 10)
  load("lisp/so-long-tests/spelling-tests" nil t)

This is because I have no hunspell dictionaries at all (and it would
be cleaner to define the test unconditionally, but skip it when
needed, but thatʼs another discussion).

Robert
-- 

Re: Emacs pretest 28.0.91 is out

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: stefan@marxist.se,  emacs-devel@gnu.org
> Date: Wed, 12 Jan 2022 15:15:08 +0100
> 
> Debugger entered--Lisp error: (error "Can't find Hunspell dictionary with a .aff affix f...")
>   signal(error ("Can't find Hunspell dictionary with a .aff affix f..."))
>   error("Can't find Hunspell dictionary with a .aff affix f...")
>   ispell-find-hunspell-dictionaries()
>   ispell-set-spellchecker-params()
>   ispell-valid-dictionary-list()
>   byte-code("\301\302!\210\301\303!\210\301\304!\210\10\203>\0\305\10!\203>\0\3061\"\0\307 \210\3100\202&\0\210\202>\0\203>\0\311\312 \235\203>\0\313\314..." [ispell-program-name require ert ispell cl-lib executable-find (error) ispell-check-version t "british" ispell-valid-dictionary-list ert-set-test so-long-spelling record ert-test "Check the spelling in the source code." #f(compiled-function () #<bytecode 0x63d714e81979f10>) nil :passed (:unstable)] 10)
>   load("lisp/so-long-tests/spelling-tests" nil t)
> 
> This is because I have no hunspell dictionaries at all (and it would
> be cleaner to define the test unconditionally, but skip it when
> needed, but thatʼs another discussion).

So you want to fix this?  I don't mind, but since it's (AFAIU)
something specific to your installation, is it important to fix on the
release branch?

Re: Emacs pretest 28.0.91 is out

[Robert Pluim]

>>>>> On Wed, 12 Jan 2022 16:22:53 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: stefan@marxist.se,  emacs-devel@gnu.org
    >> Date: Wed, 12 Jan 2022 15:15:08 +0100
    >> 
    >> Debugger entered--Lisp error: (error "Can't find Hunspell dictionary with a .aff affix f...")
    >> signal(error ("Can't find Hunspell dictionary with a .aff affix f..."))
    >> error("Can't find Hunspell dictionary with a .aff affix f...")
    >> ispell-find-hunspell-dictionaries()
    >> ispell-set-spellchecker-params()
    >> ispell-valid-dictionary-list()
    >> byte-code("\301\302!\210\301\303!\210\301\304!\210\10\203>\0\305\10!\203>\0\3061\"\0\307
    >> \210\3100\202&\0\210\202>\0\203>\0\311\312 \235\203>\0\313\314..."
    >> [ispell-program-name require ert ispell cl-lib executable-find
    >> (error) ispell-check-version t "british"
    >> ispell-valid-dictionary-list ert-set-test so-long-spelling record
    >> ert-test "Check the spelling in the source code."
    >> #f(compiled-function () #<bytecode 0x63d714e81979f10>) nil :passed
    >> (:unstable)] 10)
    >> load("lisp/so-long-tests/spelling-tests" nil t)
    >> 
    >> This is because I have no hunspell dictionaries at all (and it would
    >> be cleaner to define the test unconditionally, but skip it when
    >> needed, but thatʼs another discussion).

    Eli> So you want to fix this?  I don't mind, but since it's (AFAIU)
    Eli> something specific to your installation, is it important to fix on the
    Eli> release branch?

Iʼm not sure, which is why Iʼm asking you

Although, given that it works fine on GNU/Linux, perhaps let sleeping
tests lie. Who here hasn't pushed a last minute harmless bug fix that
caused problems? :-)

Robert
-- 

Re: Emacs pretest 28.0.91 is out

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: stefan@marxist.se,  emacs-devel@gnu.org
> Date: Wed, 12 Jan 2022 15:33:56 +0100
> 
>     Eli> So you want to fix this?  I don't mind, but since it's (AFAIU)
>     Eli> something specific to your installation, is it important to fix on the
>     Eli> release branch?
> 
> Iʼm not sure, which is why Iʼm asking you
> 
> Although, given that it works fine on GNU/Linux, perhaps let sleeping
> tests lie. Who here hasn't pushed a last minute harmless bug fix that
> caused problems? :-)

Yes, probably.

Thanks.

Re: [External] : Emacs pretest 28.0.91 is out

[H. Dieter Wilhelm]

Hi again

Corwin Brust <corwin@bru.st> writes:

> Hi again!
>
> On Tue, Jan 11, 2022 at 3:43 PM H. Dieter Wilhelm
> <dieter@duenenhof-wilhelm.de> wrote:
>>
>> Hi Corwin
>>
>> Corwin Brust <corwin@bru.st> writes:
>>
>> > I (and others) have volunteered to attempt to come up to speed with
>> > this.  I'm attempting to make dist on windows now but I'm very, very
>> > novice.   I'm optimistic one of us will get there, however.   I'll
>> > share a link to my build artifacts if I do manage to create some.
>
> I've placed my very first successfully built redistributables for
> windows into a repo on sourcehut.  I'd be grateful for any reports of
> trouble, suggestions, or confirmation these work for others.

I used your installer successfully. :-)

> browse the tree:  https://git.sr.ht/~mplscorwin/emacs-w64/tree
> clone the repo: https://git.sr.ht/~mplscorwin/emacs-w64
>
> ...

> - I ended up creating ~/emacs-build and ~/emacs-upload rather than
> messing with the scripts.
> - I had to run build-zips and build-deps many, many times
> - each failure required finding and install a missing msys package
> then trying again
>   # pacman -Ss <partial-name>
>   # pacman -S <full_x86_64_name>

   - had additionally to install: mingw-w64-x86_64-lerc,
     mingw-w64-x86_64-tzdata, some scr tgz with 0 size in emacs-src!
   - brotli compression library
   - pacman -S zip unzip  mingw-w64-x86_64-ntldd-git

> - this lead me to install sed via:
>   # pacman -S mingw64/mingw-w64-x86_64-sed-HMM
> - once I installed that version of sed Emacs' configure stopped working
> - I "fixed" that by
>   # mv /mingw64/bin/sed /mingw64/bin/sed
>   # cp /usr/bin/sed /mingw64/bin

Strange, I had no problems with sed..

> Also (as I think you know):
> - build-dep-zips.py still has incorrect paths for MINGW sources:

Yes, can't recollect which emacs-developer pointed me to the latest
address

> # diff /c/Users/corwi/emacs-build/git/emacs-28/admin/nt/dist-build/build-dep-zips.py
> /d/projects/emacs-28/admin/nt/dist-build/build-dep-zips.py
> 124,125c124,125
> < #SRC_REPO="https://sourceforge.net/projects/msys2/files/REPOS/MINGW/Sources"
> < SRC_REPO="https://repo.msys2.org/mingw/sources"


        Dieter

-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: [External] : Emacs pretest 28.0.91 is out

[H. Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Corwin Brust <corwin@bru.st>
>> Date: Tue, 11 Jan 2022 22:07:41 -0600
>> Cc: Po Lu <luangruo@yahoo.com>, Stefan Kangas <stefan@marxist.se>,
>>  Drew Adams <drew.adams@oracle.com>,
>>  "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>> 
>> Please note that this build does **not** enable native-compilation nor
>> does it include gccjit (in deps).  I'm working on the assumption that
>> the Phillip's build scripts should be enhanced so we can build (and
>> distribute) windows binaries both with and without native compilation
>> enabled.

> I'm not sure this is correct/justified.  Wouldn't it be better to have
> just one build that could support both variants?  It is supposed to
> work that way, but I don't think anyone tested this in practice.  It
> would be good to see if that indeed works as intended, and if not,
> report the issues which prevent that.

I don't quite understand, does this mean that ALL .elc files are getting
.eln companions?  

Or can this work as under Gnu-Linux with JIT compilation?

> Specifically, I suggest to build Emacs _with_ native-compilation
> support, then try using that on a system that has neither libgccjit
> nor gcc/Binutils installed.

OK, I can check this in the office.

       Dieter
-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: [External] : Emacs pretest 28.0.91 is out

[Eli Zaretskii]

> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> Cc: Corwin Brust <corwin@bru.st>,  luangruo@yahoo.com,  stefan@marxist.se,
>   drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Wed, 12 Jan 2022 22:15:57 +0100
> 
> > I'm not sure this is correct/justified.  Wouldn't it be better to have
> > just one build that could support both variants?  It is supposed to
> > work that way, but I don't think anyone tested this in practice.  It
> > would be good to see if that indeed works as intended, and if not,
> > report the issues which prevent that.
> 
> I don't quite understand, does this mean that ALL .elc files are getting
> .eln companions?  

Not necessarily.  If you use the "normal" build procedure, only the
Lisp files that are preloaded (and a few additional support files)
will be natively compiled, the rest will be left as *.elc files.

But I'm not sure I understand why you are asking this.

> Or can this work as under Gnu-Linux with JIT compilation?

If libgccjit is not available, Emacs should use the *.elc files.

Re: [External] : Emacs pretest 28.0.91 is out

[H. Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
>> Cc: Corwin Brust <corwin@bru.st>,  luangruo@yahoo.com,  stefan@marxist.se,
>>   drew.adams@oracle.com,  emacs-devel@gnu.org
>> Date: Wed, 12 Jan 2022 22:15:57 +0100
>> 
>> > I'm not sure this is correct/justified.  Wouldn't it be better to have
>> > just one build that could support both variants?  It is supposed to
>> > work that way, but I don't think anyone tested this in practice.  It
>> > would be good to see if that indeed works as intended, and if not,
>> > report the issues which prevent that.
>> 
>> I don't quite understand, does this mean that ALL .elc files are getting
>> .eln companions?  
>
> Not necessarily.  If you use the "normal" build procedure, only the
> Lisp files that are preloaded (and a few additional support files)
> will be natively compiled, the rest will be left as *.elc files.

Indeed, I observed this behaviour under MinGW2.

> But I'm not sure I understand why you are asking this.

I wanted to know if it makes sense (and is possible) to natively compile
all *.elc files for Windows? :-)

>> Or can this work as under Gnu-Linux with JIT compilation?
>
> If libgccjit is not available, Emacs should use the *.elc files.

I thought this. I'm also wondering how much the additional .eln files
will enlarge the Emacs distribution..

Thank you

      Dieter
-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: [External] : Emacs pretest 28.0.91 is out

[Eli Zaretskii]

> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> Cc: corwin@bru.st,  luangruo@yahoo.com,  stefan@marxist.se,
>   drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Thu, 13 Jan 2022 08:15:33 +0100
> 
> I wanted to know if it makes sense (and is possible) to natively compile
> all *.elc files for Windows? :-)

It's possible, yes -- as long as you are talking about the *.elc files
that come with Emacs.  The 3rd-party packages people might install are
not under your control anyway, so "total" compilation doesn't
necessarily make sense.  E.g., if J.R. Hacker never uses the package
foo.el that is part of the Emacs source distribution, having the
foo-*.eln file in the binary distribution will not help him.

If you want to compile all the bundled *.el files, you should set
NATIVE_FULL_AOT=1 in the environment or on the Make command line.

My opinion is that we should first offer the MS-Windows users a build
made using the "normal" procedure, and that means natively-compiling
only the preloaded files.  Only if we discover some good reasons to
offer a full AOT compilation should we do that (and maybe then not
only on Windows).

But it's your call.

> > If libgccjit is not available, Emacs should use the *.elc files.
> 
> I thought this. I'm also wondering how much the additional .eln files
> will enlarge the Emacs distribution..

An average .eln file is around 300KB, so it's quite a lot.  E.g., my
eln-cache directory for the 28.0.91 pretest, which includes only those
packages that I used since the session started 3 days ago, has 148
files that weigh in at about 48MB.

Re: [External] : Emacs pretest 28.0.91 is out

[H. Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:

> My opinion is that we should first offer the MS-Windows users a build
> made using the "normal" procedure, and that means natively-compiling
> only the preloaded files.  Only if we discover some good reasons to
> offer a full AOT compilation should we do that (and maybe then not
> only on Windows).

I'll check over the weekend if such a build is running on a Windows
system without MSYS installed.

Thank you for your guidance

      Dieter
-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany