GNU bug report logs - #36725
26.1; Emacs can't connect to gnu elpa

Previous Next

Package: emacs;

Reported by: Lennard Henze <henzelen <at> hu-berlin.de>

Date: Thu, 18 Jul 2019 23:28:01 UTC

Severity: normal

Merged with 36749, 36810, 36873, 37453, 43708

Found in versions 26.1, 26.2

Fixed in versions 26.2.90, 26.3

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Thu, 18 Jul 2019 23:28:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Lennard Henze <henzelen <at> hu-berlin.de>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Thu, 18 Jul 2019 23:28:02 GMT) Full text and rfc822 format available.

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

From: Lennard Henze <henzelen <at> hu-berlin.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1; Emacs can't connect to gnu elpa
Date: Thu, 18 Jul 2019 21:28:45 +0200
Trying to use "use-package" to install evil-mode. use-package showed:
cant access: https://elpa.gnu.org/packages/undo-tree.html :Bad request
Tryed to package-install w/o use-package: other repos worked,
elpa.gnu.org did not work. tried other repos:
first popkit @ http://elpa.popkit.org/packages/ ... did not work, same
problem
than tried http://elpa.emacs-china.org/gnu/ ... did work, no idea why
https://elpa.gnu.org/packages/undo-tree.html was available the whole
time with curl, and even with emacs built in browser.
dont know if it really is a bug, but i tried trubbleshooting other stuff
on my os (5.2.1-arch1-1-ARCH). First had emacs 26.2, than downgraded to
26.1 bug was in both versions.

Fresh install, only change is .emacs:
(setq package-archives
'(("gnu" . "http://elpa.emacs-china.org/gnu/")
("melpa" . "https://melpa.org/packages/")
("org" . "https://orgmode.org/elpa/")))

(require 'package)
(package-initialize)

(unless (package-installed-p 'use-package)
(package-refresh-contents)
(package-install 'use-package))

(require 'use-package)

(use-package evil
:ensure t
:config
(evil-mode 1))
(custom-set-variables
'(package-selected-packages
(quote
(ghci-completion bnf-mode yasnippet undo-tree use-package))))
(custom-set-faces
)


Hope this helps!
Thanks for doing this :)

In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.7)
of 2019-03-17 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.12005000
Recent messages:
user-error: Not defining or executing kbd macro
Building list of manual directory expansions...
Building completion list of all manual topics...
Quit
Making completion list...
Quit
Type C-w C-o to remove help window.
Type "q" in help window to restore its previous buffer.
delete-backward-char: Text is read-only [2 times]
Making completion list... [2 times]

Configured using:
'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules
'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
-fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 MODULES THREADS LIBSYSTEMD LCMS2

Important settings:
value of $LC_COLLATE: C
value of $LC_TIME: de_DE.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
shell-dirtrack-mode: t
evil-mode: t
evil-local-mode: t
global-undo-tree-mode: t
undo-tree-mode: t
override-global-mode: t
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
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail eieio-opt speedbar sb-image
ezimage dframe find-func help-fns apropos woman man macros pp cus-edit
cus-start cus-load wid-edit evil evil-keybindings evil-integration
evil-maps evil-commands ffap reveal flyspell ispell evil-jumps
evil-command-window evil-types evil-macros evil-repeat evil-search
evil-ex shell pcomplete evil-states evil-core advice evil-common
windmove thingatpt rect evil-digraphs evil-vars tar-mode undo-tree
warnings edmacro kmacro diff cl compile comint ansi-color ring elec-pair
autoload radix-tree lisp-mnt mm-archive message dired dired-loaddefs
format-spec rfc822 mml mml-sec epa derived epg gnus-util rmail
rmail-loaddefs mailabbrev gmm-utils mailheader mm-decode mm-bodies
mm-encode mail-utils network-stream starttls url-http tls gnutls
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw
nsm rmc puny url-cache url-auth url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util mailcap cl-extra
help-mode use-package use-package-ensure use-package-delight
use-package-diminish use-package-bind-key bind-key easy-mmode
use-package-core finder-inf info package easymenu epg-config
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors 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 composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray 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 dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 444813 39048)
(symbols 48 34765 2)
(miscs 40 141 358)
(strings 32 119393 15581)
(string-bytes 1 2904208)
(vectors 16 31047)
(vector-slots 8 706702 34064)
(floats 8 87 292)
(intervals 56 777 0)
(buffers 992 19))





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Thu, 18 Jul 2019 23:50:02 GMT) Full text and rfc822 format available.

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Lennard Henze <henzelen <at> hu-berlin.de>
Cc: 36725 <at> debbugs.gnu.org
Subject: Re: bug#36725: 26.1; Emacs can't connect to gnu elpa
Date: Thu, 18 Jul 2019 19:49:39 -0400
Lennard Henze <henzelen <at> hu-berlin.de> writes:

> Trying to use "use-package" to install evil-mode. use-package showed:
> cant access: https://elpa.gnu.org/packages/undo-tree.html :Bad request

> on my os (5.2.1-arch1-1-ARCH). First had emacs 26.2, than downgraded to
> 26.1 bug was in both versions.

Does (setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3") help?  If
yes, this is likely Bug#34341 (should already be fixed already in
emacs-26, and the 26.2.90 pretest).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 08:47:01 GMT) Full text and rfc822 format available.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Lennard Henze <henzelen <at> hu-berlin.de>, 36725 <at> debbugs.gnu.org
Subject: Re: bug#36725: 26.1; Emacs can't connect to gnu elpa
Date: Fri, 19 Jul 2019 10:45:50 +0200
>>>>> On Thu, 18 Jul 2019 19:49:39 -0400, Noam Postavsky <npostavs <at> gmail.com> said:

    Noam> Lennard Henze <henzelen <at> hu-berlin.de> writes:
    >> Trying to use "use-package" to install evil-mode. use-package showed:
    >> cant access: https://elpa.gnu.org/packages/undo-tree.html :Bad request

    >> on my os (5.2.1-arch1-1-ARCH). First had emacs 26.2, than downgraded to
    >> 26.1 bug was in both versions.

    Noam> Does (setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3") help?  If
    Noam> yes, this is likely Bug#34341 (should already be fixed already in
    Noam> emacs-26, and the 26.2.90 pretest).

