I'd like to have a show of hands of who's for xine and who's for
mplayer. Which one is the better choice for a complete multimedia
solution? I've used both and have to say that I've had problems with
With xine I've been able to play most all formats with the exception of
Windows media (although I know the codecs are out there). I've gotten
the gxine frontend which includes a plugin for mozilla. Unfortunately
I've had many many crashes of mozilla / xine when using the plugin.
With mplayer (which I've just recently installed), I've had better
stability (although it has crashed on inline movies), but I don't know
the extent of the formats that it can play. Also I haven't seen a
frontend to mplayer so far....I assume that one does exist.
Thanks in advance!
The automake we have in Fedora development no longer provides
mkinstalldirs, but the gettext m4 macros and Makefile.in.in still want
to use it. The same goes for glib-gettext.m4.
Are these things that we need to fix before release? I guess they'll
prevent maintainers from being able to release packages using Fedora
Or is it only me seeing it?
I'm at fedora-devel-latest, and the panel and icons are very much
screwed up... This has been the case for the last week or so,
and no updates have solved this problem...
If this is going to be fixed up by packages released in the next
few days, that is fine by me. I can wait.
If I'm the only person experiencing this, please offer me a way make
the problem more obvious, or suggest ways to fix this.
If it is a known issue, and it is going to be a week or more, I'll try
to back down to GNOME 2.4 and see what happens...
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
if akira is not taking care of the package, and if we include sylpheed
in FC2, I'd like to take it. Seems like a harmless enough exercise,
it cannot be worse than having a dead maintainer, right?
I am not sure whether or not to post this as a bug, but in the devel
series of Fedora, the location bar and tool bars in Nautilus seem to be
Is this a known problem? Configuration? Just a wait and it will come
Thanks for any information,
"'We have two ears and one mouth, so we may listen twice as much as we
speak' -- Epictetus. Aha! This obviously explains many people's attitude
to Usenet: 'We have ten fingers and two eyes, so we may type five times
as much drivel as we actually bother to read.'" -- alt.humor.best-of-
Are there any 3Dfx users out there still, using Voodoo 3/4/5 or
Banshee, who are interested in DRI support (3D acceleration)
continuing to be part of the distribution?
What a perfect time to volunteer!
Essentially, Glide3 source code is rather insane, compiler picky,
and gcc barfs on it nowadays. It was unmaintained upstream for 2
years, but we kept it because "it worked". Now, "it doesn't
work", and is a zero-priority level package basically.
I hate to drop hardware support, but continuing to maintain an
aging unsupported package like this is a waste of resources that
I could be much better spending, hacking on more relevant stuff.
I really don't plan on spending any time on this rather obsolete
package anymore however if nobody upstream or out in the
community is interested in keeping it alive, and I'm definitely
not interested in becoming the upstream maintainer. That said,
there are upstream people still working on Glide, however there
are some "issues" with switching to the new code, including the
fact it's never been widely deployed or tested yet.
If someone is interested in volunteering to make this compile
again, in Fedora Core 1 and 2, please contact me back, or hop
into IRC. My preference is to allow others to get involved
rather than just dropping something that some people out there
are bound to still use, and would like to see it remain in the
Thanks in advance.
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
I have a question about distribution upgrade : how should we deal with
unmaintained packages which don't work in the new distribution ? Let's say
we have included a program in Extras (or main) and the project stops for
some reason. At some point in the future, the program will stop working
(API change, glibc upgrade, ...). How should we deal with such a package
(except not including it in the first place of course ;) ) ?
We could tell Anaconda to remove it (well I don't know much about Anaconda,
but I suppose it is possible), but what about online upgrades using yum or
Thanks for your explanations
http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info
"As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours ; and
this we should do freely and generously." -- Benjamin Franklin
Since XFree86 4.4.0 is nearing release soon, I have started to
get an increase in the number of questions asked about it, and
about my XFree86 plans for Fedora Core and future development.
Rather than answer them over and over again in IRC, mailing
lists, and direct email, I thought it would be a better idea to
post this brief summary publically on a few of our lists, in
hopes that you all can help me to get the message around to the
masses. ;o) Please DO NOT directly email me or ask me in IRC
when it will be ready. Keep this FAQ handy instead, and reread
it every few days. ;o)
Q) What release of XFree86 will Fedora Core 2 be shipping?
A) XFree86 4.3.0 is what will ship in Fedora Core 2. It will
contain a number of bug fixes, Radeon driver fixes and other
improvements to further stabilize the 4.3.0 series, and give
Fedora Core a relatively mature XFree86 base. I would also
like to update the "via" driver to Alan Cox's new DRI
enabled via driver, so that VIA EPIA users can enjoy 3D
acceleration. I'm probably going to do a number of other video
driver updates and scan bugzilla for the most critical issues to
spend some time on. Any large-risk issues will likely not be
addressed until 4.4.0 is integrated into the distro however if I
believe the risk of regression to be too great to be worth taking
for a given problem. I've considered a great number of technical
and other issues/factors in coming to this decision.
Q) When will XFree86 4.4.0 be officially released?
A) XFree86 4.4.0 is still under development, and it's official
release date is not known. XFree86 releases generally miss their
originally projected release dates by anywhere from 1 month to 6
months or greater. XFree86 4.4.0 was planned to be released
originally on Dec 15, 2003 or so, however it is still under
development, and a new release candidate was announced earlier
today or yesterday. Any release date predictions are generally
unreliable, as there are countless factors that can delay a
release from occuring when developers originally intended to
release the new release. Generally, this means that many more
bug fixes are being worked on, and it's better to have an XFree86
release that is less buggy and released later on at an
unpredictable time, than earlier and contain many bugs that might
not get fixed for another year or so. So the best answer to this
question is the one people so hate to hear - "When XFree86.org
thinks it is ready."
Q) Why isn't XFree86 4.4.0 going to be in Fedora Core 2?
A) The simple answer, is that XFree86 4.4.0 has not been released
yet, and the release date is not known or 100% predictable.
There is a good chance it will be released prior to the release
of Fedora Core, however, in order for it to be integrated and
into the distribution properly, and some of the other changes I
plan on making for 4.4.0, it needs to be done early enough in the
cycle that there is time to work out any major stop-ship problems
that arise, and fix them. I prefer to ship something known to be
relatively stable, with additional bug fixes, than to ship
something of unknown stability as a rush job, late in the cycle
without having enough proper beta testing occur. Fedora Core is
intended to be more cutting edge, but I don't want bloody fingers
from rushed packages. <grin> Besides, users who really want to
use 4.4.0 on Fedora Core 2 (and possibly Fedora Core 1 and older
releases also) will be able to do so very easily when I do make
my 4.4.0 rpms available (see next question). This will allow
those who want the bleeding edge, to have it and use it, while
those who want the more stable and mature release to get that by
default. I think this is the best overall solution, especially
since we have no idea when 4.4.0 might be released. ;o)
Q) When will XFree86 4.4.0 rpm packages become available, and for
what Red Hat operating systems will they be available for?
A) I have been working on 4.4.0 packaging for a while now, and
will be releasing rpms sometime soon, but no specific date. I
want the initial publically posted packages to be in a certain
state, and they're not quite there yet. They will be available
on ftp://people.redhat.com accessible via FTP and yum, and I will
send out an announcement to xfree86-list(a)redhat.com and
fedora-devel-list(a)redhat.com to announce it with more detailed
instructions. The initial builds will be provided as 'rawhide'
built rpms (but not put into rawhide itself). At some point,
if I have enough time, I might also provide Fedora Core 1
rpms, and perhaps RHL 9 and RHL 8.0 rpms. No promises,
however if and when I make any releases, I will announce them
on the two mailing lists mentioned above. RPMS will be available
for whatever architectures happen to compile through to
Q) What are the major new improvements and benefits of XFree86
4.4.0 over previous releases?
A) The largest user-visible improvements in XFree86 4.4.0 are
updated video drivers which support most newer video hardware to
some degree or another, IPv6 support for the X server,
(hopefully) saner default settings for the server/drivers. There
are many other things, but I can't remember it all. Read the
XFree86 CHANGELOG document for details. ;o)
Q) Will there be Radeon IGP DRI support?
A) No. Use DRI-CVS for Radeon IGP DRI support.
Q) Will there be Radeon 9500/9600/9700/9800 DRI support?
A) No. The specifications for the 3D engine of that hardware is
not available, and nobody is working on it currently or planning
on doing so to the best of my knowledge. If the specifications
were to become available, it would probably be anywhere from 6 to
12 months for stable DRI support to become available, and require
funding to develop. For further details, please search the DRI
project's mailing list archives for this very frequently asked
question, as the answer doesn't change over time. ;o)
Q) Will you ship the Radeon merged framebuffer support from
DRI-CVS, so people can use pseudo-Xinerama with DRI?
A) No, it is in experimental CVS for a reason. Once it is
integrated into XFree86.org it will become part of a future OS
release sometime down the road. Users wanting to test this
experimental support before then can build DRI-CVS or download
prebuild drivers from the DRI project directly.
Q) What is the freedesktop.org kdrive xserver?
A) kdrive xserver, also known to many as "The freedesktop.org X
server" has some nice eye candy which Keith Packard has whipped
up. This X server is not intended for general purpose usage, but
is instead an experimental X server intended for developing new X
technology and testing it out. It currently caters more to
active X developers, and those interested in hacking on the
server itself, however others do play with it as well. It does
not support all of the video hardware XFree86's X server
supports, and it does not have DRI support and other fancy
features. It was originally designed years ago for PDAs and
embedded systems, so it is quite small. Search google for
"tinyx" and "kdrive" to learn more, as well as visiting the
freedesktop.org xserver pages.
Q) Do you plan on shipping it in Fedora Core?
A) Not as a "supported" X server intended for general purpose
usage, no. I do think that it has some cool geek factor though,
and that it would be cool to include it in Fedora Core as a more
or less "as-is" unsupported thing for people to play with who are
interested in doing so. Fedora-Extras/fedora.us might be a
better place for it though. If it does not end up there, I'll
probably have unofficial rpms on people.redhat.com for people to
play with at some point, and make an announcement here.
Q) Do you plan on using freedesktop.org X libraries?
A) I am currently exploring the possiblity of using the
freedesktop.org X libraries, or at least some of them, however I
have not yet reviewed them all, nor investigated the
integrational issues widely enough to draw any conclusions or
make any commitments at this point. I do however like the idea
of a less monolithic, more modular X11 build, and I believe
modularized libraries have a number of good benefits both for
development, maintenance, and for end users. I'm enthusiastic
about the project, and would like to find the time to contribute
more directly to it in the future. We'll have to wait and see
how things come along.
Q) What do you think about the recent news of X.org and
A) I read the Newsforge article, and think that it is encouraging
to see related projects collaborating together more closely.
Hopefully this will benefit future development of X11 and related
I think that pretty much summarizes the majority of questions
I've been getting lately. If there is something that I have
overlooked, PLEASE DO NOT email me or IRC me directly, but
instead, post a message to xfree86-list, so that myself or
someone else who knows the answer can reply and multiple people
can benefit from the answer. Of course, please be sure to check
the mailing list archives first, in case the question has been
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
Does anyone have an oppinion in relation to adding some antivirus features
I think we are badly in need of a generel purpose virus scanner that will
allow scheduled scans (possible on-access) and fast e-mail content scanning.
What I have in mind personally would be something like :
- ClamAV (which looks very promising)
- amavisd-new (or similar that would allow checking of mail going through
sendmail and postfix)
The products should probably be suitable to work with either of out
implementations available (sendmail/postfix).
There is already a bug reported on this (#82017) but it doesn't seem very
active. Check it out!
Please share your experiences and ideas!
Has anyone been using Jeremy's evo 1.5.2? If so, is it any better than
1.5.1 as crashes and such go this time? Is it still not yet too usable?
"It's funny until someone gets hurt...then it's hilarious!"