Wine/Cedega and fedora 3
by Kjetil Nygård
I tried to install cedega from Transgaming yesterday. But I could not
start it until I followed the instructions in their manual and did the
following changes to my Fedora install
1. Removed prelinking
(Think it should have been enough to remove "exec-shield")
2. echo 1>/proc/sys/vm/legacy_va_layout
Is it possible to change these in fedora so that users doesn't have to
do this themselves?
--
Kjetil Nygård
Tlf: +47 41 47 43 37
19 years, 5 months
Re: Slow X on x86_64
by Hugh Caley
Relevant log entries below.
I note that I have no /dev/dri directory. Created one, but it's gone on
reboot. My 32-bit machine has these entries in dmesg, but the 64-bit
machine does not:
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode
Hugh
x86_64
dmesg:
agpgart: Detected AMD 8151 AGP Bridge rev B3
agpgart: Maximum main memory to use for agp memory: 7956M
agpgart: AGP aperture is 128M @ 0xf0000000
PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
Linux agpgart interface v0.100 (c) Dave Jones
vesafb: probe of vesafb0 failed with error -6
Xorg.0.log:
(II) Loading sub module "drm"
(II) LoadModule: "drm"
(II) Loading /usr/X11R6/lib64/modules/linux/libdrm.a
(II) Module drm: vendor="X.Org Foundation"
(II) MGA(0): [drm] bpp: 32 depth: 24
(II) MGA(0): [drm] Sarea 2200+664: 2864
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: Open failed
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: Open failed
[drm] failed to load kernel module "mga"
(II) MGA(0): [drm] drmOpen failed
(EE) MGA(0): [drm] DRIScreenInit failed. Disabling DRI.
> Re: Slow X on x86_64
>
> ______________________________________________________________________
> * From: Alan Cox <alan redhat com>
> * To: Development discussions related to Fedora Core <fedora-
> devel-list redhat com>
> * Subject: Re: Slow X on x86_64
> * Date: Wed, 8 Dec 2004 18:21:54 -0500
>
> ______________________________________________________________________
> On Wed, Dec 08, 2004 at 02:45:54PM -0800, Hugh Caley wrote:
> > I'm having a problem with an install of FC3 on an Opteron machine. The
> > X performance is deadly slow; glxgears gives me less than 53 FPS. On a
> > similarly x86 32-bit machine I'm getting well over 500 FPS. It's the
> > same with both a Matrox G550 and an ATI Radeon 9200 card.
>
> Maxtrox at least was 32bit only for DRI until very recently. Radeon should
> be working. Mine does anyway 8)
>
> > Anyone else seeing this?
>
> Logs ?
>
19 years, 5 months
Re: Smart package manager (Was: Same named packages, different dependencies)
by Axel Thimm
On Thu, Dec 09, 2004 at 12:50:03PM +0100, Dag Wieers wrote:
> With smart you can decide what repositories you trust to be
> upgrading your system by default, which ones cannot override core
> packages and even which repositories are prefered on a per package
> basis.
In theory you could do that with apt, too, but there were bugs or at
least the documenation was not in sync with the code (meaning the code
did behave differently than the docs specified).
In general having such a system is not a bad idea. Of course long term
the reasons for prioritizing repos should be examined and fixed. OTOH
we know that some issues with repos not being compatible to users by
definition have been attacked quite often in the last 1 1/2 year and
still were not resolved. So there is definitely a need for such a
system.
There will be bugs in using prioritized repo structure, such as A
requiring a fixed package B, which is forbidden to be upgraded by
smart/apt due to priority rules. In order to overcome such a situation
B would have to provide B-feature-X-is-fixed and A depend on this.
Currently the assumption is that since A and B are maintained in the
same repo, such implicit dependencies/properties are seldomly cast
into the specfile. Creating dependencies on specific releases also
makes the package less generic and portable.
An example would be transcode, which can have a lot of different
support in its baggage. smart itself would be another example, which
requires a patched up rpm, which ATrpms provides, but from a package
POV is indistinguishable from a non-patched rpm (there are no extra
Provides). Using smart from ATrpms for say Red Hat 7.3 w/o using the
patched up rpm will do no good.
The bottom line seems to be, if there will be support from repos for
prioritizing schemes, each package need to be considered outside of it
own repo context, which is quite hard to do. OTOH it rises the
packaging quality of that package, and it will make it cross-repo
friendlier will even make it more cross-distro friendly.
--
Axel.Thimm at ATrpms.net
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
19 years, 5 months
X86_64 Yum Question
by Janina Sajka
Is there a way to tell yum to install a i386 version of some package if
the x86_64 version isn't available? Is there some documentation that I
should be reading on this? Or more generally on the do's and don'ts of
mixing 32 bit apps onto an 64 system?
Thanks for any guidance.
Janina
> Hi,
>
> When I select Preferences -> Advanced in Thunderbird 1.0rc I see a
>
> XML Parsing Error: not well-formed
> Location: chrome://messenger/content/pref-advanced.xul
> Line number 208, Column 5:
>
> This is after rebuilding the src.rpm on RHEL3 (with a few tweaks),
> so I'm now wondering if this also happens on FC3. Anyone?
>
> Thanks,
>
This kind of problem happened to me after upgrading without restarting
thunderbird. Have you tried closing thunderbird completely and reopening?
Warren
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
19 years, 5 months
Broken %post scriptlets in recent java packages
by Enrico Scholz
Hello,
recent java-packages (ant*, xerces*, ...) have scriptlets like
| $ rpm -q --scripts servletapi5-javadoc
| postinstall scriptlet (using /bin/sh):
| rm -f /usr/share/javadoc/servletapi5
| rm -f /usr/share/javadoc/jsp-api
| ln -s servletapi5-5.0.18 /usr/share/javadoc/servletapi5
| ln -s jsp-api-5.0.18 /usr/share/javadoc/jsp-api
This is really bad code because it does not make sense in an rpm-world
and causes problems in combination with the %_netsharedpath feature.
E.g. when the /usr/share filesystem is shared between several hosts you
can:
* manage (add, remove, modify) files on this filesystem on exactly one
host, and
* mount this filesystem (e.g. over NFS) as read-only on the other hosts
and add it to rpm's %_netsharedpath. E.g.
| # cat /proc/mounts | grep /usr/share
| morden:/usr/share /usr/share nfs ro,...
|
| # rpm --showrc | grep netsha
| -14: _netsharedpath ...:/usr/share:...
Then, rpm will assume the files under /usr/share as existing and does
not touch them:
| $ rpm -qs servletapi5-javadoc
| net shared /usr/share/javadoc/jsp-api-5.0.18
| net shared /usr/share/javadoc/jsp-api-5.0.18/JAVADOC.PLACEHOLDER
| net shared /usr/share/javadoc/servletapi5-5.0.18
| net shared /usr/share/javadoc/servletapi5-5.0.18/JAVADOC.PLACEHOLDER
In such a scenario, scriptlets like above will fail horribly
| Preparing... ########################################### [100%]
| 1:servletapi5-javadoc ########################################### [ 50%]
| rm: cannot remove `/usr/share/javadoc/servletapi5': Read-only file system
| rm: cannot remove `/usr/share/javadoc/jsp-api': Read-only file system
| ln: creating symbolic link `/usr/share/javadoc/servletapi5/servletapi5-5.0.18' to `servletapi5-5.0.18': Read-only file system
| ln: creating symbolic link `/usr/share/javadoc/jsp-api/jsp-api-5.0.18' to `jsp-api-5.0.18': Read-only file system
| error: %post(servletapi5-javadoc-5.0.18-1jpp_3fc) scriptlet failed, exit status 1
As already said, this does not make sense in an rpm-world. There, the
'jsp-api' symlink should be created in the %install stage and packaged
as an ordinary file. Then, rpm will unpack it correctly (inclusive
honoring the %_netsharedpath) and no %post scriptlet is needed.
Enrico
19 years, 5 months
Some encryption-related projects
by W. Michael Petullo
I have several encryption-related projects that I like to advertise
on this list every once in a while in hopes of attracting interested
developers or testers. Since we are just beginning work on Fedora Core
4, now seemed like a good time to mention them.
1. Encrypted swap.
This is a prerequisite for many different disk encryption techniques.
See [1] for a good example of why this is necessary (potential shortcoming
of Apple's FileVault). See Red Hat bug #127378 for some discussion about
this, including a proposed patch for initscripts. The patch has not been
scrutinized very much yet, so is only meant to encourage discussion at
this point.
2. Encrypted root filesystem.
Red Hat Bug #182479 discusses adding support for an encrypted root
filesystem to Fedora. The bug contains a patch for mkinird that
facilitates this. Eventually it would be nice to see support in anaconda
for this, but #182479 is the first step.
3. Pam-keyring.
The pam-keyring PAM module unlocks a GNOME keyring for a user using that
user's login password. The idea behind pam-keyring is to make using
GNOME keyrings as transparent as possible. Pam-keyring is available
at http://flyn.org/projects/pam_keyring/index.html.
4. Command line gnome-keyring tool.
GNOME bug #155681 proposes an addition to gnome-keyring. The
gnome-keyringtool utility is a program that manipulates keyrings from
the command line. I originally wrote gnome-keyringtool so that it could
be assigned SELinux privileges and used by pam-keyring. This avoids
assigning additional privileges to various login programs.
5. Automounting encrypted removable filesystems.
I would like to see encrypted removable filesystems handled as
transparently as other removable media. Red Hat bug #133461
discusses this a bit. I have done some experimentation with
this and have a prototype working. However, my work contains
a large kludge to get HAL to acknowledge dm-crypt filesystems
properly. Documentation of this shortcoming may be found at
http://freedesktop.org/pipermail/hal/2004-September/001051.html and
http://marc.theaimsgroup.com/?l=linux-kernel&m=109937418210973&w=2.
[1] Archive of bugtraq mailing list message:
http://securityfocus.com/archive/1/367116/2004-06-24/2004-06-30/0
Date: 06/25/2004
Subject: Mac OS X stores login/Keychain/FileVault passwords on disk
Author: Matt Johnston
--
Mike
:wq
19 years, 5 months
Slow X on x86_64
by Hugh Caley
I'm having a problem with an install of FC3 on an Opteron machine. The
X performance is deadly slow; glxgears gives me less than 53 FPS. On a
similarly x86 32-bit machine I'm getting well over 500 FPS. It's the
same with both a Matrox G550 and an ATI Radeon 9200 card.
Seems to be a problem with drm and dri initialization.
Anyone else seeing this?
I've added to a bugzilla bug that seems to be on target. There are
errors and xorg.conf snippets there. Interestingly, it seems that it
isn't x86_64 specific.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142105
--
Hugh Caley | Unix Systems Administrator | CIS
AFFYMETRIX, INC. | 6550 Vallejo St. Ste 100 | Emeryville, CA 94608
Tel: 510-428-8537 | Hugh_Caley(a)affymetrix.com
19 years, 5 months
Fedora Core Release Policy
by Vamsi K Kambhampati
I dont know if this question was raised before, but is there a general
policy pertaining to fedora core release cycles? I mean is the release
policy something similar to kernel releases? (odd for development, even
for stable/bug-fixed packages?).
I apologize if this would not be the appropriate list, but oh well all I
need is an answer (from someone).
Thanks
-- Vamsi
19 years, 6 months
Fedora and Redhat EL
by Rahul Sundaram
Hi
I have been using both Fedora and Redhat EL systems
and it seems to me that the split between these
distributions makes it more easy for Fedora to form a
community with a set of third party repositories and
packagers working with it while Redhat EL is left out
in the cold with a few exceptions like dag's
repository.
One of the reasons is that Redhat EL is tied into a
subscription model (ie) the binaries are not available
for free from Redhat itself. While third party
rebuilds like centos(centos.org) do a good job of
filling that need, it might be more beneficial for
Redhat to supply the binaries and ISO images itself
without a support subscription attached to it. A
subscription would only be available for a fee.
Benefits
* Business strategy is clear, Software is free.
Support costs.
* Prevents Redhat EL(or even Linux itself) being
called a costly affair
* Redhat can actively form a community just like what
it is trying to do with the fedora project
Disadvantage
- From a business viewpoint
One of the reasons seems to be that people would
download the software and expect Redhat to support it
too.
I see a few choices to make that clear to the end user
* A click through agreement that says the software is
unsupported.
* called it redhat-unsupported-(arch).iso
* A nag in the installer warning that the software is
unsupported when its the download version. Remove all
the trademarks and stuff you need to protect and swap
it with a free set of things you dont need to care
about..
Bandwidth
ISO images are only available directly to those who
mirror it.
up2date, yum or whatever never points to the redhat
mirrors in the downloaded version and instead switches
between the free mirrors as required
Since those who want to use it for free are going to
use a rebuild anyway, I dont see a potential loss
there.
Your thoughts?
=====
Regards
Rahul Sundaram
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
19 years, 6 months
