GNU bug report logs -
#41530
28.0.50; gnus-cloud-download-all-data does not mark articles as read
Previous Next
To reply to this bug, email your comments to 41530 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41530
; Package
emacs
.
(Mon, 25 May 2020 16:50:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 25 May 2020 16:50:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello,
I'm having trouble setting up gnus-cloud. Here are the steps I
follow:
0. Clean the slate.
- On my IMAP server's webmail:
- delete all mails generated by gnus-cloud,
- delete the Emacs-Cloud folder.
- In system 1's .newsrc.eld:
- remove all gnus-cloud-* variables,
- remove Emacs-Cloud from gnus-newsrc-alist.
- On system 2: remove .newsrc.eld.
On both systems 1 and 2, gnus-cloud-method is customized to
"nnimap:gmail".
1. On system 1: upload a CloudSynchronizationDataPack™.
- Start Emacs & Gnus.
- In the *Server* buffer:
- hit i on NNTP servers.
- In the *Group* buffer:
- hit ~ u, enter & confirm passphrase.
So far, things seem to be working… maybe? I have a new mail from
nobody <at> gnus.cloud.invalid in the Emacs-Cloud group, entitled
> (sequence: UNKNOWN type: :full storage-method: epg)
(Looking at gnus-cloud.el, i have no idea how this "UNKNOWN" ends up
here, since I see no reason for gnus-cloud-sequence to be nil.)
If I decrypt this mail, I can see one Lisp form per subscribed group,
of the form
> (:type :newsrc-data :name "…" :contents (…) :timestamp "…")
Moving on…
2. On system 2: try to download the CloudSynchronizationDataPack™.
- Start Emacs & Gnus.
- In the *Server* buffer:
- hit i on NNTP servers,
- subscribe to groups system 1 is subscribed to.
- In the *Group* buffer:
- hit ~ d.
At this point I'd expect
1. to be prompted for the passphrase entered in step 1,
2. NNTP articles I've read on system 1 to be marked read on system 2.
Instead, nothing happens: no passphrase prompt, and all articles in the
NNTP groups I subscribed to remain unread. I just get this in
*Messages*:
> nnimap read 0k from [IMAP server].
I tried to dig into this; all I could figure out is that
gnus-cloud-available-chunks returns nil.
I *think* this is not linked to bug#40280; I applied the patch and not
much changed. From what I understand, the patch fixes a problem that
happens later, when processing whatever gnus-cloud-available-chunks is
supposed to return.
I don't know if this might be linked to bug#28845.
Let me know if there is anything I can do to help debug this.
Thank you for your time.
In GNU Emacs 28.0.50 (build 11, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, cairo version 1.15.10)
of 2020-05-25 built on klegouguec-HP-ProBook-450-G1
Repository revision: 0cdedf612b9da14fccc39c4a4e81cbf400e4552f
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12005000
System Description: Ubuntu 18.04.4 LTS
Configured using:
'configure --with-xwidgets --with-cairo'
Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS JSON
PDUMPER LCMS2 GMP
Important settings:
value of $LC_MONETARY: en_US.UTF-8
value of $LC_NUMERIC: en_US.UTF-8
value of $LC_TIME: en_US.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
This bug report was last modified 5 years and 24 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.