On Tue, 06 Dec 2011 22:17:57 +0100 Steinar Bang <sb@dod.no> wrote: 

>>>>>> Steinar Bang <sb@dod.no>:
>> However, on the home desktop, doing `gnus-sync-read' wasn't enough to
>> fix the issue.  I still get the error message (or a similar one) on all
>> attempts to `gnus-sync-save'.

SB> On the home desktop (debian testing, GNU Emacs 23.3.1), I get the
SB> following message in the mini-buffer when trying to do `gnus-sync-save': 
SB>  Wrong type argument: number-or-marker-p, "8-54ce40d61d4b92eda3bffb29c6e0b1c6"

SB> The stack trace, is:
SB>   (lambda (entry) (gnus-sync-lesync-pre-save-group-entry (cadr gnus-sync-backend) entry (cons ... ftime)))(("nntp+nntp.dod.no:no.alt.motorsykler" 6 ((1 . 33536)) ((subscribe-all) (_deleted_conflicts "8-54ce40d61d4b92eda3bffb29c6e0b1c6") (subscribe-all nil)) (nntp "nntp.dod.no") ((charset . iso-8859-1))))
SB>   mapcar((lambda (entry) (gnus-sync-lesync-pre-save-group-entry (cadr gnus-sync-backend) entry (cons ... ftime))) (("nntp+nntp.dod.no:no.alt.motorsykler" 6 (...) (... ... ...) (nntp "nntp.dod.no") (...)) ("nntp+news.gmane.org:gmane.linux.drivers.bcm54xx.devel" 6 (...) (... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.discuss" 3 (...) (... ... ... ... ...) "nntp:news.gmane.org") ("nntp+news.gmane.org:gmane.comp.db.postgresql.german" 7 nil (... ...) "nntp:news.gmane.org")))
SB>   (let* ((ftime ...) (url ...) (entries ...) (sync ...)) (mapcar (lambda ... ...) sync))
SB>   (cond ((and ... ... ...) (when force ...) (let* ... ...)) ((stringp gnus-sync-backend) (gnus-message 7 "gnus-sync-save: saving to backend %s" gnus-sync-backend) (let ... ...)) (nil))
SB>   gnus-sync-save(nil)
SB>   call-interactively(gnus-sync-save t nil)
SB>   execute-extended-command(nil)
SB>   call-interactively(execute-extended-command nil nil)

I'm at a conference so I can't do the code fix properly, but I think if
you try the attached patch it will fix the issue.

The root of the problem is that CouchDB saw a conflict and inserted a
parameter telling you so, and gnus-sync.el thinks the parameter is a
mark.  It's not a big deal.  The patch skips any such unused (by
gnus-sync.el) parameters with a warning but I'll think about better
handling at the root of the problem, when your save conflicts with
another.

Ted