Minimum emacs version for Oort

Minimum emacs version for Oort

[Paul Stevenson]

Hello,

Is there an official minimum emacs version required for ognus?  As of
cancel-locks being added, my 20.3.1 seems not good enough:

While compiling the end of the data in file [...]/emacs/ognus/lisp/canlock.el:
  ** the function base64-encode-string is not known to be defined.

So I can't send news...  Short of persuading the sysadmin to upgrade
emacs, which I know he'd put at the bottom of a large pile of jobs, am
I restricted to older gnusæ?

yours,
Paul Stevenson

Re: Minimum emacs version for Oort

[Simon Josefsson]

Paul Stevenson <p.stevenson@surrey.ac.uk> writes:

> Hello,
>
> Is there an official minimum emacs version required for ognus? 
> As of cancel-locks being added, my 20.3.1 seems not good enough:

The manual says Emacs 20.3 or XEmacs 20.4 or later, so if those 
doesn't work, it is a bug.

> While compiling the end of the data in file 
> [...]/emacs/ognus/lisp/canlock.el: ** the function 
> base64-encode-string is not known to be defined.
>
> So I can't send news...  Short of persuading the sysadmin to 
> upgrade emacs, which I know he'd put at the bottom of a large 
> pile of jobs, am I restricted to older gnusæ?

No.  Does your emacs have `base64-encode-region'?  As a workaround 
put gnus/contrib in your load path.

Re: Minimum emacs version for Oort

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> No.  Does your emacs have `base64-encode-region'?  As a workaround put
> gnus/contrib in your load path.

The base64.el there does not have base64-encode-string, so that won't help.

kai
-- 
Simplification good!  Oversimplification bad!  (Larry Wall)

Re: Minimum emacs version for Oort

[Paul Stevenson]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

S Josefsson writes:

> Paul Stevenson <p.stevenson@surrey.ac.uk> writes:
> 
> > Hello,
> >
> > Is there an official minimum emacs version required for ognus? As of
> > cancel-locks being added, my 20.3.1 seems not good enough:
> 
> The manual says Emacs 20.3 or XEmacs 20.4 or later, so if those
> doesn't work, it is a bug.

Oh. Oh yes. My bad.

> > While compiling the end of the data in file
> > [...]/emacs/ognus/lisp/canlock.el: ** the function
> > base64-encode-string is not known to be defined.
> >
> > So I can't send news...  Short of persuading the sysadmin to upgrade
> > emacs, which I know he'd put at the bottom of a large pile of jobs,
> > am I restricted to older gnusæ?
> 
> No.  Does your emacs have `base64-encode-region'?  As a workaround put
> gnus/contrib in your load path.

Again, my bad (as they say these days).  I jumped to the wrong
conclusion about the above message.  It finds the base64 stuff just
fine.

Here's the backtrace of what happens when it fails 


[-- Attachment #2: backtrace --]
[-- Type: application/octet-stream, Size: 596 bytes --]

Re: Minimum emacs version for Oort

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> No.  Does your emacs have `base64-encode-region'?  As a 
>> workaround put gnus/contrib in your load path.
>
> The base64.el there does not have base64-encode-string, so that 
  won't help.
 
Oops.  Paul, does the following patch work? 

--- canlock.el.~6.5.~	Wed Jan  9 16:25:50 2002
+++ canlock.el	Mon Jan 21 16:32:48 2002
@@ -103,6 +103,18 @@
 	(list 'string-as-unibyte string)
       string)))
 
+(defun canlock-base64-encode-string (string &optional no-line-break)
+  (save-excursion
+    (set-buffer (get-buffer-create " *base64-encode*"))
+    (erase-buffer)
+    (insert string)
+    (base64-encode-region (point-min) (point-max) no-line-break)
+    (skip-chars-backward " \t\r\n")
+    (delete-region (point-max) (point))
+    (prog1
+	(buffer-string)
+      (kill-buffer (current-buffer)))))
+
 (defun canlock-sha1-with-openssl (message)
   "Make a SHA-1 digest of MESSAGE using OpenSSL."
   (let (default-enable-multibyte-characters)
@@ -153,7 +165,7 @@
 	(opad (mapconcat (lambda (char)
 			   (char-to-string (logxor 92 char)))
 			 password "")))
-    (base64-encode-string
+    (canlock-base64-encode-string
      (funcall canlock-sha1-function
 	      (concat
 	       opad
@@ -250,8 +262,8 @@
 		(insert "Cancel-Key: sha1:" key-for-key "\n"))
 	      (when key-for-lock
 		(insert "Cancel-Lock: sha1:"
-			(base64-encode-string (funcall canlock-sha1-function
-						       key-for-lock))
+			(canlock-base64-encode-string
+			 (funcall canlock-sha1-function key-for-lock))
 			"\n")))))))))
 
 ;;;###autoload
