On Wed, 2003-10-29 at 11:11, Ryan wrote:
> I'm not sure my initial email made it to the list (I just set up a new
> "list only" email account).
> I've read on the gnome-devel list that Redhat removed the ability to
> edit applications:///
> I'm wondering if this is true and if so what the reasoning behind this
> is? And also how I can fix things so that I can edit menus.
> thanks all,
For those others out there (few though they may be) who would like to be
able to edit applications:/// try these instructions at your own risk
(they're pulled verbatim from
http://people.ecsc.co.uk/~matt/repository.html and they worked fine for
Menu-editing in RedHat 9
* To enable menu editing per user config (via nautilus), you need
to open a terminal and do the following:
<give root password>
cp default-modules.conf default-modules.conf-no-menu-editing
cp default-modules.conf.with-menu-editing default-modules.conf
For any user you want to have the right to edit their menu, you
also need to do this as the user:
* When gnome-panel is restarted (via logout/login or kill) the
user will be able to see the changes they have made to their
i'm using the arjan (hope that's spelled right) testkernels with rh9/xd2
on my sony pcg-z600lek notebook, but all kernels newer than
2.6.0-0.test5.1.36 seems to have problems connecting to the
internet. my notebook is connected to a sitecom-router, and in this way
(plus another switch connected to the sitecom-router) also to 6 or 7
windows-pcs. interestingly, i can connect to them via smb/nautilus and
can copy files from them to my pc with the new(est) testkernel running,
but when i want to fetch my mails via evolution or to browse with
galeon, the resp. program tries to connect, but there seems to be simply
no data coming. after a while, in galeon, i get the
note that when booting, i get the green "ok-message" for eth0 and again,
i can copy files from other computers in my network flawlessly...
my notebook's built-in network-adapter is a widely used intel
(pro?)-chipset (sorry for not knowing the exact type, if needed, i'll
try to find out the exact type).
so my question-is this a known thing, and is it fixable from my side-or
a bug in the (newer) kernels?
thanks for any help!
i realize that the graphical boot has been discussed on numerous
occasions, but frankly, i've never seen one on my system (currently
running FC3). how do i get one? (at the moment, i see the standard
line-oriented boot i've seen for years).
i've verified that /etc/sysconfig/init contains
i've perused /etc/rc.sysinit and the conditions look like they'd be
satisfied. /usr/bin/rhgb is there. the file /proc/cmdline does not
contain the string "nogui". so what am i missing?
i figured it would be nice to see this graphical boot thingie at
Setup: test3 updated to 10/28
I remember seeing some mention of emacs problems awhile ago here.
Trying to compile emacs from cvs sources fails with these error
[root@exp emacs]# ./configure
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for gcc... gcc
checking for C compiler default output... configure: error: C compiler
cannot create executables
See `config.log' for more details.
Does this ring a bell with anyone?
all right, i have some intriguing observations to report. but first, i
want to settle this "rhgb" boot-line option. can someone point me to
where this option has any effect *at* *all*?
i have gone over these two files:
and it *appears* that whether or not you get a graphical boot is tested in
/etc/rc.sysinit, and is based *solely* on the following:
access to /usr/bin/rhgb
there is, AFAICT, no test *anywhere* that looks for the option "rhgb" on
the boot line. OTOH, the file /etc/rc.sysinit *does* check for the
boot-line option "nogui" to *prevent* the graphical boot. so ... who wants
to explain how the option "rhgb" means anything, and where it's tested. in
short, i see "nogui" to prevent a graphical boot if it's turned on. i see
no "rhgb" test to activate a graphical boot if it's turned off.
second, if you check /etc/rc.sysinit, whether you get a graphical boot
early depends on whether /usr is a separate filesystem. if it is, you
can't get a graphical boot since /usr/bin/rhgb isn't even available yet.
so that first conditional is skipped early in the file.
however, the whole test is done again around line 560 where, by now,
/usr is mounted and it should work. at least, that's the theory.
in my case, though, what i get when the line "/usr/bin/rhgb" is run
umount2: Invalid argument.
umount: /initrd: not mounted.
printed twice. what the ...? i'd seen these crop up recently and
was planning on tracking them down at some point, but it never occurred
to me to associate them with the second invocation of rhgb.
can anyone explain what these mean? that might go a long way to
clearing this up. well, at least for me.
I have trouble with xmms. Sometimes I can't change the volume in xmms,
only gmix works. Only happens in gnome, kde works fine.
When I open gmix it sometimes changes the volume: xmms is already
running and I've increased volume, it's decreased by gmix loading it's
Anybody else seeing this? I think, the volume levels should be restored
at login, not on gmix startup. Never had this problem before, only on
Christoph Wickert <christoph.wickert(a)web.de>
I raised a problem with kernel compiles in an addendum to bugzilla bug 105979.
It was pointed out that the problem (shown below) is caused by a workaround
to kernel 2.4 build system limitations. Does anyone know a simple way to get
the 2.4.22-1.2115.nptl kernel to build in Fedora 095 on the i386 platform?
This is a bare-metal install of 095.
The problem I'm having is shown here:
# cd /usr/src/linux-2.4.22-1.2115.nptl
# make clean
# make mrproper
# make menuconfig
# make dep
ar rcs lib.a checksum.o old-checksum.o delay.o usercopy.o getuser.o memcpy.o
make: Leaving directory `/usr/src/linux-2.4.22-1.2115.nptl/arch/i386/lib'
make: Leaving directory `/usr/src/linux-2.4.22-1.2115.nptl/arch/i386/lib'
make: Entering directory `/usr/src/linux-2.4.22-1.2115.nptl'
kallsyms pass 1
ld -m elf_i386 -T /usr/src/linux-2.4.22-1.2115.nptl/arch/i386/vmlinux.lds -e
stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o
init/version.o init/do_mounts.o --start-group arch/i386/kernel/kernel.o
arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o
drivers/acpi/acpi.o drivers/cpufreq/cpufreq.o drivers/char/char.o
drivers/block/block.o drivers/misc/misc.o drivers/net/net.o
drivers/char/drm/drm.o drivers/net/fc/fc.o drivers/net/appletalk/appletalk.o
drivers/net/tokenring/tr.o drivers/net/wan/wan.o drivers/atm/atm.o
drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/pci/driver.o
drivers/pnp/pnp.o drivers/video/video.o drivers/media/media.o
drivers/md/mddev.o drivers/isdn/vmlinux-obj.o crypto/crypto.o net/network.o
/usr/src/linux-2.4.22-1.2115.nptl/arch/i386/lib/lib.a --end-group -o
kernel/kernel.o(.text+0xfc3): In function `schedule':
: undefined reference to `active_load_balance'
make: *** [kallsyms] Error 1
make: Leaving directory `/usr/src/linux-2.4.22-1.2115.nptl'
make: *** [vmlinux] Error 2
10:44:26  bubo10:src/linux-2.4.22-1.2115.nptl#
We had to respin FC1 today for a non-technical issue (that's all
I can say, sorry), which resets the clock for release. We have
to start over again with the export process, and I don't think
they work weekends, so we have to slip until after we hear back
from them and then sync to mirrors. Wednesday the 5th is slightly
possible, a day later more likely.
We did at least pull in a few technical fixes as well whil we were
Sorry about that,
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
Brent Fox wrote:
> On Wed, 2003-10-29 at 10:11, Will Backman wrote:
>> Some of the redhat-config-* tools have a tui version. Any rumors of
>> a tui version of the user manager?
> It's the first request I've had for a TUI for
> redhat-config-users, so I
> have no plans for this at the moment. I had always imagined that the
> command line tools were good enough for those who didn't use the GUI.
> Maybe you can explain what you'd like to see from a TUI that
> the command line tools don't provide?
I know that it's probably a pretty dramatic bit of recoding in most
cases, but I'd like to see TUI versions for _all_ the redhat-config* stuff
(shudder - sudden flashback to linuxconf). The issue is that I get used to
the GUI stuff (read: crutch - I'll admit it) and, well, forget bits and
pieces of the command line stuff at times. That, coupled with the fact that
the GUI tools are doing multiple tasks in many cases (like the network and
user tools) make it attractive to me. In a way it's your fault - you guys
have made the GUI tools too nice :)
But worth the effort? Well, that's up to you guys @ RH or one of
the masses now on Fedora to decide.....