* bug#22582: 25.0.90; package-test fail on w64
@ 2016-02-07 14:25 Fabrice Popineau
2016-02-07 18:02 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Fabrice Popineau @ 2016-02-07 14:25 UTC (permalink / raw)
To: 22582
[-- 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 --]
^ permalink raw reply related [flat|nested] 7+ messages in thread
* bug#22582: 25.0.90; package-test fail on w64
2016-02-07 14:25 bug#22582: 25.0.90; package-test fail on w64 Fabrice Popineau
@ 2016-02-07 18:02 ` Eli Zaretskii
2016-02-07 19:17 ` Fabrice Popineau
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2016-02-07 18:02 UTC (permalink / raw)
To: Fabrice Popineau; +Cc: 22582
> 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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#22582: 25.0.90; package-test fail on w64
2016-02-07 18:02 ` Eli Zaretskii
@ 2016-02-07 19:17 ` Fabrice Popineau
2016-02-07 20:50 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Fabrice Popineau @ 2016-02-07 19:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22582
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#22582: 25.0.90; package-test fail on w64
2016-02-07 19:17 ` Fabrice Popineau
@ 2016-02-07 20:50 ` Eli Zaretskii
2016-02-08 10:04 ` Fabrice Popineau
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2016-02-07 20:50 UTC (permalink / raw)
To: Fabrice Popineau; +Cc: 22582
> 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.")
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#22582: 25.0.90; package-test fail on w64
2016-02-07 20:50 ` Eli Zaretskii
@ 2016-02-08 10:04 ` Fabrice Popineau
2016-02-08 17:19 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Fabrice Popineau @ 2016-02-08 10:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22582
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#22582: 25.0.90; package-test fail on w64
2016-02-08 10:04 ` Fabrice Popineau
@ 2016-02-08 17:19 ` Eli Zaretskii
2017-02-25 17:58 ` npostavs
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2016-02-08 17:19 UTC (permalink / raw)
To: Fabrice Popineau; +Cc: 22582
> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#22582: 25.0.90; package-test fail on w64
2016-02-08 17:19 ` Eli Zaretskii
@ 2017-02-25 17:58 ` npostavs
0 siblings, 0 replies; 7+ messages in thread
From: npostavs @ 2017-02-25 17:58 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Fabrice Popineau, 22582
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)
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-02-25 17:58 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-07 14:25 bug#22582: 25.0.90; package-test fail on w64 Fabrice Popineau
2016-02-07 18:02 ` Eli Zaretskii
2016-02-07 19:17 ` Fabrice Popineau
2016-02-07 20:50 ` Eli Zaretskii
2016-02-08 10:04 ` Fabrice Popineau
2016-02-08 17:19 ` Eli Zaretskii
2017-02-25 17:58 ` npostavs
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.