Bug 474958 - update-directory-autoloads broken
update-directory-autoloads broken
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: emacs (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Novotny
Fedora Extras Quality Assurance
:
: 522746 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-05 21:01 EST by Wolfgang Rupprecht
Modified: 2013-01-09 23:57 EST (History)
2 users (show)

See Also:
Fixed In Version: emacs-23.1-13.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-19 05:57:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Wolfgang Rupprecht 2008-12-05 21:01:46 EST
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 07:52:14 EDT
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 08:23:48 EDT
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 09:07:43 EDT
*** Bug 522746 has been marked as a duplicate of this bug. ***
Comment 4 Daniel Novotny 2009-10-12 09:10:05 EDT
(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 08:47:58 EDT
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 09:01:49 EDT
(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 09:29:43 EDT
Seems setq-ing the variable in site-lisp.el fixes the problem.
Comment 8 Daniel Novotny 2009-10-16 09:30:53 EDT
(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 05:57:14 EDT
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-24 20:59:16 EDT
emacs-23.1-19.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/emacs-23.1-19.fc12
Comment 11 Fedora Update System 2010-03-30 19:17:35 EDT
emacs-23.1-11.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/emacs-23.1-11.fc11
Comment 12 Fedora Update System 2010-04-01 12:09:51 EDT
emacs-23.1-13.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/emacs-23.1-13.fc11
Comment 13 Fedora Update System 2010-04-20 09:08:29 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.