elpa.gnu.org uses TLS1.2, not TLS1.3. But emacs-27 has a bunch of
changes in its TLS handling that might improve matters.

Robert




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 11:02:01 GMT) Full text and rfc822 format available.

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

From: Tim Cross <theophilusx <at> gmail.com>
To: 36725 <at> debbugs.gnu.org
Date: Fri, 19 Jul 2019 21:01:04 +1000
[Message part 1 (text/plain, inline)]
I have also been having very similar problems with the same error messages.
Using Emacs 26.2 on GNU Linux (Ubuntu 19.04). Attempting to install the
delight package. Exact same error with emacs -Q. Same configuration is
working fine under macOS, so seems to be GNU Linux specific. Changing to
use HTTP instead of HTTPS fixes the problem. Note however that HTTPS to the
melpa repository works fine. Note also that this setup has been working
fine for ages. Last fresh install was only a couple of weeks back.

-- 
regards,

Tim

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

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 11:17:01 GMT) Full text and rfc822 format available.

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

From: Tim Cross <theophilusx <at> gmail.com>
To: 36725 <at> debbugs.gnu.org
Date: Fri, 19 Jul 2019 21:16:10 +1000
[Message part 1 (text/plain, inline)]
Correction to previous message. Attempting package-refresh-content under
macOS also now fails with the error "Failed to download 'gnu' archive
(other archives, such as melpa fine using https).

Temporary work around is to use http rather than https.

BTW using eww to visit https://elpa.gnu.org/packages works fine.

-- 
regards,

Tim

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

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 12:04:02 GMT) Full text and rfc822 format available.

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Lennard Henze <henzelen <at> hu-berlin.de>
Cc: Tim Cross <theophilusx <at> gmail.com>, 36725 <at> debbugs.gnu.org
Subject: Re: bug#36725: 26.1; Emacs can't connect to gnu elpa
Date: Fri, 19 Jul 2019 08:02:54 -0400
Robert Pluim <rpluim <at> gmail.com> writes:

>     Noam> Does (setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3") help?  If
>     Noam> yes, this is likely Bug#34341 (should already be fixed already in
>     Noam> emacs-26, and the 26.2.90 pretest).
>
> elpa.gnu.org uses TLS1.2, not TLS1.3. But emacs-27 has a bunch of
> changes in its TLS handling that might improve matters.

Hmm, it does.  On the other hand, Lennard told me [Lennard, please use
"Reply All" next time so your response goes to the bug list] that (setq
gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3") did actually help.

Tim, can you check the gnutls-algorithm-priority workaround too?





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 12:11:02 GMT) Full text and rfc822 format available.

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

From: Tim Cross <theophilusx <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Lennard Henze <henzelen <at> hu-berlin.de>, 36725 <at> debbugs.gnu.org
Subject: Re: bug#36725: 26.1; Emacs can't connect to gnu elpa
Date: Fri, 19 Jul 2019 22:09:43 +1000
[Message part 1 (text/plain, inline)]
Yep, checked and it made no difference. Did get a little more wrt error info

