GNU bug report logs - #41530
28.0.50; gnus-cloud-download-all-data does not mark articles as read

Previous Next

Package: emacs;

Reported by: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>

Date: Mon, 25 May 2020 16:50:02 UTC

Severity: normal

Found in version 28.0.50

To reply to this bug, email your comments to 41530 AT debbugs.gnu.org.

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#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):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; gnus-cloud-download-all-data does not mark articles as read
Date: Mon, 25 May 2020 18:49:16 +0200
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.