Rawhide firefox
by Brian C. Huffman
I just upgraded via yum from FC4 to latest Fedora rawhide. Everything
except firefox seems to be working well. Here's what I get when I run
firefox under strace:
[snip]
open("/usr/lib/libexpat.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\201"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=128252, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f37000
mmap2(0xb96000, 129624, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
3, 0) = 0xb96000
mmap2(0xbb4000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x1d) = 0xbb4000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f36000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f35000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f356b0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0x690000, 8192, PROT_READ) = 0
mprotect(0xc85000, 4096, PROT_READ) = 0
mprotect(0xd45000, 4096, PROT_READ) = 0
mprotect(0x1f4000, 4096, PROT_READ) = 0
mprotect(0x111000, 835584, PROT_READ|PROT_WRITE) = 0
mprotect(0x111000, 835584, PROT_READ|PROT_EXEC) = 0
mprotect(0x6be000, 12288, PROT_READ|PROT_WRITE) = 0
mprotect(0x6be000, 12288, PROT_READ|PROT_EXEC) = -1 EACCES (Permission
denied)
writev(2, [{"/usr/lib/firefox-1.5/firefox-bin", 32}, {": ", 2}, {"error
while loading shared libra"..., 36}, {": ", 2},
{"/usr/lib/firefox-1.5/libxpcom.so", 32}, {": ", 2}, {"cannot restore
segment prot afte"..., 39}, {": ", 2}, {"Permission denied", 17}, {"\n",
1}], 10/usr/lib/firefox-1.5/firefox-bin: error while loading shared
libraries: /usr/lib/firefox-1.5/libxpcom.so: cannot restore segment prot
after reloc: Permission denied
) = 165
exit_group(127) = ?
Process 4857 detached
Any thoughts?
Thanks,
Brian
18 years, 3 months
does your video resume after a suspend to ram with kernel-2.6.15-1.1823_FC4
by Paul Johnson
Is suspend & resume working on your laptop?
I was told that one of the goals in FC5 is to make laptop
suspend/restore work. I've been testing with various kernels and have
been having the same problem since 2.6.13. The system will suspend,
but when I resume, the video stays dark. This is happening now with
the testing kernel-2.6.15-1.1823_FC4
http://people.redhat.com/davej/kernels/Fedora/FC4/RPMS.kernel/
I want to know if other laptop users have a similar problem? I've
asked in the gnome-power-management list and they say there's nothing
they can do about the problem if it is in the kernel, and that's where
I think it is. Here's why: the laptop stays dark even if I suspend
from runlevel 3 (never starting X or gdm at all). I think that means
the problem does not lie with the Nvidia X driver.
This system I'm testing is mostly FC4, but it has udev and hal updated
from the g-p-m site and it has the kernel from Dave J's site.
Oh, one more question. I got desperate enough to try the Suspend2
kernel patch and the hibernate program. That did work in "suspend to
disk" mode. However, I did not see any value in that because the
system took just about as long to restart from a suspend to disk as it
took to just reboot from scratch. However, when I set it to suspend
to ram, I got the same dark video.
--
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas
18 years, 3 months
suspend on fc5
by William John Murray
Hello all,
I would like to try out suspend (ramd and disk) on FC5T1.
It looks like gnome-power-manager is the way to go?
I installed gnome-power-manager.i386, libnotify.i386,
notify-daemon.i386 and hal-gnome.i386 but something is still
wrong.
gnome-power-manager --no-daemon
responds:
** (gnome-power-manager:3662): CRITICAL **: HAL does not have
PowerManagement capability
Can anyone suggest what might be responsible? I am woefully
hal ignorant.
Thanks,
Bill
Ps Typing gnome-power-manager by itself just does nothing.
18 years, 3 months
OOo and x86_64
by Paul F. Johnson
Hi,
Is it me or is there not a build of OOo native for x86_64 yet and if
this is the case, any signs of one happening?
TTFN
Paul
--
main(t,_,a) char*a;{return!0<t?t<3?main(-79,-13,a+main(-87,1-_,main(-86,
0,a+1 )+a)):1,t<_?main(t+1,_,a ):3,main (-94,-27+t,a)&&t==2?_<13?main(2,
_+1,"%s %d %d\n"):9:16:t<0?t<-72?main(_,t,"@n'+,#'/*{}w+/w#cdnr/+,{}r/*de}
+,/*{*+,/w{%+,/w#q#n+,/#{l,+,/n{n+,/+#n+,/#;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K
w'K:'+}e#';dq#'l q#'+d'K#!/+k#;q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]
'/+#n';d}rw' i;# ){nl]!/n{n#'; r{#w'r nc{nl]'/#{l,+'K {rw' iK{;[{nl]'/w#q#n
'wk nw' iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c ;;{nl'-{}
rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;#'rdq#w! nr'/ ') }+}{rl#'{n' ')# }'+}##
(!!/"):t<-50?_==*a?putchar(31[a]):main(-65,_,a+1):main((*a=='/')+t,_,a+1
):0<t?main(2,2,"%s"):*a=='/'||main(0,main(-61,*a,"!ek;dc i@bK'(q)-[w]*%n+r3#l
,{}:\nuwloca-O;m .vpbks,fxntdCeghiry"),a+1);}
18 years, 3 months
xorg-x11-drivers [inappropriately] requires all drivers modules
by David Timms
I attempted to remove some of the xorg-x11-drv-mga /s3 etc since I have
only an ATI card, but found that the particular drivers "is needed by
(installed) xorg-x11-drivers".
Can the .spec be modified so that -drivers requires one-or-more -drv?
Also, the -drv-* would then need be a provider of -drv. This means an
update would only need to dl/install one of the 50 or so drivers.
I guess by default it would make sense to install a few base drv that
can be used as a fallback when no specific driver exists. The installer
would need to "know" which drv to install above the fallbacks, perhaps
such code needs to be invented first ?
Or doesn't the modular X + rpm requires/provides work this way ?
18 years, 3 months
RE: does your video resume after a suspend to ram withkernel-2.6.15-1.1823_FC4
by Brown, Len
>[mailto:fedora-test-list-bounces@redhat.com] On Behalf Of Paul Johnson
>Is suspend & resume working on your laptop?
>
>I was told that one of the goals in FC5 is to make laptop
>suspend/restore work. I've been testing with various kernels and have
>been having the same problem since 2.6.13. The system will suspend,
>but when I resume, the video stays dark. This is happening now with
>the testing kernel-2.6.15-1.1823_FC4
>
>http://people.redhat.com/davej/kernels/Fedora/FC4/RPMS.kernel/
>
>I want to know if other laptop users have a similar problem? I've
>asked in the gnome-power-management list and they say there's nothing
>they can do about the problem if it is in the kernel, and that's where
>I think it is. Here's why: the laptop stays dark even if I suspend
>from runlevel 3 (never starting X or gdm at all). I think that means
>the problem does not lie with the Nvidia X driver.
>
>This system I'm testing is mostly FC4, but it has udev and hal updated
>from the g-p-m site and it has the kernel from Dave J's site.
Paul,
If a laptop supports Linux, then it is a BIOS bug if the BIOS
does not re-post video on resume from S3.
Of course that is a big "if" -- as it is unlikely the
laptop suppler sold you a unit with Linux installed...
The next line of defense is indeed the window system.
The X graphics driver can often restore video on resume from S3
because Linux switches from text to video console on resume
and that provokes the driver to restore graphics.
So sometimes updating the X driver helps here.
There are some kernel hacks and vbetool that may help,
but they're workarounds -- try at your own risk.
workaround are listed here in Documentation/power/video.txt
a copy can be found in the kernel source tree:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=bl...
cheers,
-Len
18 years, 3 months
hal-0.5.5.1.cvs20060105-2, hal-gnome-0.5.5.1.cvs20060105-2
by Don Springall
I believe the latest hal broke gnome-power-manager-0.3.1-2.1 again. See
below.
[root@localhost don]# gnome-power-manager
(gnome-power-manager:2253): GnomeUI-WARNING **: While connecting to session
manager:
Authentication Rejected, reason : None of the authentication protocols
specified are supported and host-based authentication failed.
** (gnome-power-manager:2253): WARNING **: Failed to open connection to dbus
session bus: No reply within specified time
This program cannot start until you start the dbussession daemon
This is usually started in X or gnome startup (depending on distro)
You can launch the session dbus-daemon manually withthis command:
eval `dbus-launch --auto-syntax`
If this works, add "dbus-lauch --auto-syntax" to ~/.xinitrc
18 years, 3 months
Jan 4th and leftover #prelink# files
by Jim Cornette
I have several files from prelink that ended up on the system on the
4th. Most of the files were located in /usr/lib with the latest
installed libraries. One was from /usr/bin
What might be causing this? updating the system during prelink runs or
as first questioned regarding shutting down the computer.
I cleaned up the matter. I would however like to find out where the
source for these files remaining along with the same library version
with the appended prelink ending.
I removed the previous versions from the prior problem and verified that
there were no remaining #prelink# files on my system.
Jim
locate '#prelink#'
/usr/bin/kwikdisk#prelink#.1rA5Jm
/usr/lib/libGL.so.1.2.#prelink#.Wvw8hK
/usr/lib/libGLU.so.1.3.060401.#prelink#.69UZeK
/usr/lib/libImlib2.so.1.2.1.#prelink#.ChDxbJ
/usr/lib/libSDL-1.2.so.0.7.2.#prelink#.vXlGek
/usr/lib/libdv.so.4.0.1.#prelink#.LgfyBf
/usr/lib/libgsm.so.1.0.10.#prelink#.HOfOSH
/usr/lib/libxvidcore.so.4.0.#prelink#.e0MbnY
ls -la *#prelink#*
-rwx------ 1 root root 460492 Jan 4 21:45
libGLU.so.1.3.060401.#prelink#.69UZeK
-rwx------ 1 root root 52620 Jan 4 21:47 libgsm.so.1.0.10.#prelink#.HOfOSH
-rwx------ 1 root root 355864 Jan 4 21:14
libImlib2.so.1.2.1.#prelink#.ChDxbJ
-rwx------ 1 root root 454016 Jan 4 21:30
libSDL-1.2.so.0.7.2.#prelink#.vXlGek
-rwx------ 1 root root 614708 Jan 4 21:46
libxvidcore.so.4.0.#prelink#.e0MbnY
--
Computers don't actually think.
You just think they think.
(We think.)
18 years, 3 months