Re: Questions about emacs-snapshot (and also a small patch)

[Daniel Brockman <daniel@brockman.se>]

Jérôme Marant <jmarant@free.fr> writes:

> Quoting Daniel Brockman <daniel@brockman.se>:
>
>> --- orig/patches/misc-unseparated.dpatch
>> +++ mod/patches/misc-unseparated.dpatch
>> @@ -57,1 +57,1 @@
>> - * Installation Changes in Emacs 21.4
>> + * Installation Changes in Emacs 22.1
>
> Coincidence: I fixed this patch yesterday.

Oh, cool.

> I also:
>  - integrated changes we introduced in 21.4a-1
>  - wrote a new script which automates the building of snapshots
>    from the CVS trunk and the packaging from my Bazaar archive
>
> I need to test changes and I currently have a slow machine
> (it takes 50 minutes to build packages).

Ouch.  Isn't there some Debian box you can use, or are those usually
under heavy load already?

> Announced soon.

Though I don't really understand the changed you described above, I'm
looking forward to it. :-)

>> By the way, is there any tla equivalent of `cvs diff'?
>
> Forget about tla. Use bazaar 1.3.2 from debian unstable.
>
> 'baz diff' is what you want.

Oh, my, yet another VCS...

>> Oh, and I seem to have a problem with getting `load-path' to include
>> entries starting with `/usr/local'.  I discovered this problem when I
>> did the following
>
> I don't see what you mean. Could you elaborate?

Do `<f1> v load-path RET C-x o C-s local' and see if there's any match
for you.  There isn't for me, and Trent Buck reported the same thing
on IRC a while ago.

As you'll know, Debian Emacs Policy[1] requires that every Emacs
flavor have the following entries in `load-path' (in this order):

    /usr/local/share/emacs/<upstream-version>/site-lisp
    /usr/local/share/emacs/site-lisp

This part of Policy is enforced, in a way, by the function
`debian-pkg-add-load-path-item' (in `debian-startup.el'):

    (if (not last-local-pos)
        (error "No /usr/local/ prefixed paths in load-path"))

This error is normally not very loud, even if the condition occurs,
because of how the package initialization files (which are the ones
that will call `debian-pkg-add-load-path-item') are loaded by the
function `debian-run-directories' in the same file:

         (condition-case ()
             (load file nil)
           (message "Error while loading %s" file))

(That is, all errors are suppressed and messages are printed instead.)

While the errors aren't loud, they do prevent packages from
being loaded.

>> --- old/debian-startup.el	2005-04-26 06:20:41.611076992 +0200
>> +++ new/debian-startup.el	2005-04-26 06:20:04.480721664 +0200
>> @@ -119,9 +119,10 @@
>>        ;; ordering.
>>        (mapcar
>>         (lambda (file)
>> -         (condition-case ()
>> +;;          (condition-case ()
>>               (load file nil)
>> -           (error (message "Error while loading %s" file))))
>> +;;            (error (message "Error while loading %s" file)))
>> +           )
>>         base-names)
>>        ;; restore the old load-path -- including any new paths added by
>>        ;; files loaded in directory traversal.
>>
>> in an attempt to figure out why certain packages were failing to load.
>> (Is there any better way to do this?)

What I meant here was, what is a good way to find out why a package is
failing to load?  The ``Error while loading 50foo'' messages are not
in themselves helpful.  For example,

Loading 50w3m-el (source)...
Error while loading 50w3m-el
Loading 50wget-el (source)...done
Loading 50whizzytex (source)...done
Loading 51debian-el (source)...
Error while loading 51debian-el
Loading 51planner-el (source)...
Error while loading 51planner-el

How do you know what needs to be done to fix the w3m-el, debian-el,
and planner-el packages?

>> I tried to work around the problem by adding the `/usr/local'-prefixed
>> load-path entries in `/etc/emacs-snapshot/site-start.el', but it turns
>> out that file is run AFTER the Debian package startup files, which I
>> suppose makes sense.

Disregard this part; it is more or less irrelevant.

>> I'm not sure what I'm trying to say here, except this:  If anyone can
>> shed some light on some of this, please do.
>
> I have no idea currently. How about looking into emacsen-common?

I think I've been looking into most stuff that has `emacs' in the name
recently. :-)

-- 
Daniel Brockman <daniel@brockman.se>