bug#22582: 25.0.90; package-test fail on w64

bug#22582: 25.0.90; package-test fail on w64

[Fabrice Popineau]

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

The are 2 failures.

One can be fixed simply by patching test/automated/package-test.el in
the following way:

diff --git a/test/automated/package-test.el b/test/automated/package-test.el
index e10946e..e2526e3 100644
--- a/test/automated/package-test.el
+++ b/test/automated/package-test.el
@@ -246,12 +246,15 @@ package-test-desc-version-string
   "Install a package which includes a dependency."
   (with-package-test (:basedir "data/package")
     (package-install-file (expand-file-name "macro-problem-package-1.0/"))
-    (require 'macro-problem)
+    (load-library "macro-aux")
+    (load-library "macro-problem")
     ;; `macro-problem-func' uses a macro from `macro-aux'.
     (should (equal (macro-problem-func) '(progn a b)))
     (package-install-file (expand-file-name "macro-problem-package-2.0/"))
     ;; After upgrading, `macro-problem-func' depends on a new version
     ;; of the macro from `macro-aux'.
+    (load-library "macro-aux")
+    (load-library "macro-problem")
     (should (equal (macro-problem-func) '(1 b)))
     ;; `macro-problem-10-and-90' depends on an entirely new macro from
`macro-aux'.
     (should (equal (macro-problem-10-and-90) '(10 90)))))

My question is: when you ``(require 'macro-problem)'',
should the package mechanism be clever enough to reload the files
when you upgrade the package? Because clearly it doesn't happen
there.

Second problem directly related to the underlying platform: the
connection to http://0.0.0.0:8000/ fails with a 10049 error.
This error is frequently reported on forums (see
http://www.sockets.com/err_lst1.htm for example).
I don't know what is the best fix.

diff --git a/test/automated/package-test.el b/test/automated/package-test.el
index e10946e..e2526e3 100644
--- a/test/automated/package-test.el
+++ b/test/automated/package-test.el
@@ -374,7 +377,7 @@ package-test-desc-version-string
   (skip-unless (not (getenv "NIX_STORE")))
   (with-package-test (:basedir
                       package-test-data-dir
-                      :location "http://0.0.0.0:8000/")
+                      :location "http://127.0.0.1:8000/")
     (let* ((package-menu-async t)
            (process (start-process
                      "package-server" "package-server-buffer"




In GNU Emacs 25.0.90.10 (x86_64-w64-mingw32)
 of 2016-02-07 built on LOBSANG
Repository revision: 9a71f062ce6e610a8206108f551ad029ebac6d33
Windowing system distributor 'Microsoft Corp.', version 10.0.10586
Configured using:
 'configure --prefix=/c/Local/Emacs --libexecdir=/c/Local/Emacs/bin
 --datarootdir=/c/Local/Emacs --localstatedir=/c/Local/Emacs
 --sysconfdir=/c/Local/Emacs/etc --with-jpeg --with-xpm --with-png
 --with-tiff --with-rsvg --with-xml2 --with-gnutls --without-imagemagick
 --enable-checking=no 'CFLAGS=-I/mingw64/include -fomit-frame-pointer
 -O3 -g0 -mtune=corei7' CPPFLAGS=-I/mingw64/include
 LDFLAGS=-L/mingw64/lib'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: fr_FR
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec epg epg-config gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util help-fns help-mode easymenu cl-loaddefs pcase
cl-lib mail-prsvr mail-utils time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
disp-table w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic 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 charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote w32notify dbusbind w32 multi-tty
make-network-process emacs)

Memory information:
((conses 16 88612 6686)
 (symbols 56 19622 0)
 (miscs 48 37 105)
 (strings 32 15786 3899)
 (string-bytes 1 424977)
 (vectors 16 11609)
 (vector-slots 8 414040 4736)
 (floats 8 161 43)
 (intervals 56 256 6)
 (buffers 976 12))

[-- Attachment #2: Type: text/html, Size: 7021 bytes --]

bug#22582: 25.0.90; package-test fail on w64

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sun, 7 Feb 2016 15:25:42 +0100
> 
> The are 2 failures.
> 
> One can be fixed simply by patching test/automated/package-test.el in
> the following way:
> 
> diff --git a/test/automated/package-test.el b/test/automated/package-test.el
> index e10946e..e2526e3 100644
> --- a/test/automated/package-test.el
> +++ b/test/automated/package-test.el
> @@ -246,12 +246,15 @@ package-test-desc-version-string
> "Install a package which includes a dependency."
> (with-package-test (:basedir "data/package")
> (package-install-file (expand-file-name "macro-problem-package-1.0/"))
> - (require 'macro-problem)
> + (load-library "macro-aux")
> + (load-library "macro-problem")
> ;; `macro-problem-func' uses a macro from `macro-aux'.
> (should (equal (macro-problem-func) '(progn a b)))
> (package-install-file (expand-file-name "macro-problem-package-2.0/"))
> ;; After upgrading, `macro-problem-func' depends on a new version
> ;; of the macro from `macro-aux'.
> + (load-library "macro-aux")
> + (load-library "macro-problem")
> (should (equal (macro-problem-func) '(1 b)))
> ;; `macro-problem-10-and-90' depends on an entirely new macro from `macro-aux'.
> (should (equal (macro-problem-10-and-90) '(10 90)))))
> 
> My question is: when you ``(require 'macro-problem)'',
> should the package mechanism be clever enough to reload the files
> when you upgrade the package? Because clearly it doesn't happen
> there.
> 
> Second problem directly related to the underlying platform: the
> connection to http://0.0.0.0:8000/ fails with a 10049 error.
> This error is frequently reported on forums (see
> http://www.sockets.com/err_lst1.htm for example).
> I don't know what is the best fix.
> 
> diff --git a/test/automated/package-test.el b/test/automated/package-test.el
> index e10946e..e2526e3 100644
> --- a/test/automated/package-test.el
> +++ b/test/automated/package-test.el
> @@ -374,7 +377,7 @@ package-test-desc-version-string
> (skip-unless (not (getenv "NIX_STORE")))
> (with-package-test (:basedir
> package-test-data-dir
> - :location "http://0.0.0.0:8000/")
> + :location "http://127.0.0.1:8000/")
> (let* ((package-menu-async t)
> (process (start-process
> "package-server" "package-server-buffer"

Strangely enough, none of that happens to me, the test passes with
flying colors.

Can you post the full contents of your package-test.log?

bug#22582: 25.0.90; package-test fail on w64

[Fabrice Popineau]

[-- Attachment #1.1: Type: text/plain, Size: 2977 bytes --]

Ok, closing the first part of the bug report: it is working as expected at
this point.
Two days ago, I had to debug this (require 'macro-problem) thing
and I came up with explicitly loading the libraries to make it work.

The second problem is still there. Under Windows 10 and my setup, a 10049
error is reported
when trying to connect to  http://0.0.0.0:8000/

Log file attached.

Fabrice



2016-02-07 19:02 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Sun, 7 Feb 2016 15:25:42 +0100
> >
> > The are 2 failures.
> >
> > One can be fixed simply by patching test/automated/package-test.el in
> > the following way:
> >
> > diff --git a/test/automated/package-test.el
> b/test/automated/package-test.el
> > index e10946e..e2526e3 100644
> > --- a/test/automated/package-test.el
> > +++ b/test/automated/package-test.el
> > @@ -246,12 +246,15 @@ package-test-desc-version-string
> > "Install a package which includes a dependency."
> > (with-package-test (:basedir "data/package")
> > (package-install-file (expand-file-name "macro-problem-package-1.0/"))
> > - (require 'macro-problem)
> > + (load-library "macro-aux")
> > + (load-library "macro-problem")
> > ;; `macro-problem-func' uses a macro from `macro-aux'.
> > (should (equal (macro-problem-func) '(progn a b)))
> > (package-install-file (expand-file-name "macro-problem-package-2.0/"))
> > ;; After upgrading, `macro-problem-func' depends on a new version
> > ;; of the macro from `macro-aux'.
> > + (load-library "macro-aux")
> > + (load-library "macro-problem")
> > (should (equal (macro-problem-func) '(1 b)))
> > ;; `macro-problem-10-and-90' depends on an entirely new macro from
> `macro-aux'.
> > (should (equal (macro-problem-10-and-90) '(10 90)))))
> >
> > My question is: when you ``(require 'macro-problem)'',
> > should the package mechanism be clever enough to reload the files
> > when you upgrade the package? Because clearly it doesn't happen
> > there.
> >
> > Second problem directly related to the underlying platform: the
> > connection to http://0.0.0.0:8000/ fails with a 10049 error.
> > This error is frequently reported on forums (see
> > http://www.sockets.com/err_lst1.htm for example).
> > I don't know what is the best fix.
> >
> > diff --git a/test/automated/package-test.el
> b/test/automated/package-test.el
> > index e10946e..e2526e3 100644
> > --- a/test/automated/package-test.el
> > +++ b/test/automated/package-test.el
> > @@ -374,7 +377,7 @@ package-test-desc-version-string
> > (skip-unless (not (getenv "NIX_STORE")))
> > (with-package-test (:basedir
> > package-test-data-dir
> > - :location "http://0.0.0.0:8000/")
> > + :location "http://127.0.0.1:8000/")
> > (let* ((package-menu-async t)
> > (process (start-process
> > "package-server" "package-server-buffer"
>
> Strangely enough, none of that happens to me, the test passes with
> flying colors.
>
> Can you post the full contents of your package-test.log?
>

[-- Attachment #1.2: Type: text/html, Size: 4399 bytes --]

[-- Attachment #2: package-test.log --]
[-- Type: application/octet-stream, Size: 16906 bytes --]

bug#22582: 25.0.90; package-test fail on w64

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sun, 7 Feb 2016 20:17:59 +0100
> Cc: 22582@debbugs.gnu.org
> 
> The second problem is still there. Under Windows 10 and my setup, a 10049 error is reported
> when trying to connect to http://0.0.0.0:8000/

Thanks.  I guess it's something new with Windows 10, then.  (Error
10049 means "The requested address is not valid in its context.")

bug#22582: 25.0.90; package-test fail on w64

[Fabrice Popineau]

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

If I run the package-test-server.py and I try to connect from a browser with
http://0.0.0.0:8000/archive-contents, I get ERR_ADDRESS_INVALID.

But that I have the same error if I try to open:
http://xx.xx.xx.xx:8000/archive-contents with xx.xx.xx.xx being my current
IP address.

I get the file only if I connect to http://127.0.0.1:8000/archive-contents.

So I suspect that it is a default setting of the firewall in Windows 10.

The python server script
test/automated/data/package/package-test-server.py
runs explicitly on 127.0.0.1, so why not using this address in the test?
What does using 0.0.0.0 brings here in the
package-test-update-archives-async test?


Fabrice


2016-02-07 21:50 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Sun, 7 Feb 2016 20:17:59 +0100
> > Cc: 22582@debbugs.gnu.org
> >
> > The second problem is still there. Under Windows 10 and my setup, a
> 10049 error is reported
> > when trying to connect to http://0.0.0.0:8000/
>
> Thanks.  I guess it's something new with Windows 10, then.  (Error
> 10049 means "The requested address is not valid in its context.")
>
>

[-- Attachment #2: Type: text/html, Size: 2093 bytes --]

bug#22582: 25.0.90; package-test fail on w64

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Mon, 8 Feb 2016 11:04:49 +0100
> Cc: 22582@debbugs.gnu.org
> 
> If I run the package-test-server.py and I try to connect from a browser with
> http://0.0.0.0:8000/archive-contents, I get ERR_ADDRESS_INVALID.
> 
> But that I have the same error if I try to open:
> http://xx.xx.xx.xx:8000/archive-contents with xx.xx.xx.xx being my current IP address.
> 
> I get the file only if I connect to http://127.0.0.1:8000/archive-contents.
> 
> So I suspect that it is a default setting of the firewall in Windows 10.
> 
> The python server script 
> test/automated/data/package/package-test-server.py
> runs explicitly on 127.0.0.1, so why not using this address in the test?
> What does using 0.0.0.0 brings here in the package-test-update-archives-async test?

I don't know.  Perhaps someone else does.

Failing that, maybe we should just make the change and see who
hollers.

bug#22582: 25.0.90; package-test fail on w64

[npostavs]

tags 22582 fixed
close 22582 26.1
quit

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Fabrice Popineau <fabrice.popineau@gmail.com>
>> Date: Mon, 8 Feb 2016 11:04:49 +0100
>> Cc: 22582@debbugs.gnu.org
>> 
>> If I run the package-test-server.py and I try to connect from a browser with
>> http://0.0.0.0:8000/archive-contents, I get ERR_ADDRESS_INVALID.
>> 
>> But that I have the same error if I try to open:
>> http://xx.xx.xx.xx:8000/archive-contents with xx.xx.xx.xx being my current IP address.
>> 
>> I get the file only if I connect to http://127.0.0.1:8000/archive-contents.
>> 
>> So I suspect that it is a default setting of the firewall in Windows 10.
>> 
>> The python server script 
>> test/automated/data/package/package-test-server.py
>> runs explicitly on 127.0.0.1, so why not using this address in the test?
>> What does using 0.0.0.0 brings here in the package-test-update-archives-async test?
>
> I don't know.  Perhaps someone else does.
>
> Failing that, maybe we should just make the change and see who
> hollers.

Done [1: 546d30ed14].

1: 2017-02-25 12:56:09 -0500 546d30ed1400d5a434886790a102bd37ec852919
  Don't use IP 0.0.0.0 for package test server (Bug#22582)