From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/61936 Path: news.gmane.org!not-for-mail From: Ted Stern Newsgroups: gmane.emacs.gnus.general Subject: Re: Total expiry not working -- is clock skew the problem? Date: Wed, 08 Feb 2006 12:56:24 -0800 Organization: The Boeing Company Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: sea.gmane.org 1139499801 31237 80.91.229.2 (9 Feb 2006 15:43:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 9 Feb 2006 15:43:21 +0000 (UTC) Original-X-From: ding-owner+m10462@lists.math.uh.edu Thu Feb 09 16:43:05 2006 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F7Dvp-0003aR-ET for ding-account@gmane.org; Thu, 09 Feb 2006 16:42:13 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1F7Dvj-0005Qk-00; Thu, 09 Feb 2006 09:41:59 -0600 Original-Received: from nas01.math.uh.edu ([129.7.128.39]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1F6wOV-0001dY-00 for ding@lists.math.uh.edu; Wed, 08 Feb 2006 14:58:31 -0600 Original-Received: from quimby.gnus.org ([80.91.224.244]) by nas01.math.uh.edu with esmtp (Exim 4.52) id 1F6wOS-0000zs-6P for ding@lists.math.uh.edu; Wed, 08 Feb 2006 14:58:31 -0600 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1F6wOQ-0008VZ-00 for ; Wed, 08 Feb 2006 21:58:26 +0100 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1F6wNo-0008Tm-Fh for ding@gnus.org; Wed, 08 Feb 2006 21:57:50 +0100 Original-Received: from orca.drizzle.com ([216.162.192.15]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Feb 2006 21:57:48 +0100 Original-Received: from dodecatheon by orca.drizzle.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Feb 2006 21:57:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: ding@gnus.org Original-Lines: 103 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: orca.drizzle.com User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) Cancel-Lock: sha1:1kru+xEg3WhDorI7tA7pnBJz1T4= X-Spam-Score: -2.6 (--) Precedence: bulk Original-Sender: ding-owner@lists.math.uh.edu Xref: news.gmane.org gmane.emacs.gnus.general:61936 Archived-At: On 7 Feb 2006 at 19:37 UTC-0800, Katsumi Yamaoka wrote: >>>>> In Ted Stern wrote: > >> One more note -- if I set expiry-wait to 0.0 on a topic, that works >> perfectly. It is only non-zero values that do not work. > >> On 7 Feb 2006 at 08:28 UTC-0800, Ted Stern wrote: > >>> I started a new job about 100 days ago and had to reconstitute my >>> entire Gnus setup, almost from scratch. In my old job, I had total >>> expiry turned on and articles expired with no problems. Now I have >>> total expiry turned on in the group parameters for an entire topic, >>> but nothing has expired automatically since day one. > > Well, you're talking about nnfolder groups, aren't you? Yes, sorry for not being more specific! > If so, how does the X-Gnus-Article-Number header in old articles > look? (You may need to type `t' in the summary buffer.) Here is one example: X-Gnus-Article-Number: 1 Mon Nov 7 12:45:27 2005 This looks like it should be in the right format, right? Other details: - I have threads sorted by date, not number. From ~/.gnus: (setq gnus-sort-gathered-threads-function 'gnus-thread-sort-by-date) (setq gnus-thread-sort-functions '( (not gnus-thread-sort-by-most-recent-date) )) - My mailing list email comes to me through a tortuous path: => gmail account, adding extra headers at beginning => fwd'd to company mail => goes through company mail filter that filters for spam and adds extra headers => procmail, in which I filter out gmail forwarding headers at beginning. So is it possible that Gnus is not seeing the X-Gnus-Article-Number header because it comes after a bunch of other headers? > For example, it should be something like: > > X-Gnus-Article-Number: 1234 Tue Feb 7 08:28:55 2006 > > Where 1234 is an article number and the rest is a timestamp. Gnus > will look at this timestamp to decide whether to expire the article, > so if there's no such header, the time stamp is corrupted or it > shows a future date, expiring will not take place. I have no more > idea if those are going well. > > BTW, expiring might be executed in your machine eight hours earlier > than the time specified with expiry-wait. It is because the > timestamp in the X-Gnus-Article-Number header is made by the > current-time-string function and doesn't have a timezone info. For > instance: > > (progn > (setenv "TZ" "PST8PDT") ;; -0800 > (/ (time-to-seconds (time-since (current-time-string))) 3600)) > => 8.000075615555556 Aha. This could be the problem. There is a problem with time-since input in my Emacs. (progn (setenv "TZ" "PST8PDT") ;; -0800 (time-since (current-time-string))) ,----[ lisp debugger output, bytecode deleted and linebreaks added ] | Debugger entered--Lisp error: (wrong-type-argument listp \ | "Wed Feb 8 12:45:24 2006") | time-since("Wed Feb 8 12:45:24 2006") | (progn (setenv "TZ" "PST8PDT") (time-since (current-time-string))) | eval((progn (setenv "TZ" "PST8PDT") (time-since (current-time-string)))) | eval-last-sexp-1(t) | eval-last-sexp(t) | eval-print-last-sexp() | call-interactively(eval-print-last-sexp) | recursive-edit() | byte-code("" \ | [unread-command-char debugger-args x debugger-buffer noninteractive \ | debugger-batch-max-lines -1 debug backtrace-debug 4 t backtrace-frame \ | lambda 5 pop-to-buffer debugger-mode debugger-setup-buffer count-lines 2 \ | "...\n" message "%s" buffer-string kill-emacs "" nil "" \ | recursive-edit middlestart buffer-read-only standard-output] 4) `---- Did you mean to use 'current-time' instead of 'current-time-string'? In any case, I don't get any GMT/PST8PDT difference. Ted -- dodecatheon at gmail dot com Frango ut patefaciam -- I break so that I may reveal