Problem with the latest CVS build

Problem with the latest CVS build

[Daniel Pittman]

Updating from CVS as of 19:11:16 EST today, I get the following error in
many files:

  !! File error (("Cannot open load file" "mailheader"))

CVS told me that the file is no longer pertinent--IOW that it had been
'cvs remove'd from the repository.

Is this right, or are major changes afoot that will take some time to
get the CVS archive back into working shape?

        Daniel
 
-- 
Any form of power without responsibility, without direct and formal checks and
balances, is frightening to people -- and reasonably so. It should be frankly
admitted that hackers are frightening, and that the basis of this fear is not
irrational.
        -- Bruce Sterling

Re: Problem with the latest CVS build

[Lars Magne Ingebrigtsen]

Daniel Pittman <daniel@danann.net> writes:

>   !! File error (("Cannot open load file" "mailheader"))
> 
> CVS told me that the file is no longer pertinent--IOW that it had been
> 'cvs remove'd from the repository.

mailheader isn't a part of Gnus, so I've removed it from the
distribution. 

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

Re: Problem with the latest CVS build

[Daniel Pittman]

On 04 Dec 1999, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> Daniel Pittman <daniel@danann.net> writes:
> 
>>   !! File error (("Cannot open load file" "mailheader"))
>> 
>> CVS told me that the file is no longer pertinent--IOW that it had
>> been 'cvs remove'd from the repository.
> 
> mailheader isn't a part of Gnus, so I've removed it from the
> distribution. 

Oh. Um. That's probably a good thing(tm), I guess. The copy with my
older pgnus build is noted as part of Emacs but I can't locate it in the
packages I have installed with XEmacs.

Hmmm. Is this part of another Emacs mail client such an VM, rmail or
mh-e? I hope so as I can then install that package and be able to build.

If not... well, I guess that I need to file a bug report with the XEmacs
team and all... :/

        Daniel

-- 
The whole problem with the world is that fools and fanatics are always so
certain of themselves, but wiser people so full of doubts.
        -- Bertrand Russell

Re: Problem with the latest CVS build

[Shenghuo ZHU]

>>>>> "Daniel" == Daniel Pittman <daniel@danann.net> writes:

Daniel> On 04 Dec 1999, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
>> Daniel Pittman <daniel@danann.net> writes:
>> 
>>> !! File error (("Cannot open load file" "mailheader"))
>>> 
>>> CVS told me that the file is no longer pertinent--IOW that it had
>>> been 'cvs remove'd from the repository.
>> 
>> mailheader isn't a part of Gnus, so I've removed it from the
>> distribution. 

Daniel> Oh. Um. That's probably a good thing(tm), I guess. The copy
Daniel> with my older pgnus build is noted as part of Emacs but I
Daniel> can't locate it in the packages I have installed with XEmacs.

Daniel> Hmmm. Is this part of another Emacs mail client such an VM,
Daniel> rmail or mh-e? I hope so as I can then install that package
Daniel> and be able to build.

Daniel> If not... well, I guess that I need to file a bug report with
Daniel> the XEmacs team and all... :/

In XEmacs packages (mail-lib 1.24, gnus 1.41), it is included in gnus,
while in Emacs (20.4) it is in mail directory not gnus.

In XEmacs The file pop3.el is in mail-lib, while in Emacs, it is in
gnus.

Where should these files go?

Two other files, base64.el and md5.el, may face the same problem,
since w3 also has those files, but two copies are different.

-- 
Shenghuo

Re: Problem with the latest CVS build

[Mike Fabian]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> Where should these files go?
> 
> Two other files, base64.el and md5.el, may face the same problem,
> since w3 also has those files, but two copies are different.

I recently had the w3 directory before the gnus directory in my
load-path, which caused problems in Gnus because of the differences in
base64.el. The Gnus version of the function base64-encode-region has
an additional optional parameter which the w3-version of this function
doesn't have:

