GNU bug report logs - #22582
25.0.90; package-test fail on w64

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22582 in the body.
You can then email your comments to 22582 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.90; package-test fail on w64
Date: Sun, 7 Feb 2016 15:25:42 +0100

[Message part 1 (text/plain, inline)]

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))

[Message part 2 (text/html, inline)]

Message #8 received at 22582 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> gmail.com>
Cc: 22582 <at> debbugs.gnu.org
Subject: Re: bug#22582: 25.0.90; package-test fail on w64
Date: Sun, 07 Feb 2016 20:02:34 +0200

> From: Fabrice Popineau <fabrice.popineau <at> 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?

Message #11 received at 22582 <at> debbugs.gnu.org (full text, mbox):

From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22582 <at> debbugs.gnu.org
Subject: Re: bug#22582: 25.0.90; package-test fail on w64
Date: Sun, 7 Feb 2016 20:17:59 +0100

[Message part 1 (text/plain, inline)]

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 <at> gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau <at> 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?
>

[Message part 2 (text/html, inline)]

[package-test.log (application/octet-stream, attachment)]

Message #14 received at 22582 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> gmail.com>
Cc: 22582 <at> debbugs.gnu.org
Subject: Re: bug#22582: 25.0.90; package-test fail on w64
Date: Sun, 07 Feb 2016 22:50:55 +0200

> From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
> Date: Sun, 7 Feb 2016 20:17:59 +0100
> Cc: 22582 <at> 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.")

Message #17 received at 22582 <at> debbugs.gnu.org (full text, mbox):

From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22582 <at> debbugs.gnu.org
Subject: Re: bug#22582: 25.0.90; package-test fail on w64
Date: Mon, 8 Feb 2016 11:04:49 +0100

[Message part 1 (text/plain, inline)]

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 <at> gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
> > Date: Sun, 7 Feb 2016 20:17:59 +0100
> > Cc: 22582 <at> 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.")
>
>

[Message part 2 (text/html, inline)]

Message #20 received at 22582 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fabrice Popineau <fabrice.popineau <at> gmail.com>
Cc: 22582 <at> debbugs.gnu.org
Subject: Re: bug#22582: 25.0.90; package-test fail on w64
Date: Mon, 08 Feb 2016 19:19:47 +0200

> From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
> Date: Mon, 8 Feb 2016 11:04:49 +0100
> Cc: 22582 <at> 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.

Message #23 received at 22582 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22582 <at> debbugs.gnu.org, Fabrice Popineau <fabrice.popineau <at> gmail.com>
Subject: Re: bug#22582: 25.0.90; package-test fail on w64
Date: Sat, 25 Feb 2017 12:58:55 -0500

tags 22582 fixed
close 22582 26.1
quit

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
>> Date: Mon, 8 Feb 2016 11:04:49 +0100
>> Cc: 22582 <at> 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)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.