gnutls.el: (err=[-50] The request is invalid.) boot: (:priority
"NORMAL:-VERS-TLS1.3" :hostname melpa.org :loglevel 0 :min-prime-bits 256
:trustfiles (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist nil
:verify-flags nil :verify-error nil :callbacks nil)

Also tried with TLS 1.2, same error.



On Fri, 19 Jul 2019 at 22:02, Noam Postavsky <npostavs <at> gmail.com> wrote:

> Robert Pluim <rpluim <at> gmail.com> writes:
>
> >     Noam> Does (setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")
> help?  If
> >     Noam> yes, this is likely Bug#34341 (should already be fixed already
> in
> >     Noam> emacs-26, and the 26.2.90 pretest).
> >
> > elpa.gnu.org uses TLS1.2, not TLS1.3. But emacs-27 has a bunch of
> > changes in its TLS handling that might improve matters.
>
> Hmm, it does.  On the other hand, Lennard told me [Lennard, please use
> "Reply All" next time so your response goes to the bug list] that (setq
> gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3") did actually help.
>
> Tim, can you check the gnutls-algorithm-priority workaround too?
>
>

-- 
regards,

Tim

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

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 12:15:01 GMT) Full text and rfc822 format available.

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Tim Cross <theophilusx <at> gmail.com>
Cc: Lennard Henze <henzelen <at> hu-berlin.de>, 36725 <at> debbugs.gnu.org
Subject: Re: bug#36725: 26.1; Emacs can't connect to gnu elpa
Date: Fri, 19 Jul 2019 08:14:32 -0400
Tim Cross <theophilusx <at> gmail.com> writes:

> Yep, checked and it made no difference. Did get a little more wrt error info
>
> gnutls.el: (err=[-50] The request is invalid.) boot: (:priority
> "NORMAL:-VERS-TLS1.3" :hostname melpa.org :loglevel 0 :min-prime-bits 256
> :trustfiles (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist nil
> :verify-flags nil :verify-error nil :callbacks nil)

Oh, what is your value of libgnutls-version?  Perhaps it's not new
enough to recognize the TLS1.3 thing.  Now I'm wondering if the problem
is intermittent, and previous reports of that workaround helping are
just coincidence.

> Also tried with TLS 1.2, same error.

You mean you tried (setq gnutls-algorithm-priority
"NORMAL:-VERS-TLS1.2")?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 12:17:03 GMT) Full text and rfc822 format available.

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

From: Tim Cross <theophilusx <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Lennard Henze <henzelen <at> hu-berlin.de>, 36725 <at> debbugs.gnu.org
Subject: Re: bug#36725: 26.1; Emacs can't connect to gnu elpa
Date: Fri, 19 Jul 2019 22:15:55 +1000
[Message part 1 (text/plain, inline)]
Should have be a little clearer. That work-around causes all https
connections to fail. As you will see from the error I posted, that error
was from melpa, which works without that setting. The same error with
elpa.gnu.org as well.  Without that setting, the melpa https connection
works and only the elpa https connection fails.

Tim

On Fri, 19 Jul 2019 at 22:09, Tim Cross <theophilusx <at> gmail.com> wrote:

> Yep, checked and it made no difference. Did get a little more wrt error
> info
>
> gnutls.el: (err=[-50] The request is invalid.) boot: (:priority
> "NORMAL:-VERS-TLS1.3" :hostname melpa.org :loglevel 0 :min-prime-bits 256
> :trustfiles (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist nil
> :verify-flags nil :verify-error nil :callbacks nil)
>
> Also tried with TLS 1.2, same error.
>
>
>
> On Fri, 19 Jul 2019 at 22:02, Noam Postavsky <npostavs <at> gmail.com> wrote:
>
>> Robert Pluim <rpluim <at> gmail.com> writes:
>>
>> >     Noam> Does (setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")
>> help?  If
>> >     Noam> yes, this is likely Bug#34341 (should already be fixed
>> already in
>> >     Noam> emacs-26, and the 26.2.90 pretest).
>> >
>> > elpa.gnu.org uses TLS1.2, not TLS1.3. But emacs-27 has a bunch of
>> > changes in its TLS handling that might improve matters.
>>
>> Hmm, it does.  On the other hand, Lennard told me [Lennard, please use
>> "Reply All" next time so your response goes to the bug list] that (setq
>> gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3") did actually help.
>>
>> Tim, can you check the gnutls-algorithm-priority workaround too?
>>
>>
>
> --
> regards,
>
> Tim
>
> --
> Tim Cross
>
>

-- 
regards,

Tim

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

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 12:27:01 GMT) Full text and rfc822 format available.

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

From: Tim Cross <theophilusx <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Lennard Henze <henzelen <at> hu-berlin.de>, 36725 <at> debbugs.gnu.org
Subject: Re: bug#36725: 26.1; Emacs can't connect to gnu elpa
Date: Fri, 19 Jul 2019 22:26:20 +1000
[Message part 1 (text/plain, inline)]
Yes, I tried "NORMAl:VERS-TLS1.2" as well with no luck.

My GNUTLS version looks to be 3.6.5. This is a Ubuntu 19.04 system (which
was released last April) with all updates applied.

This also was working fine until just recently. Also, HTTPS to the melpa
repository works fine and using eww to https://elpa.gnu.org/packages works
fine.

Tim


On Fri, 19 Jul 2019 at 22:14, Noam Postavsky <npostavs <at> gmail.com> wrote:

> Tim Cross <theophilusx <at> gmail.com> writes:
>
> > Yep, checked and it made no difference. Did get a little more wrt error
> info
> >
> > gnutls.el: (err=[-50] The request is invalid.) boot: (:priority
> > "NORMAL:-VERS-TLS1.3" :hostname melpa.org :loglevel 0 :min-prime-bits
> 256
> > :trustfiles (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist
> nil
> > :verify-flags nil :verify-error nil :callbacks nil)
>
> Oh, what is your value of libgnutls-version?  Perhaps it's not new
> enough to recognize the TLS1.3 thing.  Now I'm wondering if the problem
> is intermittent, and previous reports of that workaround helping are
> just coincidence.
>
> > Also tried with TLS 1.2, same error.
>
> You mean you tried (setq gnutls-algorithm-priority
> "NORMAL:-VERS-TLS1.2")?
>


-- 
regards,

Tim

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

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 12:35:01 GMT) Full text and rfc822 format available.

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

From: Tim Cross <theophilusx <at> gmail.com>
To: Lennard Henze <henzelen <at> hu-berlin.de>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 36725 <at> debbugs.gnu.org
Subject: Re: bug#36725: 26.1; Emacs can't connect to gnu elpa
Date: Fri, 19 Jul 2019 22:33:54 +1000
[Message part 1 (text/plain, inline)]
What happens if you do

emacs -Q

set the gnutls-algorithm-priority (using customize-group or set-variable)

and then

M-x customize-group gnutls

M-x package-initialise
M-x package-refresh-contents

I get a failed to download 'gnu' archive error. If I try to install the
delight package (also a dependency of use-package) I get the bad response
error.

The issue is definitely TLS related, but not sure if it is client or server
end. When I set the perferred algorithm variable, the connections to MELPA
fail as well. Without setting that variable (i.e. set to nil) the
connections to MELPA work fine and only ELPA fails.

Tim



On Fri, 19 Jul 2019 at 22:15, Lennard Henze <henzelen <at> hu-berlin.de> wrote:

> Hey, I just double checked to not cause unnecessary confusion:
>
> Crated new user on arch to get empty home:
>
> used same .emacs as before, but without (setq gnutls-algorithm-priority
> "NORMAL:-VERS-TLS1.3"). After refreshing package list i can find undo-tree
> in gnu repos. When i try to install get the same bad request bug.
>
> After adding the line (setq gnutls-algorithm-priority
> "NORMAL:-VERS-TLS1.3")
> use-package downloads the package properly at startup and everything works
> fine.
>
> Can i provide additional debug info?
> Still not sure tho if its some dumb mistake in my os.
>
> On 19.07.19 14:09, Tim Cross wrote:
>
> Yep, checked and it made no difference. Did get a little more wrt error
> info
>
> gnutls.el: (err=[-50] The request is invalid.) boot: (:priority
> "NORMAL:-VERS-TLS1.3" :hostname melpa.org :loglevel 0 :min-prime-bits 256
> :trustfiles (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist nil
> :verify-flags nil :verify-error nil :callbacks nil)
>
> Also tried with TLS 1.2, same error.
>
>
>
> On Fri, 19 Jul 2019 at 22:02, Noam Postavsky <npostavs <at> gmail.com> wrote:
>
>> Robert Pluim <rpluim <at> gmail.com> writes:
>>
>> >     Noam> Does (setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")
>> help?  If
>> >     Noam> yes, this is likely Bug#34341 (should already be fixed
>> already in
>> >     Noam> emacs-26, and the 26.2.90 pretest).
>> >
>> > elpa.gnu.org uses TLS1.2, not TLS1.3. But emacs-27 has a bunch of
>> > changes in its TLS handling that might improve matters.
>>
>> Hmm, it does.  On the other hand, Lennard told me [Lennard, please use
>> "Reply All" next time so your response goes to the bug list] that (setq
>> gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3") did actually help.
>>
>> Tim, can you check the gnutls-algorithm-priority workaround too?
>>
>>
>
> --
> regards,
>
> Tim
>
> --
> Tim Cross
>
>

-- 
regards,

Tim

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

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 12:47:02 GMT) Full text and rfc822 format available.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Tim Cross <theophilusx <at> gmail.com>
Cc: 36725 <at> debbugs.gnu.org
Subject: Re: bug#36725:
Date: Fri, 19 Jul 2019 14:46:43 +0200
>>>>> On Fri, 19 Jul 2019 21:16:10 +1000, Tim Cross <theophilusx <at> gmail.com> said:

    Tim> Correction to previous message. Attempting package-refresh-content under
    Tim> macOS also now fails with the error "Failed to download 'gnu' archive
    Tim> (other archives, such as melpa fine using https).

    Tim> Temporary work around is to use http rather than https.

    Tim> BTW using eww to visit https://elpa.gnu.org/packages works fine.

I reproduced something similar with emacs-26, although eww fails for
me.

Itʼs fixed by:

202ff53da267f9fa15f438e9c38603bbead6e890 is the first new commit
commit 202ff53da267f9fa15f438e9c38603bbead6e890
Author: Noam Postavsky <npostavs <at> gmail.com>
Date:   Mon May 6 19:55:17 2019 -0400

    Handle GNUTLS_E_AGAIN in emacs_gnutls_read (Bug#34341)

which is contained in HEAD of the emacs-26 branch and in the 26.2.90
pretest at
<https://alpha.gnu.org/gnu/emacs/pretest/emacs-26.2.90.tar.xz>

Would you be able to test one of those?

Regards

Robert




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 12:52:01 GMT) Full text and rfc822 format available.

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

From: Tim Cross <theophilusx <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 36725 <at> debbugs.gnu.org
Subject: Re: bug#36725:
Date: Fri, 19 Jul 2019 22:51:26 +1000
[Message part 1 (text/plain, inline)]
Yep, I can try the pretest version.

It it helps, I set gnutls log level to 1 and go the following, which makes
me think the issue is a server issue

Importing package-keyring.gpg...done
Contacting host: elpa.gnu.org:443
gnutls.c: [1] (Emacs) connecting to host: elpa.gnu.org
gnutls.c: [1] (Emacs) allocating credentials
gnutls.c: [1] (Emacs) setting the trustfile:
 /etc/ssl/certs/ca-certificates.crt
gnutls.c: [1] (Emacs) gnutls callbacks
gnutls.c: [1] (Emacs) gnutls_init
gnutls.c: [1] (Emacs) got non-default priority string: NORMAL:%DUMBFW
gnutls.c: [1] (Emacs) setting the priority string
gnutls.c: [audit] Note that the security level of the Diffie-Hellman key
exchange has been lowered to 256 bits and this may allow decryption of the
session data

gnutls.c: [1] (Emacs) non-fatal error: Resource temporarily unavailable,
try again. [2666 times]

On Fri, 19 Jul 2019 at 22:46, Robert Pluim <rpluim <at> gmail.com> wrote:

> >>>>> On Fri, 19 Jul 2019 21:16:10 +1000, Tim Cross <theophilusx <at> gmail.com>
> said:
>
>     Tim> Correction to previous message. Attempting
> package-refresh-content under
>     Tim> macOS also now fails with the error "Failed to download 'gnu'
> archive
>     Tim> (other archives, such as melpa fine using https).
>
>     Tim> Temporary work around is to use http rather than https.
>
>     Tim> BTW using eww to visit https://elpa.gnu.org/packages works fine.
>
> I reproduced something similar with emacs-26, although eww fails for
> me.
>
> Itʼs fixed by:
>
> 202ff53da267f9fa15f438e9c38603bbead6e890 is the first new commit
> commit 202ff53da267f9fa15f438e9c38603bbead6e890
> Author: Noam Postavsky <npostavs <at> gmail.com>
> Date:   Mon May 6 19:55:17 2019 -0400
>
>     Handle GNUTLS_E_AGAIN in emacs_gnutls_read (Bug#34341)
>
> which is contained in HEAD of the emacs-26 branch and in the 26.2.90
> pretest at
> <https://alpha.gnu.org/gnu/emacs/pretest/emacs-26.2.90.tar.xz>
>
> Would you be able to test one of those?
>
> Regards
>
> Robert
>


-- 
regards,

Tim

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

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 13:04:01 GMT) Full text and rfc822 format available.

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

From: Tim Cross <theophilusx <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 36725 <at> debbugs.gnu.org
Subject: Re: bug#36725:
Date: Fri, 19 Jul 2019 23:03:40 +1000
[Message part 1 (text/plain, inline)]
OK, running the pretest 26.2.90 seems to have resolved the issue. (or the
temp resource unavailable issue reported previously has gone away). At any
rate, seems to be working with 26.2.90

That was doing emacs -Q and then

M-x package-initialise
M-x package-refresh-contents

which previously failed with a "Failed to download 'gnu' archive'

and then did a

M-x package-install <ret> delight <ret)

which reports 1 package installed.

Will now try a full install from my normal init.el. At this stage, issue
seems resolved for me - I will just run the pretest until 26.3 is released.

Tim

On Fri, 19 Jul 2019 at 22:51, Tim Cross <theophilusx <at> gmail.com> wrote:

> Yep, I can try the pretest version.
>
> It it helps, I set gnutls log level to 1 and go the following, which makes
> me think the issue is a server issue
>
> Importing package-keyring.gpg...done
> Contacting host: elpa.gnu.org:443
> gnutls.c: [1] (Emacs) connecting to host: elpa.gnu.org
> gnutls.c: [1] (Emacs) allocating credentials
> gnutls.c: [1] (Emacs) setting the trustfile:
>  /etc/ssl/certs/ca-certificates.crt
> gnutls.c: [1] (Emacs) gnutls callbacks
> gnutls.c: [1] (Emacs) gnutls_init
> gnutls.c: [1] (Emacs) got non-default priority string: NORMAL:%DUMBFW
> gnutls.c: [1] (Emacs) setting the priority string
> gnutls.c: [audit] Note that the security level of the Diffie-Hellman key
> exchange has been lowered to 256 bits and this may allow decryption of the
> session data
>
> gnutls.c: [1] (Emacs) non-fatal error: Resource temporarily unavailable,
> try again. [2666 times]
>
> On Fri, 19 Jul 2019 at 22:46, Robert Pluim <rpluim <at> gmail.com> wrote:
>
>> >>>>> On Fri, 19 Jul 2019 21:16:10 +1000, Tim Cross <
>> theophilusx <at> gmail.com> said:
>>
>>     Tim> Correction to previous message. Attempting
>> package-refresh-content under
>>     Tim> macOS also now fails with the error "Failed to download 'gnu'
>> archive
>>     Tim> (other archives, such as melpa fine using https).
>>
>>     Tim> Temporary work around is to use http rather than https.
>>
>>     Tim> BTW using eww to visit https://elpa.gnu.org/packages works fine.
>>
>> I reproduced something similar with emacs-26, although eww fails for
>> me.
>>
>> Itʼs fixed by:
>>
>> 202ff53da267f9fa15f438e9c38603bbead6e890 is the first new commit
>> commit 202ff53da267f9fa15f438e9c38603bbead6e890
>> Author: Noam Postavsky <npostavs <at> gmail.com>
>> Date:   Mon May 6 19:55:17 2019 -0400
>>
>>     Handle GNUTLS_E_AGAIN in emacs_gnutls_read (Bug#34341)
>>
>> which is contained in HEAD of the emacs-26 branch and in the 26.2.90
>> pretest at
>> <https://alpha.gnu.org/gnu/emacs/pretest/emacs-26.2.90.tar.xz>
>>
>> Would you be able to test one of those?
>>
>> Regards
>>
>> Robert
>>
>
>
> --
> regards,
>
> Tim
>
> --
> Tim Cross
>
>

-- 
regards,

Tim

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

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 13:19:02 GMT) Full text and rfc822 format available.

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

From: Tim Cross <theophilusx <at> gmail.com>
To: Lennard Henze <henzelen <at> hu-berlin.de>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 36725 <at> debbugs.gnu.org
Subject: Re: bug#36725: 26.1; Emacs can't connect to gnu elpa
Date: Fri, 19 Jul 2019 23:18:25 +1000
[Message part 1 (text/plain, inline)]
Weird. When I set that variable, both elpa and melpa fail.

I upgraded to the 26.2.90 pretest and now it all works fine - no need to
set any additional variable.

I also increased the gnutls-log-level to 1 and saw a resource temporarily
unavailable errors. I'm running a dual stack network (IPv4 and IPv6) and
wonder if perhaps elpa.gnu.org IPv4 was fine but IPv6 was not and my system
was attempting to connect via IPv6. Thais could explain why I had more
success on the macOS as that system has IPv6 set to link-local only.

All speculation at this point. All working with the emacs pretest version,
so now I can get back to what I was originally trying to do oh so many
houts ago!

On Fri, 19 Jul 2019 at 23:06, Lennard Henze <henzelen <at> hu-berlin.de> wrote:

> Cleaned everything:
>
> emacs -Q: get into small buffer for lisp eval
>
> try to set via set-variable: does not find gnutls-algorithm-priority (only
> var starting with gnutls is gnutls-min-prime-bits)
>
> do customize-group gnutls: there the variable gnutls-algorithm-priority is
> shown and set to nil
>
> change it to NORMAL:-VERS-TLS1.3
>
> run package-initialize: no problem
>
> run package-refresh-contents: no problem
>
> install undo-tree via package-install ret undo-tree ret: no problem
>  On 19.07.19 14:33, Tim Cross wrote:
>
> What happens if you do
>
> emacs -Q
>
> set the gnutls-algorithm-priority (using customize-group or set-variable)
>
> and then
>
> M-x customize-group gnutls
>
> M-x package-initialise
> M-x package-refresh-contents
>
> I get a failed to download 'gnu' archive error. If I try to install the
> delight package (also a dependency of use-package) I get the bad response
> error.
>
> The issue is definitely TLS related, but not sure if it is client or
> server end. When I set the perferred algorithm variable, the connections to
> MELPA fail as well. Without setting that variable (i.e. set to nil) the
> connections to MELPA work fine and only ELPA fails.
>
> Tim
>
>
>
> On Fri, 19 Jul 2019 at 22:15, Lennard Henze <henzelen <at> hu-berlin.de> wrote:
>
>> Hey, I just double checked to not cause unnecessary confusion:
>>
>> Crated new user on arch to get empty home:
>>
>> used same .emacs as before, but without (setq gnutls-algorithm-priority
>> "NORMAL:-VERS-TLS1.3"). After refreshing package list i can find undo-tree
>> in gnu repos. When i try to install get the same bad request bug.
>>
>> After adding the line (setq gnutls-algorithm-priority
>> "NORMAL:-VERS-TLS1.3")
>> use-package downloads the package properly at startup and everything
>> works fine.
>>
>> Can i provide additional debug info?
>> Still not sure tho if its some dumb mistake in my os.
>>
>> On 19.07.19 14:09, Tim Cross wrote:
>>
>> Yep, checked and it made no difference. Did get a little more wrt error
>> info
>>
>> gnutls.el: (err=[-50] The request is invalid.) boot: (:priority
>> "NORMAL:-VERS-TLS1.3" :hostname melpa.org :loglevel 0 :min-prime-bits
>> 256 :trustfiles (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist
>> nil :verify-flags nil :verify-error nil :callbacks nil)
>>
>> Also tried with TLS 1.2, same error.
>>
>>
>>
>> On Fri, 19 Jul 2019 at 22:02, Noam Postavsky <npostavs <at> gmail.com> wrote:
>>
>>> Robert Pluim <rpluim <at> gmail.com> writes:
>>>
>>> >     Noam> Does (setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")
>>> help?  If
>>> >     Noam> yes, this is likely Bug#34341 (should already be fixed
>>> already in
>>> >     Noam> emacs-26, and the 26.2.90 pretest).
>>> >
>>> > elpa.gnu.org uses TLS1.2, not TLS1.3. But emacs-27 has a bunch of
>>> > changes in its TLS handling that might improve matters.
>>>
>>> Hmm, it does.  On the other hand, Lennard told me [Lennard, please use
>>> "Reply All" next time so your response goes to the bug list] that (setq
>>> gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3") did actually help.
>>>
>>> Tim, can you check the gnutls-algorithm-priority workaround too?
>>>
>>>
>>
>> --
>> regards,
>>
>> Tim
>>
>> --
>> Tim Cross
>>
>>
>
> --
> regards,
>
> Tim
>
> --
> Tim Cross
>
>

-- 
regards,

Tim

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

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 14:03:02 GMT) Full text and rfc822 format available.

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

From: Lennard Henze <henzelen <at> hu-berlin.de>
To: Tim Cross <theophilusx <at> gmail.com>, Noam Postavsky <npostavs <at> gmail.com>
Cc: 36725 <at> debbugs.gnu.org
Subject: Re: bug#36725: 26.1; Emacs can't connect to gnu elpa
Date: Fri, 19 Jul 2019 14:15:57 +0200
[Message part 1 (text/plain, inline)]
Hey, I just double checked to not cause unnecessary confusion:

Crated new user on arch to get empty home:

used same .emacs as before, but without (setq gnutls-algorithm-priority 
"NORMAL:-VERS-TLS1.3"). After refreshing package list i can find 
undo-tree in gnu repos. When i try to install get the same bad request bug.

After adding the line (setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")

use-package downloads the package properly at startup and everything 
works fine.

Can i provide additional debug info?
Still not sure tho if its some dumb mistake in my os.

On 19.07.19 14:09, Tim Cross wrote:
> Yep, checked and it made no difference. Did get a little more wrt 
> error info
>
> gnutls.el: (err=[-50] The request is invalid.) boot: (:priority 
> "NORMAL:-VERS-TLS1.3" :hostname melpa.org <http://melpa.org> :loglevel 
> 0 :min-prime-bits 256 :trustfiles (/etc/ssl/certs/ca-certificates.crt) 
> :crlfiles nil :keylist nil :verify-flags nil :verify-error nil 
> :callbacks nil)
>
> Also tried with TLS 1.2, same error.
>
>
>
> On Fri, 19 Jul 2019 at 22:02, Noam Postavsky <npostavs <at> gmail.com 
> <mailto:npostavs <at> gmail.com>> wrote:
>
>     Robert Pluim <rpluim <at> gmail.com <mailto:rpluim <at> gmail.com>> writes:
>
>     >     Noam> Does (setq gnutls-algorithm-priority
>     "NORMAL:-VERS-TLS1.3") help?  If
>     >     Noam> yes, this is likely Bug#34341 (should already be fixed
>     already in
>     >     Noam> emacs-26, and the 26.2.90 pretest).
>     >
>     > elpa.gnu.org <http://elpa.gnu.org> uses TLS1.2, not TLS1.3. But
>     emacs-27 has a bunch of
>     > changes in its TLS handling that might improve matters.
>
>     Hmm, it does.  On the other hand, Lennard told me [Lennard, please use
>     "Reply All" next time so your response goes to the bug list] that
>     (setq
>     gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3") did actually help.
>
>     Tim, can you check the gnutls-algorithm-priority workaround too?
>
>
>
> -- 
> regards,
>
> Tim
>
> --
> Tim Cross
>
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 14:03:02 GMT) Full text and rfc822 format available.

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

From: Lennard Henze <henzelen <at> hu-berlin.de>
To: Tim Cross <theophilusx <at> gmail.com>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 36725 <at> debbugs.gnu.org
Subject: Re: bug#36725: 26.1; Emacs can't connect to gnu elpa
Date: Fri, 19 Jul 2019 15:06:37 +0200
[Message part 1 (text/plain, inline)]
Cleaned everything:

emacs -Q: get into small buffer for lisp eval

try to set via set-variable: does not find gnutls-algorithm-priority 
(only var starting with gnutls is gnutls-min-prime-bits)

do customize-group gnutls: there the variable gnutls-algorithm-priority 
is shown and set to nil

change it to NORMAL:-VERS-TLS1.3

run package-initialize: no problem

run package-refresh-contents: no problem

install undo-tree via package-install ret undo-tree ret: no problem

 On 19.07.19 14:33, Tim Cross wrote:
> What happens if you do
>
> emacs -Q
>
> set the gnutls-algorithm-priority (using customize-group or set-variable)
>
> and then
>
> M-x customize-group gnutls
>
> M-x package-initialise
> M-x package-refresh-contents
>
> I get a failed to download 'gnu' archive error. If I try to install 
> the delight package (also a dependency of use-package) I get the bad 
> response error.
>
> The issue is definitely TLS related, but not sure if it is client or 
> server end. When I set the perferred algorithm variable, the 
> connections to MELPA fail as well. Without setting that variable (i.e. 
> set to nil) the connections to MELPA work fine and only ELPA fails.
>
> Tim
>
>
>
> On Fri, 19 Jul 2019 at 22:15, Lennard Henze <henzelen <at> hu-berlin.de 
> <mailto:henzelen <at> hu-berlin.de>> wrote:
>
>     Hey, I just double checked to not cause unnecessary confusion:
>
>     Crated new user on arch to get empty home:
>
>     used same .emacs as before, but without (setq
>     gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3"). After refreshing
>     package list i can find undo-tree in gnu repos. When i try to
>     install get the same bad request bug.
>
>     After adding the line (setq gnutls-algorithm-priority
>     "NORMAL:-VERS-TLS1.3")
>
>     use-package downloads the package properly at startup and
>     everything works fine.
>
>     Can i provide additional debug info?
>     Still not sure tho if its some dumb mistake in my os.
>
>     On 19.07.19 14:09, Tim Cross wrote:
>>     Yep, checked and it made no difference. Did get a little more wrt
>>     error info
>>
>>     gnutls.el: (err=[-50] The request is invalid.) boot: (:priority
>>     "NORMAL:-VERS-TLS1.3" :hostname melpa.org <http://melpa.org>
>>     :loglevel 0 :min-prime-bits 256 :trustfiles
>>     (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist nil
>>     :verify-flags nil :verify-error nil :callbacks nil)
>>
>>     Also tried with TLS 1.2, same error.
>>
>>
>>
>>     On Fri, 19 Jul 2019 at 22:02, Noam Postavsky <npostavs <at> gmail.com
>>     <mailto:npostavs <at> gmail.com>> wrote:
>>
>>         Robert Pluim <rpluim <at> gmail.com <mailto:rpluim <at> gmail.com>> writes:
>>
>>         >     Noam> Does (setq gnutls-algorithm-priority
>>         "NORMAL:-VERS-TLS1.3") help?  If
>>         >     Noam> yes, this is likely Bug#34341 (should already be
>>         fixed already in
>>         >     Noam> emacs-26, and the 26.2.90 pretest).
>>         >
>>         > elpa.gnu.org <http://elpa.gnu.org> uses TLS1.2, not TLS1.3.
>>         But emacs-27 has a bunch of
>>         > changes in its TLS handling that might improve matters.
>>
>>         Hmm, it does.  On the other hand, Lennard told me [Lennard,
>>         please use
>>         "Reply All" next time so your response goes to the bug list]
>>         that (setq
>>         gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3") did actually
>>         help.
>>
>>         Tim, can you check the gnutls-algorithm-priority workaround too?
>>
>>
>>
>>     -- 
>>     regards,
>>
>>     Tim
>>
>>     --
>>     Tim Cross
>>
>
>
> -- 
> regards,
>
> Tim
>
> --
> Tim Cross
>
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 14:15:01 GMT) Full text and rfc822 format available.

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Tim Cross <theophilusx <at> gmail.com>
Cc: Lennard Henze <henzelen <at> hu-berlin.de>, 36725 <at> debbugs.gnu.org
Subject: Re: bug#36725: 26.1; Emacs can't connect to gnu elpa
Date: Fri, 19 Jul 2019 10:14:20 -0400
Tim Cross <theophilusx <at> gmail.com> writes:

> Should have be a little clearer. That work-around causes all https
> connections to fail. As you will see from the error I posted, that error
> was from melpa, which works without that setting. The same error with
> elpa.gnu.org as well.  Without that setting, the melpa https connection
> works and only the elpa https connection fails.

> On Fri, 19 Jul 2019 at 22:09, Tim Cross <theophilusx <at> gmail.com> wrote:
>>
>> gnutls.el: (err=[-50] The request is invalid.) boot: (:priority
>> "NORMAL:-VERS-TLS1.3" :hostname melpa.org :loglevel 0 :min-prime-bits 256
>> :trustfiles (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist nil
>> :verify-flags nil :verify-error nil :callbacks nil)

That's the behaviour I would expect for gnutls versions 3.6.2 and
earlier (because gnutls only started supporting TLS1.3 at version
3.6.3).  But you said

> My GNUTLS version looks to be 3.6.5. This is a Ubuntu 19.04 system (which
> was released last April) with all updates applied.

so that seems a little strange.  Does libgnutls-version have the 30605
value?  Can you also show the output from

    ldd $(which emacs) | grep gnutls





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 15:47:02 GMT) Full text and rfc822 format available.

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

From: Tim Cross <theophilusx <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Lennard Henze <henzelen <at> hu-berlin.de>, 36725 <at> debbugs.gnu.org
Subject: Re: bug#36725: 26.1; Emacs can't connect to gnu elpa
Date: Sat, 20 Jul 2019 01:46:16 +1000
[Message part 1 (text/plain, inline)]
libgnutls-version’s value is 30605

➜  bin ldd emacs-26.2 | grep gnutls
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30
(0x00007f78d3a1e000)

I still suspect the issue may have been server rather than client. This
system with the same configuration has been connecting to elpa.gnu.org over
https since I first built it when 26.2 was released.  It is only today that
I found https connections to elpa.gnu.org failed.

Note also that to be sure, I did a rebuild and  reinstall of emacs just in
case it had been linked against an older library. This had no effect.

According the the gnutls NEWS file, this version does support 1.3

Tim


On Sat, 20 Jul 2019 at 00:14, Noam Postavsky <npostavs <at> gmail.com> wrote:

> Tim Cross <theophilusx <at> gmail.com> writes:
>
> > Should have be a little clearer. That work-around causes all https
> > connections to fail. As you will see from the error I posted, that error
> > was from melpa, which works without that setting. The same error with
> > elpa.gnu.org as well.  Without that setting, the melpa https connection
> > works and only the elpa https connection fails.
>
> > On Fri, 19 Jul 2019 at 22:09, Tim Cross <theophilusx <at> gmail.com> wrote:
> >>
> >> gnutls.el: (err=[-50] The request is invalid.) boot: (:priority
> >> "NORMAL:-VERS-TLS1.3" :hostname melpa.org :loglevel 0 :min-prime-bits
> 256
> >> :trustfiles (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist
> nil
> >> :verify-flags nil :verify-error nil :callbacks nil)
>
> That's the behaviour I would expect for gnutls versions 3.6.2 and
> earlier (because gnutls only started supporting TLS1.3 at version
> 3.6.3).  But you said
>
> > My GNUTLS version looks to be 3.6.5. This is a Ubuntu 19.04 system (which
> > was released last April) with all updates applied.
>
> so that seems a little strange.  Does libgnutls-version have the 30605
> value?  Can you also show the output from
>
>     ldd $(which emacs) | grep gnutls
>
>

-- 
regards,

Tim

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

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Fri, 19 Jul 2019 16:51:02 GMT) Full text and rfc822 format available.

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Tim Cross <theophilusx <at> gmail.com>
Cc: Lennard Henze <henzelen <at> hu-berlin.de>, 36725 <at> debbugs.gnu.org
Subject: Re: bug#36725: 26.1; Emacs can't connect to gnu elpa
Date: Fri, 19 Jul 2019 12:50:38 -0400
Tim Cross <theophilusx <at> gmail.com> writes:

> libgnutls-version’s value is 30605
>
> ➜  bin ldd emacs-26.2 | grep gnutls
> libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30
> (0x00007f78d3a1e000)
>
> I still suspect the issue may have been server rather than client. This
> system with the same configuration has been connecting to elpa.gnu.org over
> https since I first built it when 26.2 was released.  It is only today that
> I found https connections to elpa.gnu.org failed.

I believe the actual problem is on the client side, in that Emacs
versions 26.2 and ealier don't handle the EAGAIN error from gnutls
correctly.  Whether or not the EAGAIN actually happens depends on the
precise timing, so it can be affected by all kinds of things.  For
example, there were some reports that setting gnutls-log-level would
stop the bug from happening.

I'm guessing the elpa.gnu.org server was updated recently in a way which
is triggering this bug.  So a whole lot more people are running into it.

> Note also that to be sure, I did a rebuild and  reinstall of emacs just in
> case it had been linked against an older library. This had no effect.
>
> According the the gnutls NEWS file, this version does support 1.3

The only thing I can't explain is why setting gnutls-algorithm-priority
breaks for you on what seems to be a recent libgnutls (I would have
thought it would be useless at worst).  It is reported to work for
others (though it's likely just a coincidence that it affects the timing
in such a way as to avoid EAGAIN errors).

E.g., Bug#34341 and some recent reddit threads:

https://debbugs.gnu.org/34341#19
https://old.reddit.com/r/emacs/comments/cdei4p/failed_to_download_gnu_archive_bad_request/
https://old.reddit.com/r/emacs/comments/cb3wnj/urlretrievesynchronously_returning_400_bad_request/




Merged 36725 36749. Request was from Noam Postavsky <npostavs <at> gmail.com> to control <at> debbugs.gnu.org. (Mon, 22 Jul 2019 01:00:02 GMT) Full text and rfc822 format available.

Merged 36725 36749 36810. Request was from Noam Postavsky <npostavs <at> gmail.com> to control <at> debbugs.gnu.org. (Thu, 25 Jul 2019 17:36:02 GMT) Full text and rfc822 format available.

bug Marked as fixed in versions 26.2.90. Request was from Noam Postavsky <npostavs <at> gmail.com> to control <at> debbugs.gnu.org. (Thu, 25 Jul 2019 22:41:02 GMT) Full text and rfc822 format available.

Merged 36725 36749 36810 36873. Request was from Eli Zaretskii <eliz <at> gnu.org> to control <at> debbugs.gnu.org. (Wed, 31 Jul 2019 14:17:03 GMT) Full text and rfc822 format available.

Merged 36725 36749 36810 36873. Request was from Noam Postavsky <npostavs <at> gmail.com> to control <at> debbugs.gnu.org. (Wed, 31 Jul 2019 14:18:02 GMT) Full text and rfc822 format available.

Forcibly Merged 36725 36749 36810 36873 37453. Request was from Noam Postavsky <npostavs <at> gmail.com> to control <at> debbugs.gnu.org. (Thu, 19 Sep 2019 01:51:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36725; Package emacs. (Sun, 02 Aug 2020 12:42:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 37453 <at> debbugs.gnu.org, worik <root <at> worik.org>, 36725 <at> debbugs.gnu.org
Subject: Re: bug#37453: Cannot connect to elpa
Date: Sun, 02 Aug 2020 14:40:51 +0200
Noam Postavsky <npostavs <at> gmail.com> writes:

>> https://elpa.gnu.org/packages/spinner-1.7.3.el: Bad Request
>
> Upgrade to 26.3, or else try
>
>     (setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")
>
> as a workaround.

It looks like this has been fixed in Emacs 26.3, so I'm closing this bug
report.  If the problem still exists, please respond to this email and
we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug marked as fixed in version 26.3, send any further explanations to 36725 <at> debbugs.gnu.org and Lennard Henze <henzelen <at> hu-berlin.de> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sun, 02 Aug 2020 12:42:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 31 Aug 2020 11:24:05 GMT) Full text and rfc822 format available.

bug unarchived. Request was from Noam Postavsky <npostavs <at> gmail.com> to control <at> debbugs.gnu.org. (Tue, 29 Sep 2020 15:00:02 GMT) Full text and rfc822 format available.

Merged 36725 36749 36810 36873 37453 43708. Request was from Noam Postavsky <npostavs <at> gmail.com> to control <at> debbugs.gnu.org. (Tue, 29 Sep 2020 15:00:03 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 28 Oct 2020 11:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 151 days ago.

Previous Next


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