all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#34909: 26.1; Error refreshing packages under language environment
@ 2019-03-18 21:32 E. Choroba
  2019-03-19 11:23 ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: E. Choroba @ 2019-03-18 21:32 UTC (permalink / raw)
  To: 34909

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2019-03-18 21:32 bug#34909: 26.1; Error refreshing packages under language environment E. Choroba
@ 2019-03-19 11:23 ` Eli Zaretskii
  2019-03-19 11:57   ` E. Choroba
  2019-03-19 16:27   ` Stefan Monnier
  0 siblings, 2 replies; 19+ messages in thread
From: Eli Zaretskii @ 2019-03-19 11:23 UTC (permalink / raw)
  To: E. Choroba; +Cc: 34909

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





^ permalink raw reply related	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2019-03-19 11:23 ` Eli Zaretskii
@ 2019-03-19 11:57   ` E. Choroba
  2019-03-19 12:29     ` Eli Zaretskii
  2019-03-19 16:27   ` Stefan Monnier
  1 sibling, 1 reply; 19+ messages in thread
From: E. Choroba @ 2019-03-19 11:57 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 34909

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2019-03-19 11:57   ` E. Choroba
@ 2019-03-19 12:29     ` Eli Zaretskii
  2019-03-19 13:06       ` E. Choroba
  0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2019-03-19 12:29 UTC (permalink / raw)
  To: E. Choroba; +Cc: 34909

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2019-03-19 12:29     ` Eli Zaretskii
@ 2019-03-19 13:06       ` E. Choroba
  2019-03-19 14:32         ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: E. Choroba @ 2019-03-19 13:06 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 34909

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2019-03-19 13:06       ` E. Choroba
@ 2019-03-19 14:32         ` Eli Zaretskii
  2019-03-19 14:43           ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2019-03-19 14:32 UTC (permalink / raw)
  To: E. Choroba; +Cc: 34909

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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2019-03-19 14:32         ` Eli Zaretskii
@ 2019-03-19 14:43           ` Eli Zaretskii
  2019-03-19 15:49             ` E. Choroba
  0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2019-03-19 14:43 UTC (permalink / raw)
  To: 34909, choroba

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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2019-03-19 14:43           ` Eli Zaretskii
@ 2019-03-19 15:49             ` E. Choroba
  2019-03-19 18:34               ` Eli Zaretskii
  2019-03-20 12:45               ` Noam Postavsky
  0 siblings, 2 replies; 19+ messages in thread
From: E. Choroba @ 2019-03-19 15:49 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 34909

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2019-03-19 11:23 ` Eli Zaretskii
  2019-03-19 11:57   ` E. Choroba
@ 2019-03-19 16:27   ` Stefan Monnier
  2019-03-19 18:44     ` Eli Zaretskii
  1 sibling, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2019-03-19 16:27 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 34909, E. Choroba

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2019-03-19 15:49             ` E. Choroba
@ 2019-03-19 18:34               ` Eli Zaretskii
  2019-03-20  7:00                 ` Eli Zaretskii
  2019-03-20 12:45               ` Noam Postavsky
  1 sibling, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2019-03-19 18:34 UTC (permalink / raw)
  To: E. Choroba; +Cc: 34909

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2019-03-19 16:27   ` Stefan Monnier
@ 2019-03-19 18:44     ` Eli Zaretskii
  2019-03-19 19:41       ` Stefan Monnier
  0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2019-03-19 18:44 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 34909, choroba

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2019-03-19 18:44     ` Eli Zaretskii
@ 2019-03-19 19:41       ` Stefan Monnier
  2019-03-19 20:00         ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2019-03-19 19:41 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 34909, choroba

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2019-03-19 19:41       ` Stefan Monnier
@ 2019-03-19 20:00         ` Eli Zaretskii
  0 siblings, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2019-03-19 20:00 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 34909, choroba

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2019-03-19 18:34               ` Eli Zaretskii
@ 2019-03-20  7:00                 ` Eli Zaretskii
  2022-04-12 16:40                   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2019-03-20  7:00 UTC (permalink / raw)
  To: choroba; +Cc: 34909

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2019-03-19 15:49             ` E. Choroba
  2019-03-19 18:34               ` Eli Zaretskii
@ 2019-03-20 12:45               ` Noam Postavsky
  2019-03-20 13:09                 ` Eli Zaretskii
  1 sibling, 1 reply; 19+ messages in thread
From: Noam Postavsky @ 2019-03-20 12:45 UTC (permalink / raw)
  To: E. Choroba; +Cc: 34909

"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?






^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2019-03-20 12:45               ` Noam Postavsky
@ 2019-03-20 13:09                 ` Eli Zaretskii
  0 siblings, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2019-03-20 13:09 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: 34909, choroba

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2019-03-20  7:00                 ` Eli Zaretskii
@ 2022-04-12 16:40                   ` Lars Ingebrigtsen
  2022-04-12 22:52                     ` E. Choroba
  0 siblings, 1 reply; 19+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-12 16:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 34909, choroba

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2022-04-12 16:40                   ` Lars Ingebrigtsen
@ 2022-04-12 22:52                     ` E. Choroba
  2022-04-12 23:27                       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 19+ messages in thread
From: E. Choroba @ 2022-04-12 22:52 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 34909

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
>





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34909: 26.1; Error refreshing packages under language environment
  2022-04-12 22:52                     ` E. Choroba
@ 2022-04-12 23:27                       ` Lars Ingebrigtsen
  0 siblings, 0 replies; 19+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-12 23:27 UTC (permalink / raw)
  To: E. Choroba; +Cc: 34909

"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





^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2022-04-12 23:27 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-03-18 21:32 bug#34909: 26.1; Error refreshing packages under language environment E. Choroba
2019-03-19 11:23 ` Eli Zaretskii
2019-03-19 11:57   ` E. Choroba
2019-03-19 12:29     ` Eli Zaretskii
2019-03-19 13:06       ` E. Choroba
2019-03-19 14:32         ` Eli Zaretskii
2019-03-19 14:43           ` Eli Zaretskii
2019-03-19 15:49             ` E. Choroba
2019-03-19 18:34               ` Eli Zaretskii
2019-03-20  7:00                 ` Eli Zaretskii
2022-04-12 16:40                   ` Lars Ingebrigtsen
2022-04-12 22:52                     ` E. Choroba
2022-04-12 23:27                       ` Lars Ingebrigtsen
2019-03-20 12:45               ` Noam Postavsky
2019-03-20 13:09                 ` Eli Zaretskii
2019-03-19 16:27   ` Stefan Monnier
2019-03-19 18:44     ` Eli Zaretskii
2019-03-19 19:41       ` Stefan Monnier
2019-03-19 20:00         ` Eli Zaretskii

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.