Problems building CVS source.

Problems building CVS source.

[Mattias Ahnberg]

I've been downloading the last three days source to try to get this
working, but I can't figure it out and the problem haven't solved
itself. A friend tried to build it on his machine and succeeded but I
have done everything I could come to think of myself on my machine,
with and without my .emacs where I set various variables and settings,
and with and without a lot of automatically loaded modules.

This is the error I'm getting:

  [18:40:54] ahnberg@paranoia:~/ttt/gnus$ make
  cd lisp && make EMACS="emacs" lispdir="yes" all
  make[1]: Entering directory `/home/ahnberg/ttt/gnus/lisp'
  rm -f *.elc gnus-load.el
  URLDIR=/usr/share/emacs21/site-lisp/url/ W3DIR=/usr/share/emacs21/site-lisp/w3-el/ lispdir=yes srcdir=. emacs -batch -q -no-site-file -l ./dgnushack.el -f dgnushack-make-cus-load .
  Loading cus-dep...
  Directory .
  Generating cus-load.el...
  Wrong type argument: stringp, (mm-inline-text-html-with-w3m-keymap custom-variable)
  make[1]: *** [gnus-load.el] Error 255
  make[1]: Leaving directory `/home/ahnberg/ttt/gnus/lisp'
  make: *** [lick] Error 2

Emacs version:

  GNU Emacs 21.2.2 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2002-10-16 on raven, modified by Debian

make version:

  [18:40:57] ahnberg@paranoia:~/ttt/gnus$ make --version
  GNU Make 3.80
  Copyright (C) 2002  Free Software Foundation, Inc.

Anyone have any tips, pointers or want to know more information to be
able to help me more?

Thank you in advance.

/ahnberg.

Re: Problems building CVS source.

[Kai Großjohann]

Mattias Ahnberg <mattias@ahnberg.pp.se> writes:

>   cd lisp && make EMACS="emacs" lispdir="yes" all

The lispdir=yes part appears fishy.  I think the value should be a
directory.  How does this value come about?

(I don't have problems building the CVS sources, with Emacs from
CVS.)

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Problems building CVS source.

[Mattias Ahnberg]

>> "KG" == Kai Großjohann <kai.grossjohann@uni-duisburg.de> writes:

KG> The lispdir=yes part appears fishy.  I think the value should be a
KG> directory.  How does this value come about?

I shouldn't have included that one. I just attempted a --with-lispdir
without an argument since someone on an IRC channel claimed that it
might work. It didn't. But it confused the mail. The solution with
removing the line from cus-dep.el worked though. I am running v0.08
from November 23ds CVS source now.

I do have another problem I found out just now. Upon entering a group
with unread mail pressing the space key I get:

  "Symbol's value as variable is void: downloaded"

But if I press space once again I am able to enter. Is this something
that changed recently that I should be aware of, some setting that I
missed? Or is it bychance a bug?

/ahnberg.

Re: Problems building CVS source.

[Kai Großjohann]

Mattias Ahnberg <mattias@ahnberg.pp.se> writes:

>>> "KG" == Kai Großjohann <kai.grossjohann@uni-duisburg.de> writes:
>
> KG> The lispdir=yes part appears fishy.  I think the value should be a
> KG> directory.  How does this value come about?
>
> I shouldn't have included that one. I just attempted a --with-lispdir
> without an argument since someone on an IRC channel claimed that it
> might work. It didn't. But it confused the mail. The solution with
> removing the line from cus-dep.el worked though. I am running v0.08
> from November 23ds CVS source now.

Well, what can I say.  I didn't know that Debian had a patched Emacs.

> I do have another problem I found out just now. Upon entering a group
> with unread mail pressing the space key I get:
>
>   "Symbol's value as variable is void: downloaded"
>
> But if I press space once again I am able to enter. Is this something
> that changed recently that I should be aware of, some setting that I
> missed? Or is it bychance a bug?

Can you provide a backtrace without bytecode?

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Problems building CVS source.

[Mattias Ahnberg]

>> "KG" == Kai Großjohann <kai.grossjohann@uni-duisburg.de> writes:

KG> When you have a backtrace without bytecode (or with little
KG> bytecode), post it.  (Posting is better than email because then
KG> more people can look at it.  Thanks.)

