bug#34909: 26.1; Error refreshing packages under language environment

bug#34909: 26.1; Error refreshing packages under language environment

[E. Choroba]

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

--text follows this line--

When melpa is included in the package archives and the package list is
being updated, the result depends on the language environment. Under
"English", everything works OK:

emacs -Q --eval '(progn (set-language-environment "English")(require (quote package))(add-to-list (quote package-archives) (quote ("melpa" . "http://melpa.org/packages/")))(package-list-packages))'

When the environment is set to "French" or "Czech", though, it fails with

Failed to verify signature archive-contents.sig:
Bad signature from 474F05837FBDEF9B GNU ELPA Signing Agent <elpasign@elpa.gnu.org>
Command output:
gpg: Signature made Mon 18 Mar 2019 10:10:04 PM CET using DSA key ID 7FBDEF9B
gpg: BAD signature from "GNU ELPA Signing Agent <elpasign@elpa.gnu.org>" [unknown]

At the same time, it asks for encoding:

These default coding systems were tried to encode "
(1 (zzz-t...":
   (iso-latin-2-unix (13884 . 37326) (13885 . 40165) (32038 . 248)
   (32095 . 248) (39468 . 234) (39539 . 234) (71321 . 248) (71399 .
   248) (71700 . 248) (71778 . 248) (72084 . 248))
However, each of them encountered characters it couldn’t encode:
   iso-latin-2-unix cannot encode these: 野 鳥 ø ø ê ê ø ø ø ø ...

Click on a character (or switch to this window by ‘C-x o’
and select the characters by RET) to jump to the place it appears,
where ‘C-u C-x =’ will give information about it.

Select one of the safe coding systems listed below,
or cancel the writing with C-g and edit the buffer
    to remove or modify the problematic characters,
or specify any other coding system (and risk losing
    the problematic characters).

   utf-8 gb18030 utf-7 utf-16 utf-16be-with-signature
   utf-16le-with-signature utf-16be utf-16le iso-2022-7bit utf-8-auto
   utf-8-with-signature utf-7-imap utf-8-emacs prefer-utf-8

Choroba

In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, Motif Version 2.3.4)
  of 2018-09-10 built on still
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description:	openSUSE Leap 42.3

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
user-error: Beginning of history; no preceding item [2 times]
user-error: End of history; no default available

Configured using:
  'configure --with-kerberos5=yes --with-x-toolkit=motif --with-x=yes'

Configured features:
XPM JPEG TIFF GIF PNG SOUND DBUS GSETTINGS NOTIFY GNUTLS LIBXML2
FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS MOTIF X11 THREADS

Important settings:
   value of $LANG: en_US.UTF-8
   value of $XMODIFIERS: @im=local
   locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   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

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair 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
dynamic-setting system-font-setting font-render-setting motif x-toolkit
x multi-tty make-network-process emacs)

Memory information:
((conses 16 95003 9709)
  (symbols 48 20225 1)
  (miscs 40 41 143)
  (strings 32 28261 1189)
  (string-bytes 1 743314)
  (vectors 16 13966)
  (vector-slots 8 491676 10904)
  (floats 8 51 66)
  (intervals 56 225 0)
  (buffers 992 11)
  (heap 1024 37756 1009))

bug#34909: 26.1; Error refreshing packages under language environment

[Eli Zaretskii]

> Date: Mon, 18 Mar 2019 22:32:58 +0100 (CET)
> From: "E. Choroba" <choroba@matfyz.cz>
> 
> When melpa is included in the package archives and the package list is
> being updated, the result depends on the language environment. Under
> "English", everything works OK:
> 
> emacs -Q --eval '(progn (set-language-environment "English")(require (quote package))(add-to-list (quote package-archives) (quote ("melpa" . "http://melpa.org/packages/")))(package-list-packages))'
> 
> When the environment is set to "French" or "Czech", though, it fails with
> 
> Failed to verify signature archive-contents.sig:
> Bad signature from 474F05837FBDEF9B GNU ELPA Signing Agent <elpasign@elpa.gnu.org>
> Command output:
> gpg: Signature made Mon 18 Mar 2019 10:10:04 PM CET using DSA key ID 7FBDEF9B
> gpg: BAD signature from "GNU ELPA Signing Agent <elpasign@elpa.gnu.org>" [unknown]
> 
> At the same time, it asks for encoding:

Thanks, this should be fixed now on the release branch.

The patch is below, should you want to install it locally.

diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 3118e38..1a185de 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -1538,14 +1538,16 @@ package--download-one-archive
                 (member name package-unsigned-archives))
             ;; If we don't care about the signature, save the file and
             ;; we're done.
-            (progn (write-region content nil local-file nil 'silent)
+            (progn (let ((coding-system-for-write 'utf-8))
+                     (write-region content nil local-file nil 'silent))
                    (package--update-downloads-in-progress archive))
           ;; If we care, check it (perhaps async) and *then* write the file.
           (package--check-signature
            location file content async
            ;; This function will be called after signature checking.
            (lambda (&optional good-sigs)
-             (write-region content nil local-file nil 'silent)
+             (let ((coding-system-for-write 'utf-8))
+               (write-region content nil local-file nil 'silent))
              ;; Write out good signatures into archive-contents.signed file.
              (when good-sigs
                (write-region (mapconcat #'epg-signature-to-string good-sigs "\n")
@@ -3425,6 +3427,9 @@ list-packages
   ;; Generate the Package Menu.
   (let ((buf (get-buffer-create "*Packages*")))
     (with-current-buffer buf
+      ;; Since some packages have their descriptions include non-ASCII
+      ;; characters...
+      (setq buffer-file-coding-system 'utf-8)
       (package-menu-mode)
 
       ;; Fetch the remote list of packages.

bug#34909: 26.1; Error refreshing packages under language environment

[E. Choroba]

> The patch is below, should you want to install it locally.

Thanks. I tried to apply the patch locally but the error persists (just 
running the above mentioned command).

Ch.

bug#34909: 26.1; Error refreshing packages under language environment

[Eli Zaretskii]

> Date: Tue, 19 Mar 2019 12:57:32 +0100 (CET)
> From: "E. Choroba" <choroba@matfyz.cz>
> cc: 34909@debbugs.gnu.org
> 
> > The patch is below, should you want to install it locally.
> 
> Thanks. I tried to apply the patch locally but the error persists (just 
> running the above mentioned command).

Did you byte-compile package.el after applying the patch?  If not,
either byte-compile it or load the .el file manually, and then try
again.

I definitely cannot reproduce the problem after the change, whereas it
was 100% reproducible with your recipe before the change.

bug#34909: 26.1; Error refreshing packages under language environment

[E. Choroba]

Yes, I even tried to recompile the whole Emacs with the patched package.el to 
no avail.

Maybe it's related to some other changes that happened between 26.1 and the 
development version?

Ch.

==============================================================================
On Tue, 19 Mar 2019, Eli Zaretskii wrote:
>> Date: Tue, 19 Mar 2019 12:57:32 +0100 (CET)
>> From: "E. Choroba" <choroba@matfyz.cz>
>> cc: 34909@debbugs.gnu.org
>>
>>> The patch is below, should you want to install it locally.
>>
>> Thanks. I tried to apply the patch locally but the error persists (just
>> running the above mentioned command).
>
> Did you byte-compile package.el after applying the patch?  If not,
> either byte-compile it or load the .el file manually, and then try
> again.
>
> I definitely cannot reproduce the problem after the change, whereas it
> was 100% reproducible with your recipe before the change.
>

bug#34909: 26.1; Error refreshing packages under language environment

[Eli Zaretskii]

On March 19, 2019 3:06:15 PM GMT+02:00, "E. Choroba" <choroba@matfyz.cz> wrote:
> Yes, I even tried to recompile the whole Emacs with the patched
> package.el to 
> no avail.
> 
> Maybe it's related to some other changes that happened between 26.1
> and the 
> development version?
> 
> Ch.
> 
> ==============================================================================
> On Tue, 19 Mar 2019, Eli Zaretskii wrote:
> >> Date: Tue, 19 Mar 2019 12:57:32 +0100 (CET)
> >> From: "E. Choroba" <choroba@matfyz.cz>
> >> cc: 34909@debbugs.gnu.org
> >>
> >>> The patch is below, should you want to install it locally.
> >>
> >> Thanks. I tried to apply the patch locally but the error persists
> (just
> >> running the above mentioned command).
> >
> > Did you byte-compile package.el after applying the patch?  If not,
> > either byte-compile it or load the .el file manually, and then try
> > again.
> >
> > I definitely cannot reproduce the problem after the change, whereas
> it
> > was 100% reproducible with your recipe before the change.
> >

Then I'm stumped.  I don't see how any other changes could affect this, but maybe try using package.el from the emacs-26 branch of the Emacs Git repository.

If that doesn't fix the problem, either, I guess someone will have to reproduce and tell which code requests coding-system, in addition to what I fixed.

bug#34909: 26.1; Error refreshing packages under language environment

[Eli Zaretskii]

On March 19, 2019 4:32:39 PM GMT+02:00, Eli Zaretskii <eliz@gnu.org> wrote:
> On March 19, 2019 3:06:15 PM GMT+02:00, "E. Choroba"
> <choroba@matfyz.cz> wrote:
> > Yes, I even tried to recompile the whole Emacs with the patched
> > package.el to 
> > no avail.
> > 
> > Maybe it's related to some other changes that happened between 26.1
> > and the 
> > development version?
> > 
> > Ch.
> > 
> >
> ==============================================================================
> > On Tue, 19 Mar 2019, Eli Zaretskii wrote:
> > >> Date: Tue, 19 Mar 2019 12:57:32 +0100 (CET)
> > >> From: "E. Choroba" <choroba@matfyz.cz>
> > >> cc: 34909@debbugs.gnu.org
> > >>
> > >>> The patch is below, should you want to install it locally.
> > >>
> > >> Thanks. I tried to apply the patch locally but the error persists
> > (just
> > >> running the above mentioned command).
> > >
> > > Did you byte-compile package.el after applying the patch?  If not,
> > > either byte-compile it or load the .el file manually, and then try
> > > again.
> > >
> > > I definitely cannot reproduce the problem after the change,
> whereas
> > it
> > > was 100% reproducible with your recipe before the change.
> > >
> 
> Then I'm stumped.  I don't see how any other changes could affect
> this, but maybe try using package.el from the emacs-26 branch of the
> Emacs Git repository.
> 
> If that doesn't fix the problem, either, I guess someone will have to
> reproduce and tell which code requests coding-system, in addition to
> what I fixed.

Maybe try emptying your melpa/archive-contents file, perhaps it got corrupted by the buggy code you ran before the fix.

bug#34909: 26.1; Error refreshing packages under language environment

[E. Choroba]

Sorry, I noticed the behaviour is a bit different: it still displays the "Bad 
Signature" error, but it doesn't ask for encoding anymore. So it seems your 
fix helped a bit, but maybe there's a similar problem in the epg package?

I apologize for the confusion.

Ch.

==============================================================================
On Tue, 19 Mar 2019, Eli Zaretskii wrote:
> On March 19, 2019 4:32:39 PM GMT+02:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> On March 19, 2019 3:06:15 PM GMT+02:00, "E. Choroba"
>> <choroba@matfyz.cz> wrote:
>>> Yes, I even tried to recompile the whole Emacs with the patched
>>> package.el to
>>> no avail.
>>>
>>> Maybe it's related to some other changes that happened between 26.1
>>> and the
>>> development version?
>>>
>>> Ch.
>>>
>>>
>> ==============================================================================
>>> On Tue, 19 Mar 2019, Eli Zaretskii wrote:
>>>>> Date: Tue, 19 Mar 2019 12:57:32 +0100 (CET)
>>>>> From: "E. Choroba" <choroba@matfyz.cz>
>>>>> cc: 34909@debbugs.gnu.org
>>>>>
>>>>>> The patch is below, should you want to install it locally.
>>>>>
>>>>> Thanks. I tried to apply the patch locally but the error persists
>>> (just
>>>>> running the above mentioned command).
>>>>
>>>> Did you byte-compile package.el after applying the patch?  If not,
>>>> either byte-compile it or load the .el file manually, and then try
>>>> again.
>>>>
>>>> I definitely cannot reproduce the problem after the change,
>> whereas
>>> it
>>>> was 100% reproducible with your recipe before the change.
>>>>
>>
>> Then I'm stumped.  I don't see how any other changes could affect
>> this, but maybe try using package.el from the emacs-26 branch of the
>> Emacs Git repository.
>>
>> If that doesn't fix the problem, either, I guess someone will have to
>> reproduce and tell which code requests coding-system, in addition to
>> what I fixed.
>
> Maybe try emptying your melpa/archive-contents file, perhaps it got corrupted by the buggy code you ran before the fix.
>

bug#34909: 26.1; Error refreshing packages under language environment

[Stefan Monnier]

> -            (progn (write-region content nil local-file nil 'silent)
> +            (progn (let ((coding-system-for-write 'utf-8))
> +                     (write-region content nil local-file nil 'silent))

This is probably safe, but I think the buffer should be unibyte and if
it isn't I think it indicates a bug elsewhere (likely in
package--with-response-buffer tho its use in describe-package-1 might
prefer a decoded (aka multibyte) result).


        Stefan

bug#34909: 26.1; Error refreshing packages under language environment

[Eli Zaretskii]

> Date: Tue, 19 Mar 2019 16:49:12 +0100 (CET)
> From: "E. Choroba" <choroba@matfyz.cz>
> cc: bug-gnu-emacs@gnu.org, 34909@debbugs.gnu.org
> 
> Sorry, I noticed the behaviour is a bit different: it still displays the "Bad 
> Signature" error, but it doesn't ask for encoding anymore. So it seems your 
> fix helped a bit, but maybe there's a similar problem in the epg package?

Ah, okay.  Unfortunately, this doesn't happen for me, so I guess it
either has been fixed in the epg package since 26.1 release, or has
something to do with versions of GPG different from what is installed
on the GNU/Linux machine where I tested the fix.

If someone can reproduce this with the current release branch, please
follow up with the details.

bug#34909: 26.1; Error refreshing packages under language environment

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: "E. Choroba" <choroba@matfyz.cz>,  34909@debbugs.gnu.org
> Date: Tue, 19 Mar 2019 12:27:24 -0400
> 
> > -            (progn (write-region content nil local-file nil 'silent)
> > +            (progn (let ((coding-system-for-write 'utf-8))
> > +                     (write-region content nil local-file nil 'silent))
> 
> This is probably safe, but I think the buffer should be unibyte

It isn't unibyte because no one makes it unibyte.  package.el uses
temporary buffers with no special settings, so everything is basically
determined by user locale's defaults.

> and if it isn't I think it indicates a bug elsewhere (likely in
> package--with-response-buffer tho its use in describe-package-1
> might prefer a decoded (aka multibyte) result).

Feel free to work on package--with-response-buffer in this direction.
Debugging this was a small nightmare, due to the use of macros and
async retrieval with callbacks, so I felt lucky when I finally found
the problematic code and understood why it worked in the English
language environment.  I don't feel I know enough about package.el to
make more significant changes, sorry, and as you point out, it is used
in several places in several different ways.

(I also don't understand why you say the buffer must be unibyte: if
the coding-systems for each operation are set correctly, there should
be no difference at all, not nowadays.  IME, using unibyte buffers is
just the easy way out when one doesn't want to mess with the
coding-systems stuff.)

bug#34909: 26.1; Error refreshing packages under language environment

[Stefan Monnier]

> (I also don't understand why you say the buffer must be unibyte: if
> the coding-systems for each operation are set correctly, there should
> be no difference at all, not nowadays.  IME, using unibyte buffers is
> just the easy way out when one doesn't want to mess with the
> coding-systems stuff.)

Of course, when dealing with data we only transfer from network to file,
using unibyte (or more specifically: without decoding nor encoding) is
simply more efficient, but it's also safer: Encoding using utf-8 is only
safe if the decoding was itself done using the same coding system and
I don't see where we do that, so it's not clear that it's always decoded
with utf-8.

> Feel free to work on package--with-response-buffer in this direction.
> Debugging this was a small nightmare, due to the use of macros and
> async retrieval with callbacks, so I felt lucky when I finally found
> the problematic code and understood why it worked in the English
> language environment.

"nightmare" is very appropriate, indeed.


        Stefan

bug#34909: 26.1; Error refreshing packages under language environment

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: choroba@matfyz.cz,  34909@debbugs.gnu.org
> Date: Tue, 19 Mar 2019 15:41:27 -0400
> 
> > (I also don't understand why you say the buffer must be unibyte: if
> > the coding-systems for each operation are set correctly, there should
> > be no difference at all, not nowadays.  IME, using unibyte buffers is
> > just the easy way out when one doesn't want to mess with the
> > coding-systems stuff.)
> 
> Of course, when dealing with data we only transfer from network to file,
> using unibyte (or more specifically: without decoding nor encoding) is
> simply more efficient, but it's also safer: Encoding using utf-8 is only
> safe if the decoding was itself done using the same coding system and
> I don't see where we do that, so it's not clear that it's always decoded
> with utf-8.

Did you also look in url-*.el stuff, which package.el invokes?

My motivation to use UTF-8 instead of making the buffer unibyte was
that select-safe-coding-system popped up a buffer which clearly showed
characters, not raw bytes, and it offered to select UTF-8, not
raw-text.  This can mean only one thing: that text in the buffer is
already correctly represented, and the problem was with an attempt to
encode it using a coding-system which cannot handle some of the text
(specifically, Chinese characters and a few Latin characters not
supported by ISO 8859-2).

> > Feel free to work on package--with-response-buffer in this direction.
> > Debugging this was a small nightmare, due to the use of macros and
> > async retrieval with callbacks, so I felt lucky when I finally found
> > the problematic code and understood why it worked in the English
> > language environment.
> 
> "nightmare" is very appropriate, indeed.

I will just add that the wider becomes our use of sophisticated Lisp
techniques in core packages, the harder it will be to debug our own
code.  I really wish someone would start some serious work on
expanding our debugging facilities and making them adequate for
debugging the kind of code we see in package.el.  'Nough said.

bug#34909: 26.1; Error refreshing packages under language environment

[Eli Zaretskii]

> Date: Tue, 19 Mar 2019 20:34:29 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 34909@debbugs.gnu.org
> 
> > Date: Tue, 19 Mar 2019 16:49:12 +0100 (CET)
> > From: "E. Choroba" <choroba@matfyz.cz>
> > cc: bug-gnu-emacs@gnu.org, 34909@debbugs.gnu.org
> > 
> > Sorry, I noticed the behaviour is a bit different: it still displays the "Bad 
> > Signature" error, but it doesn't ask for encoding anymore. So it seems your 
> > fix helped a bit, but maybe there's a similar problem in the epg package?
> 
> Ah, okay.  Unfortunately, this doesn't happen for me, so I guess it
> either has been fixed in the epg package since 26.1 release, or has
> something to do with versions of GPG different from what is installed
> on the GNU/Linux machine where I tested the fix.

FWIW, I just installed a stock Emacs 26.1 on that machine, patched its
package.el with the change committed for this bug, and the problem
disappeared for me.  I repeated the recipe twice, both with French and
Czech language environments, and they both work fine.  So there's some
other factor at work here, and I don't know what that could be.

bug#34909: 26.1; Error refreshing packages under language environment

[Noam Postavsky]

"E. Choroba" <choroba@matfyz.cz> writes:

> Sorry, I noticed the behaviour is a bit different: it still displays
> the "Bad Signature" error, but it doesn't ask for encoding anymore. So
> it seems your fix helped a bit, but maybe there's a similar problem in
> the epg package?

Maybe this is Bug#33825 or Bug#25532/33045?

bug#34909: 26.1; Error refreshing packages under language environment

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  34909@debbugs.gnu.org
> Date: Wed, 20 Mar 2019 08:45:05 -0400
> 
> "E. Choroba" <choroba@matfyz.cz> writes:
> 
> > Sorry, I noticed the behaviour is a bit different: it still displays
> > the "Bad Signature" error, but it doesn't ask for encoding anymore. So
> > it seems your fix helped a bit, but maybe there's a similar problem in
> > the epg package?
> 
> Maybe this is Bug#33825 or Bug#25532/33045?

Could be.  But 33825 talks about something that comes and goes,
whereas this present problem doesn't seem to be going anywhere.  25532
sounds like what I fixed, while 33045 is even more strange: it happens
in en_US.UTF-8 locale, where the bug reported here didn't rear its
head...

So I'm still confused.  But thanks for bringing this up, it seems to
confirm that some other factor(s) is/are at work here.

bug#34909: 26.1; Error refreshing packages under language environment

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> FWIW, I just installed a stock Emacs 26.1 on that machine, patched its
> package.el with the change committed for this bug, and the problem
> disappeared for me.  I repeated the recipe twice, both with French and
> Czech language environments, and they both work fine.  So there's some
> other factor at work here, and I don't know what that could be.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

E. Choroba, are you still seeing this issue with more recent Emacs
versions?

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

bug#34909: 26.1; Error refreshing packages under language environment

[E. Choroba]

I'm now on 27.1, the problem is gone *shrug*.

Ch.

==============================================================================
On Tue, 12 Apr 2022, Lars Ingebrigtsen wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> FWIW, I just installed a stock Emacs 26.1 on that machine, patched its
>> package.el with the change committed for this bug, and the problem
>> disappeared for me.  I repeated the recipe twice, both with French and
>> Czech language environments, and they both work fine.  So there's some
>> other factor at work here, and I don't know what that could be.
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> E. Choroba, are you still seeing this issue with more recent Emacs
> versions?
>
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog: http://lars.ingebrigtsen.no
>

bug#34909: 26.1; Error refreshing packages under language environment

[Lars Ingebrigtsen]

"E. Choroba" <choroba@matfyz.cz> writes:

> I'm now on 27.1, the problem is gone *shrug*.

OK; I'm closing this bug report, then.

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