bug#34983: 27.0.50; Gnus cannot start

[Eric Abrahamsen]

On 03/25/19 07:36 AM, Bastien wrote:
> Hi Eric,
>
> good luck with fixing this.
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> This is frustrating -- this was the most important part of the patch,
>> and the part I thought I'd tested most thoroughly. At worst I think Gnus
>> may be trying to read .newsrc.eld using the wrong encoding, so I don't
>> think you will have lost anything permanently. (Still, I'm very sorry
>> this is causing you Gnus outage.)
>>
>> First -- did you run "make bootstrap" before running this new version?
>
> No.  I regularily build Emacs from the master branch but I only use
> `make' to compile it then.  I had no idea I had to `make bootstrap'.
> Why was it necessary after your commit?

My commit changed the definition of some macros, and some *elc files
with the older definitions are still hanging around. This does happen
from time to time when you're running master, though in this case it
coincides with a real bug. You can also just delete all the *elc files
in lisp/gnus and run regular "make". This will fix some of the problems
you're seeing, though from the backtrace below and your previous report
it looks like you've also maybe got a literal "nil" as a group name in
your newsrc.eld.

>> Second, can you tell me if your non-ascii group names are being saved in
>> .newsrc.eld in utf-8, or if they have literal byte sequences in them?
>
> There is no literal byte sequence in the .newsrc.eld file that I was
> able to backup, right after I got this Gnus initialization error.

But there are group names with properly-encoded non-ascii names? There
shouldn't be, which is why I'm curious.

> Now I recompiled an Emacs from before your commit.  Starting with my
> backup does trigger this error:
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   intern(nil [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ...])
>   gnus-make-hashtable-from-newsrc-alist()
>   gnus-read-newsrc-el-file("/home/guerry/.newsrc.el")
>   gnus-read-newsrc-file(nil)
>   gnus-setup-news(nil nil nil)
>   #f(compiled-function () #<bytecode 0x1559c202fd35>)()
>   gnus-1(nil nil nil)
>   gnus(nil)
>   funcall-interactively(gnus nil)
>   call-interactively(gnus record nil)
>   command-execute(gnus record)
>   execute-extended-command(nil "gnus" "gnus")
>   funcall-interactively(execute-extended-command nil "gnus" "gnus")
>   call-interactively(execute-extended-command nil nil)
>   command-execute(execute-extended-command)
>
> ... so I suspect I did not save my .newsrc.eld in time to properly use
> it with a stable Emacs (too bad).
>
> I hope I will be able to find my group subscriptions and my marks.

I don't think you will have lost any data! There's probably just a bogus
group name or two in your newsrc.eld file which is preventing Gnus from
starting up. If you feel comfortable doing this, would you send me your
.newsrc.eld file off list?

Sorry for this train wreck...

> I'm trying to better understand a few things, can you educate me?
>
> What is the Gnus "active" file?
> Where is it on my computer?
> What is the .newsrc.eld file?
> What is the difference between .newsrc.eld and the active file?

Basil's explanations are correct, I'll just add that you've only got
one.newsrc.eld file, recording marks for all the groups you're
subscribed to, but each of your backends produces its own active file,
saying what groups it contains, and what the newest messages are. For
nntp you request it from the server. For nnml it lives on your computer
(I think it goes under (concat gnus-home-directory "News/")). For
nnimap, the server sends Gnus a list of groups and Gnus munges the list
into something that *looks* like an active file. Gnus knows if you have
new mail by comparing the active file information with your.newsrc.eld
information.

Eric