removing old installations

removing old installations

[Eric Abrahamsen]

I'm running the Ubuntu repository version of emacs (23.2.1) on Natty. In
the past I've tried compiling both emacs 24 and emacs 23 myself on this
machine, before deciding it was unnecessary and just using the
repository version. As near as I can tell I've cleared the old 24 and 23
installations out of my system, but leftover files are still interfering
with byte compilation in my present system.

Makefiles in external packages like gnus or org-mode set the executable
to "emacs" (ie, no full path). There are no other "emacs" executables on
my path, but still I need to change the makefiles to specify
"/usr/bin/emacs", or else I pick up weird bits from emacs 24, and my
compiled files behave strangely (I can provide more details). Even with
the full path to emacs specified, I get these warnings with each byte
compilation:

Warning: Lisp directory `/usr/local/share/emacs/23.2/site-lisp' does not exist.
Warning: Lisp directory `/usr/local/share/emacs/site-lisp' does not exist.

All my site-lisp directories are under /usr/share/emacs or
/usr/share/emacs23, and I don't know what configuration or startup files
are telling it to look under /usr/local/share.

Given that no other "emacs" executables are on my system (at least, to
the best of my knowledge, and I spent a while rooting them out), what
other leftover files could be confusing my present installation?

Thanks!
Eric

Re: removing old installations

[Peter Dyballa]

Am 25.06.2011 um 19:34 schrieb Eric Abrahamsen:

> Given that no other "emacs" executables are on my system (at least, to
> the best of my knowledge, and I spent a while rooting them out), what
> other leftover files could be confusing my present installation?


With locate (or find) you can find all instances of "emacs" and also  
"emacs-23.2" and "emacs-24.0.50" and remove them. The same for the  
version sub-directories "23.2" and "24.0.50" in /usr/local/libexec/ 
emacs and /usr/local/share/emacs.

You can launch that "emacs" binary in your PATH and choose from the  
Help menu "Send Bug Report…" or type M-x report-emacs-bug RET. In the  
*unsent mail to bug-gnu-emacs@gnu.org* buffer you'll find a text  
describing where and how this "emacs" was built.

Finally you can use the trace utilities to see which files and  
directories these "emacs" executable files open.

--
Greetings

   Pete

How many Microsoft engineers does it take to screw in a light-bulb?
None.
They just redefine "dark" as the new standard.

Re: removing old installations

[Eric Abrahamsen]

On Sat, Jun 25 2011, Peter Dyballa wrote:

> Am 25.06.2011 um 19:34 schrieb Eric Abrahamsen:
>
>> Given that no other "emacs" executables are on my system (at least, to
>> the best of my knowledge, and I spent a while rooting them out), what
>> other leftover files could be confusing my present installation?
>
>
> With locate (or find) you can find all instances of "emacs" and also
> "emacs-23.2" and "emacs-24.0.50" and remove them. The same for the
> version sub-directories "23.2" and "24.0.50" in
> /usr/local/libexec/emacs and /usr/local/share/emacs.
>
> You can launch that "emacs" binary in your PATH and choose from the
> Help menu "Send Bug Report…" or type M-x report-emacs-bug RET. In the
> *unsent mail to bug-gnu-emacs@gnu.org* buffer you'll find a text
> describing where and how this "emacs" was built.
>
> Finally you can use the trace utilities to see which files and
> directories these "emacs" executable files open.

Thanks for these tips! If you have a moment I hope you'll look at this
one step further.

