XFree86-4.3.0-50 testing update issue with Radeon Mobility 9600
by Matthias Saou
Hi,
I've got an ATI Radeon Mobility 9600 in my laptop. It's not recognized by
FC1's original XFree86 build, so I initially had to install 4.4RC2 in order
to get accelerated 2D working with the radeon driver (binaries from
XFree86.org).
I saw some backports had been included for ATI drivers in the latest
XFree86 testing update, so I gave it a try : X starts, no problems
whatsoever, gdm is there, yeah! But... when I log in through gdm or
"startx" from runlevel 3 the computer completely locks up (nasty freeze,
mouse not moving, network dead... you get the picture) on the GNOME splash
screen, even before the first little logo (service being run) appears.
Back to 4.4RC2 things work again, minus some issues with xfs dying at
random times and ttmkfontdir segfaulting, but I had that before too.
As this is for a card not initially supported by FC1, and as I'm unable to
get any kind of useful debug info, I doubt this is worth bugzilla'ing :-(
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 1 (Yarrow) - Linux kernel 2.6.1-1.65
Load : 1.19 0.61 0.39
20 years, 3 months
RE: Fedora Core 1 Test Update: spamassassin-2.63-0.1
by Randal, Phil
Is this not a bit of overkill for FC1?
I rolled my own spamassassin-2.63 RPM by basically rebuilding FC1's
spamassassin-2.60 RPM with the SA 2.63 tar.gz file.
If what we had was adequate for FC1, why not the same approach for the
update?
And sort it out properly for FC2?
Cheers,
Phil
---------------------------------------------
Phil Randal
Network Engineer
Herefordshire Council
Hereford, UK
> -----Original Message-----
> From: fedora-test-list-admin(a)redhat.com
> [mailto:fedora-test-list-admin@redhat.com]On Behalf Of Warren Togami
> Sent: 11 February 2004 10:19
> To: fedora-test-list(a)redhat.com; Chip Turner; Ville Skyttä
> Subject: Re: Fedora Core 1 Test Update: spamassassin-2.63-0.1
>
>
> Warren Togami wrote:
> > Michael Schwendt wrote:
> >
> >> On Wed, 11 Feb 2004 08:14:02 +0100, shrek-m(a)gmx.de wrote:
> >>
> >>
> >>> # rpm -q spamassassin spamassassin-2.60-2
> >>>
> >>> # rpm -Uvh
> >>>
> /mnt/sda1/updates/download.fedora.redhat.com/pub/fedora/linux/
> core/updates/testing/1/i386/spamassassin-2.63-0.1.i386.rpm
> >>>
> >>> Fehler: Failed dependencies:
> >>> /usr/lib/perl5/vendor_perl/5.8.1 is needed by
> >>> spamassassin-2.63-0.1
> >>>
> >>> # rpm -q perl
> >>> perl-5.8.1-92
> >>>
> >>>
> >>> is --nodeps needed ??
> >>
> >>
> >>
> >> No. An updated test update package will be needed to fix
> this, as on FC1:
> >>
> >> $rpm --redhatprovides /usr/lib/perl5/vendor_perl/5.8.1
> >> file /usr/lib/perl5/vendor_perl/5.8.1 is not owned by any package
> >>
> >> A future Perl package will own more directories and also the vendor
> >> locations. So, presently, an FC1 test update must not and cannot
> >> depend on
> >> that directory.
> >>
> >
> > [root@laptop root]# rpm -q perl
> > perl-5.8.1-92
> > [root@laptop root]# rpm --redhatprovides
> /usr/lib/perl5/vendor_perl/5.8.1
> > file /usr/lib/perl5/vendor_perl/5.8.1 is not owned by any package
> > [root@laptop root]# rpm -ivh spamassassin-2.60-2.i386.rpm
> > Preparing...
> ###########################################
> > [100%]
> > 1:spamassassin
> ###########################################
> > [100%]
> > [root@laptop root]# rpm -Uvh spamassassin-2.63-0.1.i386.rpm
> > Preparing...
> ###########################################
> > [100%]
> > 1:spamassassin
> ###########################################
> > [100%]
> >
> >
> > At first I was like "HUH?" Why does it work for me but not
> you... but
> > then I found the reason.
> >
> > [root@laptop root]# rpm -qf /usr/lib/perl5/vendor_perl/5.8.1
> > perl-DateManip-5.42-0.fdr.2.a.1
> > perl-RPM-Specfile-1.13-0.fdr.2.1
> > perl-Digest-Nilsimsa-0.06-0.fdr.4.1
> >
> > All perl modules provided by fedora.us seems to own this
> directory. So
> > this leaves us with two questions:
> >
> > 1) Can someone check if this problem still exists in rawhide?
> > 2) What should we change the Requires to for this FC1 update? I am
> > thinking "Requires perl >= 2:5.8.0" which is like how it
> was before. It
> > required rebuilding for different pre-FC2 perl versions, but that's
> > acceptable I guess.
> >
> > See the thread "perl and multilib considerations" from
> January where
> > this was previously discussed. Since Chip Turner's suggestion of a
> > virtual provides does not exist in these older perl
> versions, we have to
> > use an imperfect solution. #2 above may be good enough for now.
> >
> > I'll roll the next FC1 test update when I wake up Wednesday
> based upon
> > comments here. Just a sanity check please.
> >
> > Warren
> >
> >
>
> <mschwendt> warren: Well, the current Perl package does not own the
> vendor directories. So including them in the spamassassin
> package would
> be cleaner, to avoid the problem of restrictive admin umask creating
> them with insufficient permissions. You could depend on $privlib
> (although you don't install into it), because that's the
> first directory
> owned by "perl" which is versioned.
> <warren> mschwendt: it seems that the fedora.us perl modules own that
> directory too
> <mschwendt> warren: fedora.us perl packages own them to avoid the
> problems of leaving empty directories behind and the
> permissions problem
> <mschwendt> warren: why do you depend on a path instead of
> "perl = 3:5.8.1"?
> <warren> mschwendt: (got the idea from mharris xchat spec, I thought
> that too was correct but now I believe it has the same
> problem that we
> see here)
> <warren> mschwendt: I thought it was working until this
> discovery, and
> we had a thread discussing it late January
> <warren> mschwendt: Chip Turner's solution creating a
> standard virtual
> provides sounded like the best solution for FC2+, but I thought this
> solution was working in FC1. I was wrong. It only worked
> while I had
> fedora.us perl modules installed.
> <mschwendt> warren: hmmm, stock spamassassin in Yarrow
> depends on "perl
> >= 2:5.8.0" which is bad.
> <warren> yes, the old method was bad, but it generally worked
> as long as
> your sources weren't broken
> <mschwendt> warren: that's why it is unfortunate that
> fedora.us packages
> must work around unowned directories by owning them. Creates problems
> like this.
>
> Okay so... bottom line:
> FC1's perl package unfortunately means we must use ownership
> with module
> packages in order to avoid unown directories and associated problems
> (like unable to strip binaries). While this situation can be easily
> remedied in FC2's perl so we no longer need this hack, we
> need the most
> robust solution for now.
>
> Without Chip's suggestion of virtual Provides in place, what Requires
> line should go into this spamassassin FC1 update? Should we own the
> directories in spamassassin, like we do with fedora.us perl modules?
> Opinions please.
>
> Warren
>
>
> --
> fedora-test-list mailing list
> fedora-test-list(a)redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-test-list
>
20 years, 3 months
Fedora Bug Day Today...err I guess I mean Tonite..err so I guess i mean Fedora Bug Nite Tonite!!!!!!
by Jef Spaleta
Fedora Bug Day Tonite!!!!!! 7.30pm EST - 'til I fall asleep
Theme: A general call to arms, for bugbusting!!!!!
*Why tonite? Why not today?
Sadly, I'm being forced to be away from all internet connected computers
today, and my wireless neural implant isn't working. Someone is trying
to tell me i have "work" to do, or something. I'm just as confused as
you are about all this. But this evening, unless my isp has other
plans, i'll be jacked into the net for a large chunk of time. Drop by
#fedora-bugs on the freenode network in about oh 10 or so hours from now
and help get involved with the bugzilla triage effort. Though now that
mitr has bugzilla editting rights, you can stop into the irc channel in
the meantime and see if he's around. So if you want to help out with
triage. What is triage?
maybe this will explain:
https://lists.dulug.duke.edu/pipermail/fedora-triage-list/2004-January/00...
*What can i do RIGHT NOW!
Become involved in the fedora.us QA process and help QA packages that
are waiting to be published in the fedora.us addon repo:
http://www.fedora.us/QA
Please look over that list, and pick a package you would like to see
published for the community to enjoy that you are interested in.
There are 348 packages sitting waiting for QA. That's 348 packages the
Fedora community could be enjoying in the published fedora.us repository
trees, once they have made it through the community peer-review process.
Remember, until the full merge is completed and Fedora Extras and
Alternatives is up and running...community packagers are being advised
to use fedora.us's process. How do you become involved in the fedora.us
peer-review process? Easy, read:
http://www.fedora.us/wiki/PackageSubmissionQAPolicy
Not only is this a good way to help out, by being part of the
peer-review process that helps make sure high quality packages are
available to the community, but doing the peer-review QA, can help you
learn how to do better rpm packaging. For those of you who dream of the
fame and fortune of being Fedora Extras contributors down the road,
getting involved in the fedora.us QA process now is a good place to
start.
-jef"technically, getting this notice out 10 hours before I'm going to
be available, actually means this notice isn't late...in fact its
probably the earliest notice i've done for a bug day so far"spaleta
20 years, 3 months
download.fedora.redhat.com
by Paul F. Johnson
Hi,
I've noticed that there is now a testing-1.90 directory on the fedora
ftp site. You can't get into it (550, fail to change directory).
When is this opening up to the world and his frog?
TTFN
Paul
20 years, 3 months
terminology and the hierarchy of releases
by Robert P. J. Day
ok, knowing that i'm going to embarrass myself by posting this, i'd like
to make a couple observations about the hierarchy of rpms available for
download, at least with respect to fedora. feel free to point out where i
am big-time confused.
as i read it from the web page
http://fedora.redhat.com/download/updates.html
i can conclude that there are four levels of rpms, in order of
stability and testing:
1) base (the actual official release)
2) updates (approved)
3) proposed updates (a.k.a. updates/testing)
4) development (cutting edge)
now, first observation -- while numerous people refer to "rawhide",
there's no mention anywhere on that page that rawhide is in fact
equivalent to the development stuff. perhaps a note to that effect on
that page would be useful.
next, if i add an entry for the development repository to my yum.conf
file, from what seth wrote, i should remove entries for the updates and
testing repos, right? does this mean that some rpm in development might
in fact be an older version of what might be found in updates? that is,
a test release might represent backing off from an updated version in
an earlier release? or is that hierarchy above supposed to represent
monotonically non-decreasing version numbers as i go from 1->2->3->4?
if that's true, then i should be safe leaving in the updates and testing
entries in /etc/yum.conf, no?
finally, is it really true that the rawhide/development rpms represent
the basis for the next test release? it would seem to me that anything
to be included in the next release should represent at least a minimal
amount of testing and stability, while historically, i remember rawhide
being used for really bleeding-edge, way-out-there software for which
there was absolutely no guarantee.
IOW, if you look at development as the basis for the next release,
you'd think there should still be a category beyond even *that* --
stuff that is still so new and untested that it's not yet being
considered for the next release. at least, not at this time.
comments?
rday
20 years, 3 months
usb devices
by Brian Millett
Well, thanks to you all for hints on getting the hotplug working. Seems
that I needed to add more to my modprobe.conf than with core 1. The
ehci-hcd was the module. Strange as the kernel has not changed. So now
I have the following in /etc/modprobe.conf and it works great. The
zaurus usb-ethernet connection works, the usb flash drive mounts, my
canon s40 camera is recognized.
alias usb-controller uhci-hcd
alias usb-controller1 ehci-hcd
alias usb-controller2 usb-ohci
alias usb-controller3 hci-usb
How, where should I look on adding the items in /etc/fstab to the gnome
right-click on destop menu?
Thanks
--
Brian Millett - Technologist Rex
"Now, I go to spread happiness through the rest of the station. It is a
terrible responsibility, but I have learned to live with it."
-- Londo, "A Voice in the Wilderness I"
20 years, 3 months
Re: No sound under the 2.6.1 test kernels
by Dave Jones
On Fri, Feb 06, 2004 at 08:53:36AM -0800, Greg KH wrote:
> On Fri, Feb 06, 2004 at 04:44:21PM +0000, Dave Jones wrote:
> >
> > usb_get_device_descriptor doesn't seem to get exported in the current
> > 2.6 tree, and frankly I'm not sure if it should be. Greg ?
>
> No, it shouldn't be, and I did fix up the snd_usb_audio file to reflect
> this change. What kernel version is this? I don't see the problem in
> 2.6.2.
Ah, original bug reporter was using an older FC2 kernel tree, which was
based on 2.6.2rc.
Dave
20 years, 3 months
IA64 Kernel panic?
by Andrew Waterman
Hi all,
I've downloaded the trial iso for use with my AMD64 and keep getting a
kernel panic on load of the iso. Any suggestions? I can't get any
install to work for any version of linux which I've pulled down. I've
looked for FAQs, etc, but can't seem to find anything. Any suggestions?
best,
A
---
Andrew Waterman awater(a)devnull.net
P.O. Box 181 510.830.9706
Berkeley, California 94701
---
"The future is beautiful."
-- Nova (http://www.discogs.com/release/45314)
20 years, 3 months
Fedora Athlon 64 Yarrow / KDE 3.2 multimedia
by Hamish Friedlander
Hi,
This the right place for this? It seems like a specific problem with
x86-64 builds, so I'll try here first
I'm trying to get KDE 3.2 working on the x86_64 .96 test build of Core
1. I've downloaded the Fedora SRPMS from kde.org, and recompiled them.
And _almost_ everything works great.
However, when using Noatun or Juk, playing any media doesn't work (.mp3,
.ogg, .wav). Using kaboodle (which does its own decoding?) they play
fine, but with Noatun or Juk, they seem to be playing (the progress bar
progresses and the spectrum analyser spectrum analyses), but no sound
comes out. I'm using the original kdemultimedia, not the patched
version, and mpeglib_artsplugin is built and installed.
Using the arts status thingy, it reports mp3, ogg, etc, as media types,
and running Noatun makes the channel show up on the arts monitor.
If I run artsshell, and call TraderCheck, I get a bunch of errors, the
most interesting of which is something like
Trader Error: OggPlayObject
Interface not found
Thats approximate (I'm at work - Athlon 64 is at home with no email),
but pretty close.
Anyone got any ideas? I'll continue to play tonight, but after that I'll
probably just give up and use some other player.
Hamish Friedlander,
Software and Systems,
Ullrich Aluminium
P.S. I sent this off list, and I guess it got lost in the moderator
spambucket. Sorry if it ends up getting posted twice.
20 years, 3 months