This is the backlog I get when I try to enter the group the first
time, upon attempting to join it a second time I don't get the
problem. I can try to enter one group, get the error, and then enter
another one. So it must be something checked once before joining a
group.

I couldn't follow your explanation more throughly with loading the
.el file and reproduce further since I don't know what function to
look at/for. :/

Thanks again.

/ahnberg

    Debugger entered--Lisp error: (void-variable downloaded)
      eval(downloaded)
      gnus-tree-highlight-node("" 1 6)
      gnus-tree-node-insert(["" "" "" "" "" "" "" "" "" ""] nil)
      gnus-tree-mode()
      gnus-get-tree-buffer()
      gnus-tree-open("nnfolder:incoming")
      gnus-summary-read-group-1("nnfolder:incoming" nil nil nil nil nil)
      gnus-summary-read-group("nnfolder:incoming" nil nil nil nil nil nil)                                                               gnus-group-read-group(nil nil nil)
      gnus-topic-read-group(nil)
      call-interactively(gnus-topic-read-group)
      recursive-edit()
      byte-code("Æ^H!\210Ç \210È    !\210\n\203?^@Éed\"^KV\2034^@eb\210Ê^K¥y\210`^\db\210Ê^K¥^KZy\210\f`|\210)Ëc\210eb\210ÌÍ !\210Î \21$
      debug(error (void-variable downloaded))
      eval(downloaded)
      gnus-tree-highlight-node("" 1 6)
      gnus-tree-node-insert(["" "" "" "" "" "" "" "" "" ""] nil)
      gnus-tree-mode()
      gnus-get-tree-buffer()
      gnus-tree-open("nnfolder:dalnet-admin")
      gnus-summary-read-group-1("nnfolder:dalnet-admin" nil nil nil nil nil)
      gnus-summary-read-group("nnfolder:dalnet-admin" nil nil nil nil nil nil)
      gnus-group-read-group(nil nil nil)
      gnus-topic-read-group(nil)
      call-interactively(gnus-topic-read-group)

Re: Problems building CVS source.

[Kai Großjohann]

Mattias Ahnberg <mattias@ahnberg.pp.se> writes:

>     Debugger entered--Lisp error: (void-variable downloaded)
>       eval(downloaded)
>       gnus-tree-highlight-node("" 1 6)
>       gnus-tree-node-insert(["" "" "" "" "" "" "" "" "" ""] nil)
>       gnus-tree-mode()

Ah, I see.  The function gnus-summary-highlight-line has changed to
grok the new variable downloaded, but gnus-tree-highlight-node has
not.  So I guess the solution is to add the
gnus-summary-highlight-line change to gnus-tree-highlight-node, as
well.  I would do it, but it seems to be a nontrivial change.  So
maybe I can get Kevin to do it :-)

In the meantime, the function gnus-tree-highlight-node (in
gnus-salt.el) has a let* statement.  There you can bind the variable
downloaded to nil, but putting (downloaded nil) together with the
other variables.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Problems building CVS source.

[Andi Hechtbauer]

Hi,

>>>>> Mattias Ahnberg writes:

    MA> I've been downloading the last three days source to try to get
    MA> this working, but I can't figure it out and the problem
    MA> [...]  
    MA> Generating cus-load.el...  Wrong type argument: stringp,
    MA> (mm-inline-text-html-with-w3m-keymap custom-variable)

I had this bite me some weeks ago.  The problem was Debian including a
different (too recent) cus-dep.el.  And Katsumi Yamaoka kindly pointed
us to the very spot:

>>>>> In <yotlk7jpm3jz.fsf@jpl.org>
>>>>>	Katsumi Yamaoka <yamaoka@jpl.org> wrote:

 >> --- cus-dep.el-20020917	2001-07-16 12:22:58 +0000
 >> +++ cus-dep.el-20020918	2002-09-18 16:01:21 +0000
 >> @@ -86,6 +86,8 @@
 >> (let ((members (get symbol 'custom-group))
 >> item where found)
 >> (when members
 >> +		  ;; So x and no-x builds won't differ.
 >> +		  (setq members (sort (copy-sequence members) 'string<))
 >> (while members
 >> (setq item (car (car members))
 >> members (cdr members)

 Katsumi> If Debian contains the 20020918 version of cus-dep.el, it
 Katsumi> seems to be fixed by simply applying the above patch
 Katsumi> reverse.

This has been confirmed to solve the Problem.

bye,
Andi