I'm quite sure I've removed everything emacs-related from /usr/local/*.
One odd thing is, my emacs man file is located at
/usr/share/man/man1/emacs.1.gz (symlinked from
/etc/alternatives/emacs.1.gz), but within the FILES section of that man
page, it gives all the emacs-related paths as /usr/local/*. Not sure
what that's about.

The bug report data shows that emacs was compiled by Debian. I note that
--enable-locallisppath includes, among many other paths, the two paths
that emacs complains about when it's run from the command line.

Among the voluminous output of strace is:

access("/usr/local/share/emacs/23.2/site-lisp", F_OK) = -1 ENOENT (No such file or directory)
write(2, "Warning: Lisp directory `/usr/lo"..., 80) = 80
access("/usr/local/share/emacs/site-lisp", F_OK) = -1 ENOENT (No such file or directory)
write(2, "Warning: Lisp directory `/usr/lo"..., 75) = 75

But the same trace is absolutely stuffed with stat64 calls to half a
million non-existent files and directories (including lots of /usr/local
stuff), so I don't know why that should merit an error. If you or anyone
else is really interested, I've put a large chunk of the trace here:

http://pastebin.com/paWFrRGh

Is my only problem that emacs was compiled with some non-existent
directories in the lisploadpath?

Thanks,
Eric

Re: removing old installations

[Andreas Röhler]

Am 25.06.2011 19:34, schrieb Eric Abrahamsen:
> I'm running the Ubuntu repository version of emacs (23.2.1) on Natty. In
> the past I've tried compiling both emacs 24 and emacs 23 myself on this
> machine, before deciding it was unnecessary and just using the
> repository version. As near as I can tell I've cleared the old 24 and 23
> installations out of my system, but leftover files are still interfering
> with byte compilation in my present system.
>
> Makefiles in external packages like gnus or org-mode set the executable
> to "emacs" (ie, no full path). There are no other "emacs" executables on
> my path, but still I need to change the makefiles to specify
> "/usr/bin/emacs", or else I pick up weird bits from emacs 24, and my
> compiled files behave strangely (I can provide more details).


Hi,

that would be of interest for me, just to understand how Emacs behaves.


  Even with
> the full path to emacs specified, I get these warnings with each byte
> compilation:
>
> Warning: Lisp directory `/usr/local/share/emacs/23.2/site-lisp' does not exist.
> Warning: Lisp directory `/usr/local/share/emacs/site-lisp' does not exist.

Given the issue above wouldn't exist --which seems a more serious one--
that warning alone would tell me:

when Emacs was build these directories existed, now they are gone.
Then it should be OK providing empty directories to get rid of the 
warning. (?)

Andreas



>
> All my site-lisp directories are under /usr/share/emacs or
> /usr/share/emacs23, and I don't know what configuration or startup files
> are telling it to look under /usr/local/share.
>
> Given that no other "emacs" executables are on my system (at least, to
> the best of my knowledge, and I spent a while rooting them out), what
> other leftover files could be confusing my present installation?
>
> Thanks!
> Eric
>
>
>

Re: removing old installations

[Peter Dyballa]

Am 26.06.2011 um 00:57 schrieb Eric Abrahamsen:

> I'm quite sure I've removed everything emacs-related from /usr/local/ 
> *.
> One odd thing is, my emacs man file is located at
> /usr/share/man/man1/emacs.1.gz (symlinked from
> /etc/alternatives/emacs.1.gz), but within the FILES section of that  
> man
> page, it gives all the emacs-related paths as /usr/local/*. Not sure
> what that's about.

I've forgotten these! And there's more than one file:

-rw-r--r-- 1 root wheel  6367  9. Jun 21:38 man1/emacs.1.gz
-rw-r--r-- 1 root wheel  1632  9. Jun 21:38 man1/emacsclient.1.gz
-rw-r--r-- 1 root wheel  4444  9. Jun 21:38 man1/etags.1.gz
-rw-r--r-- 1 root wheel   993  9. Jun 21:38 man1/grep-changelog.1.gz
-rw-r--r-- 1 root wheel  1191  9. Jun 21:38 man1/rcs-checkin.1.gz
-rw-r--r-- 1 root wheel    37  9. Jun 21:38 man1/ctags.1.gz
-rw-r--r-- 1 root wheel  1128  9. Jun 21:38 man1/ebrowse.1.gz

Another area with around 90 files is /usr/local/share/info. And  
there's also /usr/local/share/applications/emacs.desktop!

The sym-links to /etc/alternatives are *not* from your "private"  
installation of GNU Emacs, they're presumably from Debian (package).  
The reason is that you can have more that one packaged GNU Emacs  
version on your PC. Then *some* man page must be present (similarly  
for the INFO files – and this Debian scheme really works quite fine,  
on my Mac).


>
> The bug report data shows that emacs was compiled by Debian.

So you can be sure now that it's not your own "private" Emacs!

> I note that --enable-locallisppath includes, among many other paths,  
> the two paths
> that emacs complains about when it's run from the command line.
>
> Among the voluminous output of strace is:
>
> access("/usr/local/share/emacs/23.2/site-lisp", F_OK) = -1 ENOENT  
> (No such file or directory)
> write(2, "Warning: Lisp directory `/usr/lo"..., 80) = 80
> access("/usr/local/share/emacs/site-lisp", F_OK) = -1 ENOENT (No  
> such file or directory)
> write(2, "Warning: Lisp directory `/usr/lo"..., 75) = 75

So presumably they're just *warnings*, not /errors/! You've deleted  
these directory branches when you found that they might contain data  
from your "private" installations, but they were created before when  
you installed some GNU Emacs package.

I'd recommend to check (the dates of) the MAN and INFO files. This  
step could be performed again after this most important step: remove  
all GNU Emacs packages from your PC to clean the situation as far as  
possible. (Then recheck the places I mentioned in my posts.) Finally  
re-install these packages/this package. It will create the paths GNU  
Emacs is complaining about.

>
> Is my only problem that emacs was compiled with some non-existent
> directories in the lisploadpath?


No, I presume that you started cleaning after you had installed the  
first GNU Emacs package (and found some interference of the two  
Emacsen). And during this operation you just removed a few bits too  
much. By removing and reinstalling you'll get these bits back. And a  
sane system!

--
Greetings

   Pete

Upgraded, adj.:
	Didn't work the first time.

Re: removing old installations

[Eric Abrahamsen]

On Sat, Jun 25 2011, Andreas Röhler wrote:

> Am 25.06.2011 19:34, schrieb Eric Abrahamsen:
>> I'm running the Ubuntu repository version of emacs (23.2.1) on Natty. In
>> the past I've tried compiling both emacs 24 and emacs 23 myself on this
>> machine, before deciding it was unnecessary and just using the
>> repository version. As near as I can tell I've cleared the old 24 and 23
>> installations out of my system, but leftover files are still interfering
>> with byte compilation in my present system.
>>
>> Makefiles in external packages like gnus or org-mode set the executable
>> to "emacs" (ie, no full path). There are no other "emacs" executables on
>> my path, but still I need to change the makefiles to specify
>> "/usr/bin/emacs", or else I pick up weird bits from emacs 24, and my
>> compiled files behave strangely (I can provide more details).
>
>
> Hi,
>
> that would be of interest for me, just to understand how Emacs behaves.

What was happening was that a call to a function named
internal-temp-output-buffer-show, which only exists in emacs 24, was
getting dragged in when my org-mode files were compiled. I ran into it
in the org-export function, though grepping my compiled org-mode
codebase showed that it had crept into more than a few of the compiled
files.

It was confusing because org-export complained that the function
couldn't be found; meanwhile no mention of that function appears
anywhere in the org codebase. Manually re-compiling the org-export
function definition from within emacs cleared the problem up.

That function seems to be included in src/window.c in the emacs trunk
source, but I don't know where in your system it ends up after you've
compiled and installed emacs 24. Nor do I know why it was pollution byte
compilation in my regular emacs.

Re: removing old installations

[Eric Abrahamsen]

On Sun, Jun 26 2011, Peter Dyballa wrote:

> Am 26.06.2011 um 00:57 schrieb Eric Abrahamsen:
>
>> I'm quite sure I've removed everything emacs-related from
>> /usr/local/*.
>> One odd thing is, my emacs man file is located at
>> /usr/share/man/man1/emacs.1.gz (symlinked from
>> /etc/alternatives/emacs.1.gz), but within the FILES section of that
>> man
>> page, it gives all the emacs-related paths as /usr/local/*. Not sure
>> what that's about.
>
> I've forgotten these! And there's more than one file:
>
> -rw-r--r-- 1 root wheel  6367  9. Jun 21:38 man1/emacs.1.gz
> -rw-r--r-- 1 root wheel  1632  9. Jun 21:38 man1/emacsclient.1.gz
> -rw-r--r-- 1 root wheel  4444  9. Jun 21:38 man1/etags.1.gz
> -rw-r--r-- 1 root wheel   993  9. Jun 21:38 man1/grep-changelog.1.gz
> -rw-r--r-- 1 root wheel  1191  9. Jun 21:38 man1/rcs-checkin.1.gz
> -rw-r--r-- 1 root wheel    37  9. Jun 21:38 man1/ctags.1.gz
> -rw-r--r-- 1 root wheel  1128  9. Jun 21:38 man1/ebrowse.1.gz
>
> Another area with around 90 files is /usr/local/share/info. And
> there's also /usr/local/share/applications/emacs.desktop!
>
> The sym-links to /etc/alternatives are *not* from your "private"
> installation of GNU Emacs, they're presumably from Debian (package).
> The reason is that you can have more that one packaged GNU Emacs
> version on your PC. Then *some* man page must be present (similarly
> for the INFO files – and this Debian scheme really works quite fine,
> on my Mac).
>
>
>>
>> The bug report data shows that emacs was compiled by Debian.
>
> So you can be sure now that it's not your own "private" Emacs!
>
>> I note that --enable-locallisppath includes, among many other paths,
>> the two paths
>> that emacs complains about when it's run from the command line.
>>
>> Among the voluminous output of strace is:
>>
>> access("/usr/local/share/emacs/23.2/site-lisp", F_OK) = -1 ENOENT
>> (No such file or directory)
>> write(2, "Warning: Lisp directory `/usr/lo"..., 80) = 80
>> access("/usr/local/share/emacs/site-lisp", F_OK) = -1 ENOENT (No
>> such file or directory)
>> write(2, "Warning: Lisp directory `/usr/lo"..., 75) = 75
>
> So presumably they're just *warnings*, not /errors/! You've deleted
> these directory branches when you found that they might contain data
> from your "private" installations, but they were created before when
> you installed some GNU Emacs package.
>
> I'd recommend to check (the dates of) the MAN and INFO files. This
> step could be performed again after this most important step: remove
> all GNU Emacs packages from your PC to clean the situation as far as
> possible. (Then recheck the places I mentioned in my posts.) Finally
> re-install these packages/this package. It will create the paths GNU
> Emacs is complaining about.

Yes, it turned out that all the man files (even those that claimed that
emacs would be installed under /usr/local) were all part of the debian
install, and were in the right places. The two directories it was
complaining about were part of the proper install, and after they were
recreated the warnings stopped. Just goes to show how often the problem
you think you have isn't the one you actually have.

>>
>> Is my only problem that emacs was compiled with some non-existent
>> directories in the lisploadpath?
>
>
> No, I presume that you started cleaning after you had installed the
> first GNU Emacs package (and found some interference of the two
> Emacsen). And during this operation you just removed a few bits too
> much. By removing and reinstalling you'll get these bits back. And a
> sane system!

Yup, that was exactly right.

Thank you!