@@ -307,8 +319,8 @@
 	(when locks
 	  (when id-for-lock
 	    (setq key-for-lock
-		  (base64-encode-string (funcall canlock-sha1-function
-						 (canlock-make-cancel-key
+		  (canlock-base64-encode-string
+		   (funcall canlock-sha1-function (canlock-make-cancel-key
 						  id-for-lock password))))
 	    (when (and locks (not match))
 	      (setq match (string-equal key-for-lock (pop locks)))))

Re: Minimum emacs version for Oort

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>
>> The base64.el there does not have base64-encode-string, so that
>   won't help.
>  Oops.  Paul, does the following patch work?

I'm not sure if Emacs 20.3 already has base64 support in C code.  If
not, then I guess that it would be better to define
base64-{de,en}code-string in base64.el, don't you think?

kai
-- 
Simplification good!  Oversimplification bad!  (Larry Wall)

Re: Minimum emacs version for Oort

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>>
>>> The base64.el there does not have base64-encode-string, so 
>>> that won't help.  >> >>  Oops.  Paul, does the following patch 
>>> work?
>
> I'm not sure if Emacs 20.3 already has base64 support in C code.

Perhaps only elisp.  MIME etc needs some kind of base64 support. 
Paul, which functions does C-h f base64 TAB TAB expand to?

> If not, then I guess that it would be better to define 
> base64-{de,en}code-string in base64.el, don't you think?

Well, contrib/base64.el isn't part of the "real" Gnus 
distribution, or is it?  (Due to copyright reasons.)  If it isn't, 
it probably makes sense to include the wrapper in a file that is 
part of the real distribution.  Or?

But now that I actually look in contrib/base64.el my copy do have 
b-{d,e}-string.  So it would work as a workaround.  Does your copy 
differ?

Re: Minimum emacs version for Oort

[Paul Stevenson]

S Josefsson writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>
>> Simon Josefsson <jas@extundo.com> writes:
>>
>>> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>>>
>>>> The base64.el there does not have base64-encode-string, so that
>>>> won't help.  >> >>  Oops.  Paul, does the following patch work?
>>
>> I'm not sure if Emacs 20.3 already has base64 support in C code.
>
> Perhaps only elisp.  MIME etc needs some kind of base64 support. Paul,
> which functions does C-h f base64 TAB TAB expand to?


base64-decode			   base64-decode-region
base64-decode-string		   base64-encode
base64-encode-region		   base64-encode-string
base64-insert-char		   base64-run-command-on-region
base64-xemacs-insert-char

Aha! They come from ~/emacs/tramp/lisp

perhaps I should change the ordering of my load-path


> But now that I actually look in contrib/base64.el my copy do have
> b-{d,e}-string.  So it would work as a workaround.  Does your copy
> differ?
>

no, mine has that too.

-- 
.   Paul Stevenson   .   Research Fellow   .   University of Surrey     .
.     phone: +44 (0) 1483 686795     .     fax +44 (0) 1483 686781      .
.    p.stevenson@surrey.ac.uk  .  http://www.ph.surrey.ac.uk/~phs3ps    .

Re: Minimum emacs version for Oort

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> But now that I actually look in contrib/base64.el my copy do have
> b-{d,e}-string.  So it would work as a workaround.  Does your copy
> differ?

Ah, I completely missed those functions (they are defaliases).  Cool.

Paul, what happens when you do the following?

emacs -q -no-site-file -batch --eval "(print (featurep 'base64))"

If it prints t, then Emacs has base64 support in the C code.  Then a
workaround for base64-encode-string should be in canlock.  If it
prints nil, then (require 'base64) in canlock.el should do the trick.

kai
-- 
Simplification good!  Oversimplification bad!  (Larry Wall)

Re: Minimum emacs version for Oort

[Paul Stevenson]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

K Großjohann writes:

> Paul, what happens when you do the following?
>
> emacs -q -no-site-file -batch --eval "(print (featurep 'base64))"
>
> If it prints t, then Emacs has base64 support in the C code.  Then a
> workaround for base64-encode-string should be in canlock.  If it
> prints nil, then (require 'base64) in canlock.el should do the trick.

It prints nil

(require 'base64) doesn't seem to do the trick. I don't know that the
warning:
  ** the function base64-encode-string is not known to be defined.
is really relevant - base64 stuff ends up in the load path.

Posting news fails in either of two ways, one, which involves emacs
crashing gives the backtrace I posted previously (out of memory).
When that doesn't happen, I get the following backtrace


[-- Attachment #2: backtrace 2 --]
[-- Type: application/octet-stream, Size: 496 bytes --]

[-- Attachment #3: Type: text/plain, Size: 297 bytes --]


so it looks like it can find the base64 stuff okay, but it does bad
things.

I changed my load-path so that it found the ognus/contrib dir before
the tramp/lisp dir, but it made no difference.  No wonder:

[~/emacs] erwin1 $ diff tramp/lisp/base64.el ognus/contrib/base64.el 
[~/emacs] erwin1 $ 

Re: Minimum emacs version for Oort

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Paul, what happens when you do the following?
>
> emacs -q -no-site-file -batch --eval "(print (featurep 'base64))"
>
> If it prints t, then Emacs has base64 support in the C code. 
> Then a workaround for base64-encode-string should be in canlock. 
> If it prints nil, then (require 'base64) in canlock.el should do 
> the trick.

Emacs 20.3 doesn't seem to have base64 at all, neither in C nor in 
elisp.  The MIME stuff in Gnus seems to require Base64 though. 
Should the requirement in the manual be bumped to Emacs 20.4? 
That version does have base64 support (in C).

Re: Minimum emacs version for Oort

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> Emacs 20.3 doesn't seem to have base64 at all, neither in C nor in
> elisp.  The MIME stuff in Gnus seems to require Base64 though. Should
> the requirement in the manual be bumped to Emacs 20.4? That version
> does have base64 support (in C).

Well, for the time being I think we should keep 20.3 support (at least
until the end of Oort).  20.3 users just have to include gnus/contrib
in their load-path.  For No Gnus, we should ditch support for XEmacs
20 and Emacs 20 altogether.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Minimum emacs version for Oort

[Lars Magne Ingebrigtsen]

Paul Stevenson <p.stevenson@surrey.ac.uk> writes:

>   base64-encode-string("[...]")
>   canlock-make-cancel-key("<i5k3d0zeq0k.latex@wigner.ph.surrey.ac.uk>" "25176d145e0fa7957038be84e0f3213b649ef234")

It looks like canlock is running base64-encode-string on multibyte
data.  That's not valid.  It probably wants to run that function on
binary data, so some appropriate `coding-system-for-*' variables
should probably be bound somewhere.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Minimum emacs version for Oort

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Paul Stevenson <p.stevenson@surrey.ac.uk> writes:
>
>>   base64-encode-string("[...]")
>>   canlock-make-cancel-key("<i5k3d0zeq0k.latex@wigner.ph.surrey.ac.uk>" "25176d145e0fa7957038be84e0f3213b649ef234")
>
> It looks like canlock is running base64-encode-string on multibyte
> data.  That's not valid.  It probably wants to run that function on
> binary data, so some appropriate `coding-system-for-*' variables
> should probably be bound somewhere.

I wrapped the input to base64-encode-string in a string-as-unibyte.
(The data isn't in a buffer, so I don't think coding-system-for-*
applies.)

Re: Minimum emacs version for Oort

[Kai Großjohann]

Paul Stevenson <p.stevenson@surrey.ac.uk> writes:

> Aha! They come from ~/emacs/tramp/lisp

Ick.  So that copy of base64.el is too old.  I see.  So I will update
the copy in Tramp.

Btw, Tramp now has base64.el in a contrib subdir as well, so by
default you won't use its base64.el.  Do you have an old version of
Tramp?  (Not sure when I made that change.)

kai
-- 
Simplification good!  Oversimplification bad!  (Larry Wall)

Re: Minimum emacs version for Oort

[Kai Großjohann]

Kai.Grossjohann@cs.uni-dortmund.de (Kai Großjohann) writes:

> Paul Stevenson <p.stevenson@surrey.ac.uk> writes:
>
>> Aha! They come from ~/emacs/tramp/lisp
>
> Ick.  So that copy of base64.el is too old.  I see.  So I will update
> the copy in Tramp.

It turns out that the current Tramp has the same base64.el as the
current Gnus (both from CVS) -- says M-x compare-windows RET.

kai
-- 
Simplification good!  Oversimplification bad!  (Larry Wall)

Re: Minimum emacs version for Oort

[Paul Stevenson]

K Großjohann writes:

> It turns out that the current Tramp has the same base64.el as the
> current Gnus (both from CVS) -- says M-x compare-windows RET.

Oh well,  I've solved my problems by customizing message-insert-canlock.  

Paul