Re: rawhide report: 20051011 changes
by Steve Dickson
Bernardo Innocenti wrote:
> Build System wrote:
>
>> system-config-nfs-1.3.12-1
>> --------------------------
>> * Tue Oct 11 2005 Nils Philippsen <nphilipp(a)redhat.com> 1.3.12
>> - allow user to set networking ports to be used (#151166)
>> - separate code concerning the NFS server, its settings and NFS exports
>> - some code cleanup
>
>
> Some files are missing in this package:
>
> # system-config-nfs
> Traceback (most recent call last):
> File "/usr/share/system-config-nfs/system-config-nfs.py", line 40, in ?
> import mainWindow
> File "/usr/share/system-config-nfs/mainWindow.py", line 22, in ?
> import nfsServer
> ImportError: No module named nfsServer
>
>
> BTW, is NFSv4 officially supported in Fedora now? With gss-api
> authentication too?
>
Yes... and Yes...
steved.
18 years, 5 months
Modular X ramblings
by Brian Gerst
- XFS didn't automatically restart, I had to manually start it.
- had to hand edit some paths in xorg.conf. Still getting error on rgb
file:
Couldn't open RGB_DB '/usr/lib/X11/rgb'
- scroll wheel on mouse wasn't working. I had to comment out this from
xorg.conf:
# Option "ZAxisMapping" "6 7"
# Option "Buttons" "7"
wheel works now but thumb button does not.
- Nvidia driver works fine after putting files in the new locations
- glxinfo and glxgears are MIA.
- libXxf86dga.i386 doesn't exist in the x86_64 tree, had to grab it from
i386.
- cedega / World of Warcraft is working. Life is good again. =)
--
Brian Gerst
18 years, 5 months
glxgears / glxinfo
by Brian Gerst
Which package are glxgears/glxinfo hiding in now? They used to be in
xorg-x11-tools.
--
Brian Gerst
18 years, 5 months
Xaw3d needs rebuild due to modular X
by Peter Lemenkov
Hello, All!
=====================
[root@Petro lib]# rpm -ql Xaw3d
/usr/X11R6/lib/libXaw3d.so.7
/usr/X11R6/lib/libXaw3d.so.7.0
=====================
--
With best regards, Peter Lemenkov.
18 years, 5 months
Modular X
by Bart Vanbrabant
Hello,
I just installed the new modular X from rawhide. Everything went quite
good except for two problems:
1) The nvidia driver doesn't handle modular X yet. But I solved it by
manually moving all libraries to their new places. This isn't something
that should be handled by fedora.
2) There were two paths in my xorg.conf that pointed to the old /usr/X11
places. Those where ModulePath and RgbPath. I changed them like this:
RgbPath "/usr/share/X11/rgb"
ModulePath "/usr/lib/xorg/modules"
It this something that other users could have problems with to? Because
then a postinstall script should check for this. Do I need to file a
bugreport?
cheers,
Bart
--
Bart Vanbrabant <bart.vanbrabant(a)zoeloelip.be>
PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1
18 years, 5 months
nv (open source) driver v. two heads on one card
by Bojan Smojver
Just out of curiosity, I went through the:
http://wiki.x.org/wiki/ChangesSince68
and it mentions:
- Updates to nv(4) driver from XFree86 and nVIDIA
I went through the source of the driver briefly (not that I would
understand any of it :-) and there is a mention of twoHeads in heaps of
places, so I'm hoping...
Does anyone know if this open source driver now supports two heads on
one card (e.g. Quadro 280 PCI and similar) like its close source
counterpart does?
--
Bojan
18 years, 5 months
Modular X: libXext headers missing
by Ralf Corsepius
Hi,
What has happened to libXext's headers in "modular X"?
libXext-devel-0.99.2-1.i386.rpm doesn't contain any headers, nor can't I
find them elsewhere.
Ralf
18 years, 5 months
Modular X 101 : Debugging modular X
by Mike A. Harris
Did you know, that all of the modular X packages now come with
full debuginfo packages, including the X server and driver modules?
The X server uses dlopen now also, so it can be debugged using
the stock gdb that comes with Fedora.
In order to debug the running X server, install the debuginfo
packages for it, and any drivers you are loading. You then
need to have 2 computers[1] networked together, or using a serial
port or some other remote access method.
Edit the xorg.conf file, and enable the option:
Option "NoTrapSignals"
Then, enable coredumps on the system, if you have not done so
already, by using "ulimit -c unlimited" in a script dropped into
/etc/profile.d/enable-coredumps.sh or whatever. Be sure to run
the script or log out and back in.
As the X server is a setuid root process, and the kernel will not
allow coredumps of SUID processes by default, you have 2 choices.
You can tweak the kernel to permit SUID coredumps by doing:
echo 1 > /proc/sys/kernel/core_setuid_ok
or you can run the X server as root. If you enable the kernel to
allow SUID coredumps as per above, just be sure to disable it
afterwards by echoing '0' to the same file, to avoid potential
security issues.
Now you are ready to break things and debug them. I prefer to
start the X server with "startx" all the time, but particularly
when debugging. I recommend doing the same, unless the problem
you are debugging only occurs when using gdm/kdm/xdm, as it tends
to be much simpler to debug with startx. YMMV however.
If the server crashes, you can gdb the coredump now. Assuming
you installed debuginfo packages for the server (make sure the
debuginfo package is the same version-release as the server that
is installed), you should get useful backtraces, etc.
If you want to debug the running server, single step it, etc.,
you need the second computer[1] mentioned above. Do all the same
steps as above, but this time, ssh in from the remote computer
(or use minicom on serial port or whatever), and get the PID
of the X server with 'pidof X'. Then attach gdb to the X server:
gdb --pid=$(pidof X)
Now go to town! Find the bug, install the X server/driver sources,
fix the bug, generate a patch with gendiff, and attach it to a bug
report. It's really that simple!!! ;oP
This informative message has been brought to you by the Red Hat
X Development team, and Frank's Red Hot Chile & Lime Hot Sauce.
Have fun!
[1] The reason that 2 computers are required, is that if you start
the X server, open an xterm and run gdb on the running X server,
gdb will stop the X server, and try to print to stdout. Since
stdout is your xterm, and xterm is displaying to the X server which
is now no longer responding because gdb stopped it, you are screwed.
It's kindof like trying to stand on a carpet, and then pull it out
from under yourself. You can't really do it. This is why you
need[2] 2 computers.
[2] Ok, it is technically possible to do it with one computer too,
but it is complex enough to not really bother trying to do, so
don't even waste time thinking of it. If you don't have 2
computers, go dumpster diving at 3am in the garbage dumpster of
a computer store. They throw out good stuff I'm told, and you
can have a "X server debugging terminal" in no time, like everyone
else on the block. Alternatively, surf ebay.com for a bargain, or
hang out at a computer recycling shop.
Note: Please feel free to forward this message on to other people
or mailing lists, or to copy or paraphrase into wiki pages or other
helpful resources if you think other formats or people would
benefit from this info.
18 years, 5 months
Re: questions and issues about the modular X updates
by Jason Dravet
>>Jason Dravet wrote:
>>
>> I just updated my rawhide system to the new modular x. I have been
>>reading some of the >>threads discussing this and I have a couple of
>>questions:
>>
>> 1. With modular X (when released) have support for
>>automaticahttp://by103fd.bay103.hotmail.msn.com/cgi-bin/compose?curmbox=0...
Sendlly turning on numlock when I >>start X?
>
>You can do that with any version of X, by calling xset from
>~/.Xclients or ~/.xinitrc, or one of the systemwide locations.
>
I saw the saw the setup for xset. I was hoping for a cleaner solution. For
example IMO having a line in the xorg.conf file to control the caps lock,
scroll lock, and num lock would be the best solution. It keeps all of the
configuration data together. When I move to new version of Fedora I format
my hard drive and copy the data back from a usb thumb drive. Right now I
have to copy back approximately 20 configuration files and alot of odds and
ends to get the system back to where it was before I updated. If there was
a line in xorg to control the lock keys then to get X back up and running I
would only have to put the xorg.conf back. Right now I have put xorg.conf
back, copy my mouse.sh file back, and copy the numlock.sh file back. Am I
crazy for thinking 1 file is better than 3?
>
>> 2. When I did the yum update all of the xorg-x11-drv rpms downloaded.
>>This is 56 files several >>of which I don't need. I have a Number nine
>>Revolution IV video supported by the i128 package. >>I don't need the
>>cirrus, trident, s3, nv, etc packages, but I can't uninstall them. I get
>>
>>
>Yes, this is intentional. The reasons for splitting the drivers out
>into individual packages, was to:
>
>- make it very easy for us to release single driver updates
>
>- to drastically reduce the amount of downloading necessary to update
> a single driver
>
>- drastically reduce the disk space consumption and network bandwidth
> consumption for mirror sites as well as internal build machines
>
>- to make it easy to add new video drivers to a release without
> having to release a whole new 150Mb of X packages.
>
I agree this is a good thing. Being able to release new drivers as soon as
they come out without having to respwan all of X is great. My concern is
for bandwidth. Looking at the xorg-x11-drv files there are about 2.3MB of
drivers. This number is only going to go up as time goes on and drivers are
added and updated. The idea about installing new hardware and having yum or
some other application go and download the driver is good. I agree that
such functionality will not be here for FC5. If this is where things are
going then I will shut up and download everything.
>> 3. My Microsoft Intellimouse explorer (usb) no longer functions as
>>expected. I still have
>>
>> Option "Protocol" "ExplorerPS/2"
>> Option "Device" "/dev/input/mice"
>> Option "Buttons" "7"
>> Option "ZAxisMapping" "6 7"
>>in my xorg.conf. I also have the mouse.sh file in
>>/etc/X11/xinit/xinitrc.d
>>#!/bin/sh
>># /etc/X11/xinit/xinitrc.d/mouse.sh
>># Required for the configuration of a 5-button mouse
>>xmodmap -e "pointer = 1 2 3 6 7 4 5"
>>
>> In short the back and forward buttons work as a scroll. How can I fix
>>this?
>
>I believe they've been playing with this part of the code in Xorg CVS
>lately, and that it might have gotten broken. I think I saw some CVS
>commits go in in the last few days related to button ordering, but I
>don't remember the details. My recommendation, is to post a message to
>xorg lists freedesktop org about it for now, and see what feedback you
>get back. If it turns out it is a bug, and is not fixed in CVS, query
>xorg bugzilla to see if someone has already reported it or not, and if
>not, file a bug, and attach your X server config and log, and your
>script to the report, and mark it blocking the release blocker
>bug #1690
You are correct there is a thread called ZAxisMapping causing trouble at
http://lists.freedesktop.org/archives/xorg/2005-November/date.html. I will
keep checking the list for updates.
Thank you for the reply the information was very helpful.
Jason
18 years, 5 months