I'd bring this issue up here. right now all elisp packages
has been bytecompilied at the build time. that worked fine
until now. However xemacs has been moved to Extras and we
have had the possiblity of having the multiple version of
[x]emacs against the existance of Extras. consequently it
takes the problem rise. say, the elisp packages in Core
can't provides the bytecompiled elisp for xemacs, because
Core packages can't depends on Extras packages. people
needs to have their own (duplicated) elisp packages to be
bytecompiled or needs any extra work for that. etc. and you
may wants to try the emacs CVS snapshot package. but it may
not work properly due to the incompatibility of the
For such problems, Debian has the good thing to solve
them. emacsen-common package provides the facilities to
install the elisp files. although each elisp packages needs
to have a script to bytecompile them, it will be brought
up with every favor of [x]emacs from emacsen-common and the
elisp packages can provides the bytecompiled elisp without
installing each elisp packages like -el and -el-xemacs for
[x]emacs installed on your system.
The description may be insufficient. please comment on this,
if you have any objections. the discussion is always welcome :)
What yum or rpm invocation do I need to use to discover what GUI debuggers
are available in Fedora? I'm working on an OpenGL-based game so a
curses-based debugger would probably be best, but I can run the app
windowed so an X-based debugger would also be useful. Mostly I'm looking
for something that can show me source lines, the current call stack, the
local variables, and watched variables. I tried yum install for insight and
ddd but it didn't find those.
I originally sent this to the Fedora users list earlier this morning but
didn't get a single response as of this evening. Upon reflection, it
seemed like a good idea to send this to the developers list.
If anybody can point me to a comprehensive explanation of all the
various exec-shield technologies and the ways they interact with
different kernel versions, gcc versions, etc., I would be happy to RTFM.
As of now, Googling had just returned various bits and pieces, many of
which already seem out of date as exec-shield has evolved and gotten
into upstream kernel work.
-------- Forwarded Message --------
From: Dave Roberts <ldave(a)droberts.com>
Reply-To: For users of Fedora Core releases <fedora-list(a)redhat.com>
To: For users of Fedora Core releases <fedora-list(a)redhat.com>
Subject: randomize_va_space default change?
Date: Thu, 28 Jul 2005 11:08:11 -0700
Did something just change with one of the latest kernel releases for FC3
to enable randomize_va_space by default? I had a program (sbcl - Steel
Bank Common Lisp) that was working fine with previous kernels and now
seems to be having trouble with address space randomization.
Either that, or was there a setting change in gcc that now defaults to
allowing randomization in some ELF header bit somewhere? Perhaps in gcc
3.4.3 or thereabouts? I have noticed that binaries built after sometime
in May suffer from the problem but older binaries don't. Further, newer
binaries didn't start suffering until running them with recent kernels
I'm having a lot of trouble finding information about how
randomize_va_space works. Setting it to 0 in /proc/... works fine, but
I'd rather have some way to build sbcl such that I can mark it as
incompatible with address space randomization rather than turning off
this feature for the whole system. I know that other exec-shield
features have ELF bits that can be flipped with build options, but they
seem to default to being off for compatibility's sake.
Dave Roberts <ldave(a)droberts.com>
Dave Roberts <ldave(a)droberts.com>
somehow Firefox in SuSE 9.3 supports 32bit plugins on x86_64.
The firefox-bin executable is really a 64bit binary, and
I couldn't guess how they did it by examining the files
in the binary package.
Could we do something similar in Fedora? If needed, I'm
volunteering to dissect SuSE's SRPM to extract the patch.
// Bernardo Innocenti - Develer S.r.l., R&D dept.
contains mlocate, a new locate implementation. The 'm' stands for "merging":
updatedb reuses the existing database to avoid rereading most of the file
system, which makes updatedb faster and does not trash the system caches as
much (some data are at end of this message).
The locate(1) utility is intended to be completely compatible to slocate.
It also attempts to be compatible to GNU locate, when it does not conflict
with slocate compatibility.
mlocate seems to work well so far, but it has been tested only on ext3.
Because mlocate is sensitive to filesystem timestamp semantics,
testing with rarely used filesystems or uncommon automounting setups
would be most valuable. Any other testing and comments are of course
welcome as well.
The package is prepared to install alongside slocate (it actually requires
slocate because I didn't want to allocate a GID for mlocate yet):
configure it at /etc/mupdatedb.conf and then just use (mlocate) instead
This is the first public release, so be please be careful: mlocate
certainly has a few bugs and it has not been independently audited
for security issues.
Now, the promised numbers: each time, a computer was booted into
single-user mode; after one updatedb run data was collected using
(slabtop) and (free). The measurement method is admittedly crude,
but I think the numbers represent reality quite well.
Run: real user system dentry inode buffers cached
slocate: 1m32.84 0.704 2.045 134337 170778 85972 8268
mlocate, 1st: 1m11.65 0.214 0.908 17766 15642 78452 21340
mlocate, 2nd: 37.64 0.105 0.289 17776 15639 33996 21336
real, user, system: as reported by (time)
dentry, inode: number of active objects in dentry_cache and ext3_inode_cache,
as reported by (slabtop)
buffers, cached: size of disk buffers and page cache, as reported by (free).
mlocate has two rows because the first run needs to rescan the whole
file system, while the subsequent runs can reuse most of the original
On Wed, 2005-07-27 at 23:16 +0200, DANEYE wrote:
> On my computer I have 2 HDs àn 160Gb each.
> On the primary (no partitions) I have WXPPro installed and on
> the slave (no partitions) I have recently installed Fedora Core 4.
> My problem is that the GRUB doesn’t ‘act’ so there is no
> booting choice: I always end up with the XP.
> There are no –what I can see- tips and tricks to find about my problem
> in the Hudson/Hudson/Ball/Duff Red Hat Fedora 4 UNLEASHED.
> Anybody who has hints in the matter?
Not the hint you were after I'm sure, but this list is for discussion of
rawhide development issues.
Since your really after help with a stable release of fedora, you're
better off asking your questions of fedora-users list, which is designed
to address your needs.
> fedora-devel-list mailing list
"It's a fine line between denial and faith.
It's much better on my side"
With a fully updated FC4 + full rawhide updates, are the fonts still as
messed up as they have been recently, especially in evolution and
firefox (even with the alpha one?)?
Not running it, just trying to keep track before going back to a rawhide
system like I do between releases (yes I help test, open bugs, etc.. and
aware of rawhide).
"Everything is always harder, before it's easier!
On my computer I have 2 HDs àn 160Gb each.
On the primary (no partitions) I have WXPPro installed and on
the slave (no partitions) I have recently installed Fedora Core 4.
My problem is that the GRUB doesnt act so there is no
booting choice: I always end up with the XP.
There are no what I can see- tips and tricks to find about my problem
in the Hudson/Hudson/Ball/Duff Red Hat Fedora 4 UNLEASHED.
Anybody who has hints in the matter?