(defun base64-encode-region (start end &optional no-line-break)

Therefore I got errors about a wrong number of parameters while
accidentally using the w3-version of base64.el.

Mike

-- 
Mike Fabian   <mike.fabian@gmx.de>   <mike@nozomi.rhein-neckar.de>
In der Neckarhelle 81, D-69118 Heidelberg-Ziegelhausen
Telephone: +49(0)6221/809222

Re: Problem with the latest CVS build

[William M. Perry]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> >>>>> "Daniel" == Daniel Pittman <daniel@danann.net> writes:
> 
> Daniel> On 04 Dec 1999, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> >> Daniel Pittman <daniel@danann.net> writes:
> >> 
> >>> !! File error (("Cannot open load file" "mailheader"))
> >>> 
> >>> CVS told me that the file is no longer pertinent--IOW that it had
> >>> been 'cvs remove'd from the repository.
> >> 
> >> mailheader isn't a part of Gnus, so I've removed it from the
> >> distribution. 
> 
> Daniel> Oh. Um. That's probably a good thing(tm), I guess. The copy
> Daniel> with my older pgnus build is noted as part of Emacs but I
> Daniel> can't locate it in the packages I have installed with XEmacs.
> 
> Daniel> Hmmm. Is this part of another Emacs mail client such an VM,
> Daniel> rmail or mh-e? I hope so as I can then install that package
> Daniel> and be able to build.
> 
> Daniel> If not... well, I guess that I need to file a bug report with
> Daniel> the XEmacs team and all... :/
> 
> In XEmacs packages (mail-lib 1.24, gnus 1.41), it is included in gnus,
> while in Emacs (20.4) it is in mail directory not gnus.
> 
> In XEmacs The file pop3.el is in mail-lib, while in Emacs, it is in
> gnus.
> 
> Where should these files go?
> 
> Two other files, base64.el and md5.el, may face the same problem, since
> w3 also has those files, but two copies are different.

Are they?  That's not good.  I am probably going to stop distributing them
with Emacs/W3 and put them in a 'you need this for older emacsen' type of
tarball.  I'm even thinking of making ssl.el, socks.el, and devices.el
their own downloads.  Then there would be a 'sumo' tarball for Emacs/W3
that would look like:

sumo-w3/configure
sumo-w3/w3/lisp
sumo-w3/w3/texi
sumo-w3/url/lisp
sumo-w3/url/texi
sumo-w3/misc/lisp

The sumo-w3/configure would just do AC_CONFIG_SUBDIRS(w3 url misc).
Eventually, everything in misc will be part of Emacs/XEmacs, so it can
gradually be phased out.  I'd say when Emacs 21.x is released, most of it
is already obsolete in XEmacs.

I've updated the base64.el with Emacs/W3, but I can't tell which md5.el is
newer.  The one with Emacs/W3 has newer copyright notices.

-Bill P.

Re: Problem with the latest CVS build

[Dave Love]

>>>>> "ZSH" == Shenghuo ZHU <zsh@cs.rochester.edu> writes:

 ZSH> In XEmacs The file pop3.el is in mail-lib, while in Emacs, it is in
 ZSH> gnus.

I think that's wrong in Emacs and I was proposing to move it under
mail.

Re: Problem with the latest CVS build

[Dave Love]

>>>>> "Bill" == William M Perry <wmperry@aventail.com> writes:

 Bill> I am probably going to stop distributing them with Emacs/W3 and
 Bill> put them in a 'you need this for older emacsen' type of
 Bill> tarball.

Note that md5.el isn't distributed with Emacs.  I don't think it has
an assignment.

Re: Problem with the latest CVS build

[Lloyd Zusman]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> >>>>> "Daniel" == Daniel Pittman <daniel@danann.net> writes:
> 
> Daniel> On 04 Dec 1999, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> >> Daniel Pittman <daniel@danann.net> writes:
> >> 
> >>> !! File error (("Cannot open load file" "mailheader"))
> >>> 
> >>> CVS told me that the file is no longer pertinent--IOW that it had
> >>> been 'cvs remove'd from the repository.
> >> 
> >> mailheader isn't a part of Gnus, so I've removed it from the
> >> distribution. 
> 
> [ ... ]
> 
> In XEmacs packages (mail-lib 1.24, gnus 1.41), it is included in gnus,
> while in Emacs (20.4) it is in mail directory not gnus.

Well, I'm using XEmacs, which means that `mailheader' is part of its
`gnus' package.  But I'm not using the XEmacs distribution of gnus,
but rather, the CVS version.  Therefore, I don't have access to
`mailheader'.

I believe that the XEmacs/CVS-gnus combination is fairly common, at
least among readers of this mailing list, and so what is the
recommended way for us XEmacs/CVS-gnus users to get `mailheader'
so we can keep using the CVS distribution?

Thanks in advance.

> [ ... ]

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Problem with the latest CVS build

[Hans de Graaff]

Lloyd Zusman <ljz@asfast.com> writes:

> I believe that the XEmacs/CVS-gnus combination is fairly common, at
> least among readers of this mailing list, and so what is the
> recommended way for us XEmacs/CVS-gnus users to get `mailheader' so
> we can keep using the CVS distribution?

I've grabbed a version from an older Gnus archive that still had this
file. I've put a copy in my site-lisp directory, but since that isn't
found during compilation I'm getting a bunch of warning while
byte-compiling. It seems to work, though.

Perhaps Lars could add a copy of mailheader in the contrib directory?

Hans

Re: Problem with the latest CVS build

[Lloyd Zusman]

Hans de Graaff <graaff@xs4all.nl> writes:

> Lloyd Zusman <ljz@asfast.com> writes:
> 
> > I believe that the XEmacs/CVS-gnus combination is fairly common, at
> > least among readers of this mailing list, and so what is the
> > recommended way for us XEmacs/CVS-gnus users to get `mailheader' so
> > we can keep using the CVS distribution?
> 
> I've grabbed a version from an older Gnus archive that still had this
> file. I've put a copy in my site-lisp directory, but since that isn't
> found during compilation I'm getting a bunch of warning while
> byte-compiling. It seems to work, though.

I get more than warnings when the byte compiling is going on.  I get
this ...

  !! File error (("Cannot open load file" "mailheader"))

... and then no `.elc' file gets created at all for each of the
files where this shows up.

> Perhaps Lars could add a copy of mailheader in the contrib directory?

Well, I took an old copy of `mailheader.el' and put it into the
`contrib' directory, but it still doesn't get seen during the standard
`make' procedure.

Aside from manually copying an old `mailheader.el' into the
`gnus/lisp' directory under the CVS tree, is there anything else that
an XEmacs/CVS-gnus user can do to get the CVS gnus to build?

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Problem with the latest CVS build

[Lloyd Zusman]

Lloyd Zusman <ljz@asfast.com> writes:

> [ ... ]
>
> Aside from manually copying an old `mailheader.el' into the
> `gnus/lisp' directory under the CVS tree, is there anything else that
> an XEmacs/CVS-gnus user can do to get the CVS gnus to build?

... and after doing this so at least I could get a version of Gnus
built, I realized that I got the same kind of error for `timer.el',
also which I needed to copy into the `gnus/lisp' directory before I
could build the CVS version under XEmacs.

Perhaps these kinds of problems could be handled via a change in
`Makefile' and the `configure' script, so we could specify an
extra directory (or even an extra PATH-like set of directories)
which could contain these files.  Then, we could do something like
this:

   ./configure --with-contrib=/path/to/this/extra/directory
   make EMACS=xemacs

Or alternatively, perhaps we could do it solely via a `Makefile'
change:

   make EMACS=xemacs CONTRIB=/path/to/this/extra/directory

Or is there already a way to do this sort of thing?

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Problem with the latest CVS build

[Hans de Graaff]

Lloyd Zusman <ljz@asfast.com> writes:

> ... and after doing this so at least I could get a version of Gnus
> built, I realized that I got the same kind of error for `timer.el',
> also which I needed to copy into the `gnus/lisp' directory before I
> could build the CVS version under XEmacs.

If you install the fsf-compat package the timer.el problem should be
solved. Given that mailheader.el does appear to be available in Emacs,
should the XEmacs maintainers add it to the fsf-compat package also?

Hans

Re: Problem with the latest CVS build

[Kai Großjohann]

Lloyd Zusman <ljz@asfast.com> writes:

> Well, I'm using XEmacs, which means that `mailheader' is part of its
> `gnus' package.  But I'm not using the XEmacs distribution of gnus,
> but rather, the CVS version.  Therefore, I don't have access to
> `mailheader'.

Why don't you install the normal Gnus package and then add the CVS
Gnus?  Just put the CVS Gnus directory first in load-path, and Bob
will be your uncle.

kai
-- 
A preposition is not a good thing to end a sentence with.

Re: Problem with the latest CVS build

[Lloyd Zusman]

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

> Lloyd Zusman <ljz@asfast.com> writes:
> 
> > Well, I'm using XEmacs, which means that `mailheader' is part of its
> > `gnus' package.  But I'm not using the XEmacs distribution of gnus,
> > but rather, the CVS version.  Therefore, I don't have access to
> > `mailheader'.
> 
> Why don't you install the normal Gnus package and then add the CVS
> Gnus?  Just put the CVS Gnus directory first in load-path, and Bob
> will be your uncle.

I have done exactly that, but the standard building procedure that
gets downloaded with CVS doesn't know about my normal load path, and
it can't find mailheader in the load path that *it* tries to use.

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Problem with the latest CVS build

[Lloyd Zusman]

[ I'm sorry for this re-post, but the I sent out the previous attempt
  before it was finished. ]

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

> Lloyd Zusman <ljz@asfast.com> writes:
> 
> > Well, I'm using XEmacs, which means that `mailheader' is part of its
> > `gnus' package.  But I'm not using the XEmacs distribution of gnus,
> > but rather, the CVS version.  Therefore, I don't have access to
> > `mailheader'.
> 
> Why don't you install the normal Gnus package and then add the CVS
> Gnus?  Just put the CVS Gnus directory first in load-path, and Bob
> will be your uncle.

I have done exactly that, but the standard building procedure that
gets downloaded with CVS doesn't know about my normal load path, and
it can't find mailheader in the load path that *it* tries to use.

As far as I know (and someone please correct me if I'm wrong), the
normal way for building an XEmacs-based CVS release goes like this,
starting after the latest CVS update has completed:

(1)  `cd' to the `gnus' subdirectory of the CVS tree.

(2)  Do this ...

       ./configure
       make EMACS=xemacs

The `make' step causes the following command to get executed:

  xemacs -batch -q -no-site-file -l ./dgnushack.el -f dgnushack-compile

The `-q' and `-no-site-file' options ensure that my own startup and
initialization files don't get loaded during this build.  Therefore,
there is no way for my own load path to be recognized during the
build.

That's the reason why `mailheader' and `timer' are not getting found
during the XEmacs build unless I actually put copies of them into
the `gnus/lisp' subdirectory.

There don't seem to be any options for `configure' or in any of the
makefiles which allow extra directories to be added to the load
path during the build.  This is why I suggested that perhaps
one or more of these files get changed so we could optionally
specify one or more directories to be added to these paths
during the Gnus build.

Any ideas?

Thanks in advance.

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Problem with the latest CVS build

[Gunnar Evermann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1615 bytes --]

Lloyd Zusman <ljz@asfast.com> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> 
> > Lloyd Zusman <ljz@asfast.com> writes:
> > 
> > > Well, I'm using XEmacs, which means that `mailheader' is part of its
> > > `gnus' package.  But I'm not using the XEmacs distribution of gnus,
> > > but rather, the CVS version.  Therefore, I don't have access to
> > > `mailheader'.
> > 
> > Why don't you install the normal Gnus package and then add the CVS
> > Gnus?  Just put the CVS Gnus directory first in load-path, and Bob
> > will be your uncle.
> 
> I have done exactly that, but the standard building procedure that
> gets downloaded with CVS doesn't know about my normal load path, and
> it can't find mailheader in the load path that *it* tries to use.


strange, can you post the output of something like:
  xemacs -batch -q -no-site-file -eval '(print load-path)' | tr ' ' '\n' | grep gnus


I get:
"/home/tigger3/ge204/.xemacs/xemacs-packages/lisp/pgnus-cvs/"
"/tools/emacs/lib/xemacs/xemacs-packages/lisp/gnus/"


where the first is a link to the CVS version's gnus/lisp directory and
the second is the normal XEmacs Gnus package (currently using Gnus
5.6.44 or somesuch). Thus the normal users get the old XEmacs package
and I get the bleeding edge CVS snapshots.

This setup is certainly not perfect (e.g. I guess the auto-autoload.el
should be rebuilt by Gnus' Makefile) but it Works For Me(tm).

BTW, we are still looking for a volunteer to package Gnus5.8.x for
XEmacs :-)

 Gunnar

-- 
       Gunnar Evermann
Speech, Vision & Robotics Group
Cambridge University Engineering Department

Re: Problem with the latest CVS build

[Lloyd Zusman]

Gunnar Evermann <ge204@eng.cam.ac.uk> writes:

> Lloyd Zusman <ljz@asfast.com> writes:
> 
> > Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> > 
> > > Lloyd Zusman <ljz@asfast.com> writes:
> > > 
> > > > [ ... ]
> > > 
> > > Why don't you install the normal Gnus package and then add the CVS
> > > Gnus?  Just put the CVS Gnus directory first in load-path, and Bob
> > > will be your uncle.
> > 
> > I have done exactly that, but the standard building procedure that
> > gets downloaded with CVS doesn't know about my normal load path, and
> > it can't find mailheader in the load path that *it* tries to use.
> 
> 
> strange, can you post the output of something like:
>   xemacs -batch -q -no-site-file -eval '(print load-path)' | tr ' ' '\n' | grep gnus
> 
> 
> I get:
> "/home/tigger3/ge204/.xemacs/xemacs-packages/lisp/pgnus-cvs/"
> "/tools/emacs/lib/xemacs/xemacs-packages/lisp/gnus/"

I get this:


Yes, no output.  That's because there's nothing Gnus-like in my
load-path.  And now I think I understand what Kai Großjohann meant
when he said (above) to "... install the normal Gnus package ...".  He
did *not* mean to simply install Gnus-5.8.x in my local area that gets
pointed to the `load-path' that I set in my `.emacs', which is what I
have been doing for over a year.  What he *did* mean was to do an
official XEmacs package installation of the Gnus package.  I'm pretty
sure that once I do this, I'll have what I need in my load-path when I
do the CVS build ... correct?

So ... in order for the CVS build to work, the standard XEmacs Gnus
package that it replaces has to be installed, and at least one file
that was explicitly removed from the CVS build (namely
`mailheader.el') needs to be referenced from the standard Gnus build
that the CVS build is supposed to supersede.

But something seems wrong about this: what happens once the CVS build
finally becomes the official Gnus build?  Then, there won't be any
`mailheader.el' anywhere, which means that Gnus as written today wouldn't
work under XEmacs ... right?

So therefore, either `mailheader.el' needs to become part of the CVS
build once again, or else it has to become part of some other
installable XEmacs package, or else Gnus needs to be rewritten so as
not to need `mailheader.el' at all.


But anyway, thanks very much.  Your question about `load-path' helped
me to see what I have to do to get my CVS working for the short term.


> [ ... ]

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Problem with the latest CVS build

[Hrvoje Niksic]

Hans de Graaff <graaff@xs4all.nl> writes:

> Lloyd Zusman <ljz@asfast.com> writes:
> 
> > ... and after doing this so at least I could get a version of Gnus
> > built, I realized that I got the same kind of error for
> > `timer.el', also which I needed to copy into the `gnus/lisp'
> > directory before I could build the CVS version under XEmacs.
> 
> If you install the fsf-compat package the timer.el problem should be
> solved.

timer.el is only devised for easy porting of things that require it,
not for use in packages like Gnus.

> Given that mailheader.el does appear to be available in Emacs,
> should the XEmacs maintainers add it to the fsf-compat package also?

fsf-compat is for things that have equivalent XEmacs functionality.
If I read `mailheader.el', it has nothing to do in fsf-compat.  I'd
say it belongs to the `mail-lib' package.

Re: Problem with the latest CVS build

[Jan Vroonhof]

Hrvoje Niksic <hniksic@iskon.hr> writes:

> timer.el is only devised for easy porting of things that require it,
> not for use in packages like Gnus.

On the other hand nobody has done the work to port Gnus to itimer yet.

Jan

Re: Problem with the latest CVS build

[Kai Großjohann]

Lloyd Zusman <ljz@asfast.com> writes:

> [...]  And now I think I understand what Kai Großjohann meant
> when he said (above) to "... install the normal Gnus package ...".  He
> did *not* mean to simply install Gnus-5.8.x in my local area that gets
> pointed to the `load-path' that I set in my `.emacs', which is what I
> have been doing for over a year.  What he *did* mean was to do an
> official XEmacs package installation of the Gnus package.  I'm pretty
> sure that once I do this, I'll have what I need in my load-path when I
> do the CVS build ... correct?[...]

Right.  What you said is what I meant, and I'm pretty confident that
the load-path problems will be gone, then.

kai
-- 
A preposition is not a good thing to end a sentence with.

Re: Problem with the latest CVS build

[Hrvoje Niksic]

Jan Vroonhof <vroonhof@math.ethz.ch> writes:

> Hrvoje Niksic <hniksic@iskon.hr> writes:
> 
> > timer.el is only devised for easy porting of things that require it,
> > not for use in packages like Gnus.
> 
> On the other hand nobody has done the work to port Gnus to itimer
> yet.

Huh?

What does this code do in nnheaderxmas.el, then:

(defun nnheader-xmas-run-at-time (time repeat function &rest args)
  (start-itimer
   "nnheader-run-at-time"
   `(lambda ()
      (,function ,@args))
   time repeat))

(fset 'nnheader-run-at-time 'nnheader-xmas-run-at-time)
(fset 'nnheader-cancel-timer 'delete-itimer)

AFAIK, Gnus has *never* required `timer.el' under XEmacs, probably
because one hasn't existed.

Re: Problem with the latest CVS build

[Jan Vroonhof]

Hrvoje Niksic <hniksic@iskon.hr> writes:

> What does this code do in nnheaderxmas.el, then:

<To play the devels-advocate:> It is duplicating code from timer.el

> (defun nnheader-xmas-run-at-time (time repeat function &rest args)
>   (start-itimer
>    "nnheader-run-at-time"
>    `(lambda ()
>       (,function ,@args))
>    time repeat))
> 
> (fset 'nnheader-run-at-time 'nnheader-xmas-run-at-time)
> (fset 'nnheader-cancel-timer 'delete-itimer)
> 
> AFAIK, Gnus has *never* required `timer.el' under XEmacs, probably
> because one hasn't existed.

This isn't supporting "itimer" at all. This is writing your own emulation
library. I don't see how that is preferable over using timer.el apart
from that we can then bitch a Lars if there are bugs.

We need namespaces...

</To play the devels-advocate>

>From gnus-async.el

	  (if (not (fboundp 'run-with-idle-timer))
	      ;; This is either an older Emacs or XEmacs, so we
	      ;; do this, which leads to slightly slower article
	      ;; buffer display.
	      (gnus-async-prefetch-article group next summary)
	    (run-with-idle-timer
	     0.1 nil 'gnus-async-prefetch-article group next summary)))))))

Note that you need a 21.1.9 for it to actually work because itimer is
broken (still lives in Emacs 18 times to much).

Jan