Your message dated Sat, 13 Oct 2007 13:00:57 +0900 (JST)
with message-id <[EMAIL PROTECTED]>
and subject line w3m-el: cookies broken for Australian XEmacs users
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: w3m-el
Version: 1.3.3-2
Severity: normal
(Have a look in w3m.el at where w3m-time-parse-string is declared and
this will make more sense)
w3m.el chooses the wrong implementation of w3m-time-parse-string,
since the test fails. The test fails due to a misunderstanding over
the timezone "EST", but otherwise the original version is good (the
later version doesn't work at all).
Once the broken (later) w3m-time-parse-string function is chosen,
parsing a cookie timestring returns lots of nils and the cookies are
declared expired and ignored.
I've been using this in my init.el, and it seems to be working fine:
;; bugfix. w3m.el decides this isn't any good (and installs a worse
;; version) because timezone-fix-time thinks "EST" is American EST,
;; not Australian EST.. other than that (unavoidable
;; misunderstanding), this version is good
(eval-after-load "w3m"
(setq w3m-time-parse-string
(function
(lambda (string)
"Parse the time-string STRING and return its time as Emacs style."
(ignore-errors
(let ((x (timezone-fix-time string nil nil)))
(encode-time (aref x 5) (aref x 4) (aref x 3)
(aref x 2) (aref x 1) (aref x 0)
(aref x 6))))))))
I presume the two versions are an emacs vs xemacs thing, I haven't
checked on FSF emacs. A possible solution would be to always choose
the earlier version when running on xemacs (and perhaps have a
versioned conflict on some xemacs.deb if we find it didn't work at
some point in the past), or to use "+1100" style timezones during the
test, which are immune to such "EST" ambiguities.
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux dolly 2.4.20-686 #1 Sat Dec 21 15:58:35 EST 2002 i686
Pentium II (Deschutes) GenuineIntel GNU/Linux
Versions of the packages w3m-el depends on:
ii apel 10.4-1 Portable Emacs Library
ii w3m 0.3.1-3 WWW browsable pager with excellent tables/fr
ii w3m-ssl 0.3-2 WWW browsable pager with SSL support
ii xemacs21 21.4.6-8 Editor and kitchen sink
emacs20 Not installed or no info
emacs21 Not installed or no info
emacs20 Not installed or no info
emacs21 Not installed or no info
w3mmee Not installed or no info
--
- Gus
pgpMGrlbbWPgo.pgp
Description: PGP signature
--- End Message ---
--- Begin Message ---
Version: 1.3.3-2
On January 18, 2003 at 3:32PM +1100,
gus (at debian.org) wrote:
> Package: w3m-el
> Version: 1.3.3-2
> Severity: normal
>
> (Have a look in w3m.el at where w3m-time-parse-string is declared and
> this will make more sense)
>
> w3m.el chooses the wrong implementation of w3m-time-parse-string,
> since the test fails. The test fails due to a misunderstanding over
> the timezone "EST", but otherwise the original version is good (the
> later version doesn't work at all).
>
> Once the broken (later) w3m-time-parse-string function is chosen,
> parsing a cookie timestring returns lots of nils and the cookies are
> declared expired and ignored.
>
>
> I've been using this in my init.el, and it seems to be working fine:
>
> ;; bugfix. w3m.el decides this isn't any good (and installs a worse
> ;; version) because timezone-fix-time thinks "EST" is American EST,
> ;; not Australian EST.. other than that (unavoidable
> ;; misunderstanding), this version is good
> (eval-after-load "w3m"
> (setq w3m-time-parse-string
> (function
> (lambda (string)
> "Parse the time-string STRING and return its time as Emacs style."
> (ignore-errors
> (let ((x (timezone-fix-time string nil nil)))
> (encode-time (aref x 5) (aref x 4) (aref x 3)
> (aref x 2) (aref x 1) (aref x 0)
> (aref x 6))))))))
>
>
> I presume the two versions are an emacs vs xemacs thing, I haven't
> checked on FSF emacs. A possible solution would be to always choose
> the earlier version when running on xemacs (and perhaps have a
> versioned conflict on some xemacs.deb if we find it didn't work at
> some point in the past), or to use "+1100" style timezones during the
> test, which are immune to such "EST" ambiguities.
[...]
> ii xemacs21 21.4.6-8 Editor and kitchen sink
This bug appeared with the old version of XEmacs. Debian no longer
supports XEmacs 21.4.16 and earlier versions. Closing.
Thanks,
--
Tatsuya Kinoshita
pgpmzQ8b9hJH8.pgp
Description: PGP signature
--- End Message ---
