Bug 474958

Summary: update-directory-autoloads broken
Product: [Fedora] Fedora Reporter: Wolfgang Rupprecht <wolfgang.rupprecht>
Component: emacsAssignee: Daniel Novotny <dnovotny>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 10CC: dcantrell, lijian.gnu
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: emacs-23.1-13.fc11 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-19 09:57:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Wolfgang Rupprecht 2008-12-06 02:01:46 UTC
Description of problem:
autoloads can't be rebuilt by and end user because update-directory-autoloads references a temporary rpm build-time path.

Version-Release number of selected component (if applicable):
emacs.x86_64                       1:22.2-5.fc9 

How reproducible:
every time

Steps to Reproduce:
1. add ";;;###autoload" above a random defun in the emacs el sources
2. type M-x update-directory-autoloads
3. notice it chokes with: 
Loading autoload...done
autoload-ensure-default-file: Opening output file: no such file or directory, /builddir/build/BUILD/emacs-22.2/lisp/loaddefs.el
Actual results:
building a new set of autoloads fails

Expected results:
building a new set of autoloads is expected to work.

Additional info:
Some days are like this.  Attempting to fix a missing autoload for 
vm-decode-postponed-mime-message and I'm recursing deeper into emacs breakage.
I'm not sure I understand the rpm-build goop enough to go any further.

Comment 1 Daniel Novotny 2009-10-12 11:52:14 UTC
The problem is, that emacs compiles the .el files while we build the rpm, so the path inside them is $RPM_BUILD_ROOT instead of the dir, where it will be after installation. When I write there the right path, where they will reside, emacs can't find it while building :( ... I will analyze, if we can build in chroot (don't know if that's possible) or use some other way the compiled-in path will be right.

Comment 2 Daniel Novotny 2009-10-12 12:23:48 UTC
I see now there's --enable-locallisppath option to ./configure, I will see if it does what we want

Comment 3 Daniel Novotny 2009-10-12 13:07:43 UTC
*** Bug 522746 has been marked as a duplicate of this bug. ***

Comment 4 Daniel Novotny 2009-10-12 13:10:05 UTC
(In reply to comment #2)
> I see now there's --enable-locallisppath option to ./configure, I will see if
> it does what we want  
nope, that didn't help us

Comment 5 Daniel Novotny 2009-10-14 12:47:58 UTC
a piece of advice came from the emacs mailing list:

the path, which is used there, is in the "source-directory" variable,
so you can do something like

(let ((source-directory "/usr/share/emacs/23.1/lisp/"))
    (update-directory-autoloads "/path/to/scan/for/autoload/cookies"))

The important thing is that `update-directory-autoloads' wants to
write its output to

  (concat source-directory "lisp/loaddefs.el")

I will try to find some way to incorporate this change into the Fedora Emacs package.

Comment 6 Daniel Novotny 2009-10-14 13:01:49 UTC
(In reply to comment #5)
> (let ((source-directory "/usr/share/emacs/23.1/lisp/"))
>     (update-directory-autoloads "/path/to/scan/for/autoload/cookies"))

actually (source-directory "/usr/share/emacs/23.1/") works here. the "/lisp" is added afterwards by emacs

Comment 7 Daniel Novotny 2009-10-16 13:29:43 UTC
Seems setq-ing the variable in site-lisp.el fixes the problem.

Comment 8 Daniel Novotny 2009-10-16 13:30:53 UTC
(In reply to comment #7)
> Seems setq-ing the variable in site-lisp.el fixes the problem.  
site-start.el of course

Comment 9 Daniel Novotny 2009-10-19 09:57:14 UTC
I fixed this in rawhide (emacs-23.1-13.fc13)

if someone desperately wants a fix for an older release, please let me know, but all you need to do to fix this is to have

(setq source-directory "/usr/share/emacs/23.1/")

in a startup file

Comment 10 Fedora Update System 2010-03-25 00:59:16 UTC
emacs-23.1-19.fc12 has been submitted as an update for Fedora 12.

Comment 11 Fedora Update System 2010-03-30 23:17:35 UTC
emacs-23.1-11.fc11 has been submitted as an update for Fedora 11.

Comment 12 Fedora Update System 2010-04-01 16:09:51 UTC
emacs-23.1-13.fc11 has been submitted as an update for Fedora 11.

Comment 13 Fedora Update System 2010-04-20 13:08:29 UTC
emacs-23.1-13.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.