Vector-based Fedora Logo Available?
by Ricky Boone
Probably a really stupid question..., but will there be a version of the
(final) Fedora logo as a vector-based image, in a format like EPS, SVG,
etc?
Just an off the wall question. :)
20 years, 6 months
sound-juicer update??
by Jens Knutson
Will Sound Juicer .5.5 make it into FC-final 1? It includes what I
think are probably rather important bug fixes, including the following,
excerpted from the changelog:
* Threaded MusicBrainz lookup
* Open directory actually opens the best directory
* Pipeline rebuilt after every track, works around gst-lame crashes
* Correctly handle the artist in multiple artist albums
* Fix crashes when closing dialogs with escape (Frederic)
I don't mean to nag, but the release date for FC-final 1 looms, and it'd
be a shame if such a nice music ripper shipped with those stupid bugs.
Feel free to call me a spaz if this is already on the table and just
hasn't been released yet...
- jck
--
"The bugs in Sawfish, and its greater configurability, are not
orthogonal/unrelated facts"
-- Havoc Pennington
20 years, 6 months
rawhide disabled, will be back tomorrow-ish
by Bill Nottingham
rawhide is currently disabled while we reorganize some of
its content. It should be back sometime tomorrow. (2003-10-22).
We apologize for the inconvenience.
Bill
20 years, 6 months
Split & move yum headers deeper into the hierachy?
by Axel Thimm
Currently (or last time I checked) yum headers were created for all
archs in the rawhide toplevel hierarchy.
Would it make sense to create the yum headers per arch and closer to
the RPMS directory, so that it is mirrored and usable in partial
mirrors, too?
--
Axel.Thimm(a)physik.fu-berlin.de
20 years, 6 months
Re: Split & move yum headers deeper into the hierachy?
by Axel Thimm
[The original message had a bad To: address, please reply to this one
instead.]
Currently (or last time I checked) yum headers were created for all
archs in the rawhide toplevel hierarchy.
Would it make sense to create the yum headers per arch and closer to
the RPMS directory, so that it is mirrored and usable in partial
mirrors, too?
--
Axel.Thimm(a)physik.fu-berlin.de
20 years, 6 months
RPM segfaulting
by Peter Backlund
Hi.
I've caught several segmentation faults and other problems with
rpm-4.2.1-0.30 in Fedora 0.95 when installing software that's been
compiled on a different platform, and is only distributed in binary
form. Examples include Acrobat Reader (AR), Real Player (RP) and Flash
Player (FP). AR and RP are custom rpms built by myself (with attached
specfiles), FP is from macromedia.mplug.org.
Now, rpm -ivvh on acrobat-reader-* in a directory with both a-r-5.08.rpm
and a-r-plugin-5.0.8.rpm makes rpm segfault. a-r-plugin depends on a-r,
and putting them both on the same commandline results in
[root@localhost peter]# rpm -ivv acrobat-reader-*
D: ============== acrobat-reader-5.0.8-0.fdr.1.i386.rpm
D: Expected size: 9131647 = lead(96)+sigs(180)+pad(4)+data(9131367)
D: Actual size: 9131647
D: acrobat-reader-5.0.8-0.fdr.1.i386.rpm: MD5 digest: OK
(e83fa62e90330323915bbc6726c0ce89)
D: added binary package [0]
D: ============== acrobat-reader-plugin-5.0.8-0.fdr.1.i386.rpm
D: Expected size: 56726 = lead(96)+sigs(180)+pad(4)+data(56446)
D: Actual size: 56726
D: acrobat-reader-plugin-5.0.8-0.fdr.1.i386.rpm: MD5 digest: OK
(ccbdbea7814c388c3b51907db669b9cb)
D: added binary package [1]
D: found 0 source and 2 binary packages
D: opening db environment /var/lib/rpm/Packages joinenv
D: opening db index /var/lib/rpm/Packages rdonly mode=0x0
D: locked db index /var/lib/rpm/Packages
D: ========== +++ acrobat-reader-5.0.8-0.fdr.1 i386-linux 0x1
D: opening db index /var/lib/rpm/Depends create mode=0x0
D: opening db index /var/lib/rpm/Basenames rdonly mode=0x0
D: opening db index /var/lib/rpm/Pubkeys rdonly mode=0x0
D: read h# 1460 Header sanity check: OK
D: ========== DSA pubkey id fd372689897da07a
D: read h# 32 Header V3 DSA signature: OK, key ID 897da07a
D: Requires: /bin/sh YES (db
files)
Segmentation fault
Same situation with RP and FP. However, installing only the
acrobat-reader rpm works most of the time, but sometimes (hard to
reproduce, but has happened more than once) is gets stuck a la rpm in
rh8/9, last output being
GZDIO: 3100 reads, 25389892 total bytes in 2.210 secs
Strace output from rpm when segfaulting ends with
write(2, "========== DSA pubkey id fd37268"..., 42========== DSA pubkey
id fd372689897da07a
) = 42
write(2, "D: ", 3D: ) = 3
write(2, " read h# 32 Header V3 DSA s"..., 62 read h# 32
Header V3 DSA signature: OK, key ID 897da07a
) = 62
write(2, "D: ", 3D: ) = 3
write(2, " Requires: /bin/sh "..., 72 Requires:
/bin/sh YES (db files)
) = 72
rt_sigprocmask(SIG_BLOCK, ~[RTMIN], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
pread(5, "\0\0\0\0\1\0\0\0\0\0\0\0a\25\6\0\10\0\0\0\0 \0\0\0\10\0"...,
8192, 0) = 8192
pread(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
8192, 8192) = 8192
rt_sigprocmask(SIG_BLOCK, ~[RTMIN], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
20 years, 6 months
Newer ATI Radeon, ATI FireGL, and Nvidia GeForce/Quadro hardware support
by Mike A. Harris
This document concerns the current state of the XFree86 video
driver support for ATI Radeon, FireGL, and Nvidia GeForce and
Quadro video hardware which is present in Red Hat rawhide, and
the current Fedora Core OS test release. I'm posting this in
order to solicit feedback, and also to get more people involved
in reporting bugs and also notifying Red Hat and myself of any
missing hardware support, etc. for these 2 video drivers.
More information on the Fedora Project, and our current Fedora
Core test release can be found at:
http://fedora.redhat.com
Just to be clear, this information does not apply to any previous
Red Hat operating systems such as Red Hat Linux 8.0, 7.x, but is
exclusive to Fedora Core test 3 and later. Also, this video
hardware support will also be released as an update for Red Hat
Linux 9 in the near future, as:
XFree86-4.3.0-2.90.$RAWHIDE_RELEASE_NUMBER
ATI Radeon and FireGL support status:
XFree86 4.3.0, which is in Fedora Core test releases and rawhide
currently, contains additional patches to support newer ATI
Radeon and FireGL video hardware than what the stock XFree86
4.3.0 release supports. This support is a combination of 4
things:
1) Enhancements I've implemented myself voluntarily on
weekends, etc. and included, which either have been committed
to XFree86 CVS already, or will be in the future hopefully.
2) Code that I have backported from the XFree86 developmental CVS
head, either developed by ATI, or by other people who work on
the "radeon" driver.
3) Code contributed to me directly by ATI.
4) Code contributed to me directly by other developers.
Currently, our customized 4.3.0 "radeon" driver supports almost
all ATI Radeon and FireGL hardware. 3D is supported on all video
hardware up to and including the Radeon 9000 and 9100, FireGL
8700, 8800, and it may or may not also work on the 9200 hardware
(untested). 2D support is present for all hardware including the
9500/9600/9700/9800 series cards also, and the newer ATI FireGL
X1/Z1 hardware.
There are different variants of these cards out there however,
and some cards have different PCI device IDs than others, and so
for example, while Radeon 9800 is supported 2D only, it's
possible that someone might have a Radeon 9800 card that is
unknown to our pcitable, and unknown to the video driver, but
which otherwise should/would work ok once the PCI ID is made
known to the video driver and pcitable database. About 2 weeks
ago I updated the driver with a newer list of PCI IDs sent to me
from ATI which was believed to cover all of the existing hardware
at the point ATI sent me the files. I tested this on the
hardware I personally have available, and everything worked fine,
however I don't have one of every single card for every single
PCI device ID out there, so I can only vouch for the particular
chips I physically have available to test.
Since then a number of newer ATI Radeon and FireGL hardware has
been released by ATI, such as the 9800Pro XT and SE, 9600 XT/SE,
and new FireGL cards. I do not yet have all of this hardware,
however some of this hardware might work with the existing driver
currently in rawhide, while other cards might still need to have
their PCI IDs added before they're functional. This also goes
for the Radeon Mobility, FireGL Mobility, and ATI Radeon IGP and
Mobility IGP chipsets.
Here is a list of all chips that the driver currently supports:
ATI Radeon QD (AGP)
ATI Radeon QE (AGP)
ATI Radeon QF (AGP)
ATI Radeon QG (AGP)
ATI Radeon VE/7000 QY (AGP)
ATI Radeon VE/7000 QZ (AGP)
ATI Radeon Mobility M7 LW (AGP)
ATI Mobility FireGL 7800 M7 LX (AGP)
ATI Radeon Mobility M6 LY (AGP)
ATI Radeon Mobility M6 LZ (AGP)
ATI Radeon IGP320 (A3) 4136
ATI Radeon IGP320M (U1) 4336
ATI Radeon IGP330/340/350 (A4) 4137
ATI Radeon IGP330M/340M/350M (U2) 4337
ATI Radeon 7000 IGP (A4+) 4237
ATI Radeon Mobility 7000 IGP 4437
ATI FireGL 8700/8800 QH (AGP)
ATI Radeon 8500 QI (AGP)
ATI Radeon 8500 QJ (AGP)
ATI Radeon 8500 QK (AGP)
ATI Radeon 8500 QL (AGP)
ATI Radeon 9100 QM (AGP)
ATI Radeon 8500 QN (AGP)
ATI Radeon 8500 QO (AGP)
ATI Radeon 8500 Qh (AGP)
ATI Radeon 8500 Qi (AGP)
ATI Radeon 8500 Qj (AGP)
ATI Radeon 8500 Qk (AGP)
ATI Radeon 8500 Ql (AGP)
ATI Radeon 8500 BB (AGP)
ATI Radeon 7500 QW (AGP)
ATI Radeon 7500 QX (AGP)
ATI Radeon 9000 Id (AGP)
ATI Radeon 9000 Ie (AGP)
ATI Radeon 9000 If (AGP)
ATI Radeon 9000 Ig (AGP)
ATI Radeon Mobility M9 Ld (AGP)
ATI Radeon Mobility M9 Le (AGP)
ATI Radeon Mobility M9 Lf (AGP)
ATI Radeon Mobility M9 Lg (AGP)
ATI Radeon 9000 IGP (A5) 5834
ATI Radeon Mobility 9000 IGP (U3) 5835
ATI Radeon 9200 5960 (AGP)
ATI Radeon 9200 5961 (AGP)
ATI Radeon 9200 5962 (AGP)
ATI Radeon 9200 5963 (AGP)
ATI Radeon 9200 5964 (AGP)
ATI Radeon M9+ 5968 (AGP)
ATI Radeon M9+ 5969 (AGP)
ATI Radeon M9+ 596A (AGP)
ATI Radeon M9+ 596B (AGP)
ATI Radeon 9500 AD (AGP)
ATI Radeon 9500 AE (AGP)
ATI Radeon 9500 AF (AGP)
ATI FireGL Z1/X1 AG (AGP)
ATI Radeon 9700 Pro ND (AGP)
ATI Radeon 9700/9500Pro NE (AGP)
ATI Radeon 9700 NF (AGP)
ATI FireGL X1 NG (AGP)
ATI Radeon 9600 AP (AGP)
ATI Radeon 9600 Pro AR (AGP)
ATI Radeon Mobility M10 NP (AGP)
ATI FireGL (R350) AK (AGP)
ATI Radeon 9800 NH (AGP)
ATI FireGL (R350) NK (AGP)
If someone has an ATI Radeon or FireGL card which is not on this
list, it is currently not supported by the driver. Run "lspci"
and look and see if it lists the card by name, or if it says
"unknown" or similar. If lspci doesn't know what the card is,
even if it isn't on the above list, please file a bug report in
bugzilla, and include full details of the video card, and also
manually choose any Radeon video card from the list of hardware
in redhat-config-xfree86 and test the card out with X. Report
any problems found in your bugzilla bug report.
I plan on improving our 4.3.0 radeon driver to support any new
cards that come out whenever I have the information I need to do
the work, and have some spare weekend-hacker time to do the
necessary volunteer work.
Currently the XT/SE cards wont work I don't think, however you
can probably trick them into working by using the "ChipID" config
file directive in the config file to lie to the driver about what
card you have. "man XF86Config" documents this option and how to
use it. ie:
ChipId "0x4150"
That line would probably allow a Radeon 9600 SE/XT/whatever to
work by faking that it is a "Radeon 9600 AP". You can get the
various PCI ID numbers for various supported cards from:
/usr/share/hwdata/pcitable
So, if your card is not autodetected by our config tool and/or
not autodetected by the video driver, please report a bug report
or request for enhancement in bugzilla, so that I at least know
about the missing hardware support and might be able to add
support for it when I have spare time, for future XFree86 4.3.0
update releases. I can't guarantee any kind of speedy resolution
of course, but it'd be nice to have a list of various cards in
bugzilla that need work, so that when I do have the time to hack
on it, I can add them all at once. ;o)
Nvidia support status:
The "nv" driver in 4.3.0 supports the majority of Nvidia hardware
that existed in February 2003, plus it has code to support
similar hardware that Nvidia planned on shipping later than that,
but which the driver will claim is "unknown Nvidia blah blah" and
try to drive it nonethless. The "nv" driver *only* supports CRT
displays officially, flat panel display types are not officially
supported, but the driver has experimental support which might or
might not work depending on the exact brand/make/model/phase of
the moon, etc. It is also possible that there are newer Nvidia
boards that aren't supported or just don't work at all for one
reason or another.
User's experiencing problems with the "nv" driver, be they
general bugs, or lack of support for their particular card,
should also file bug reports in Red Hat bugzilla, however they
should also file them in XFree86 bugzilla as Nvidia doesn't
release their specifications nor any detailed information on how
their hardware works, so adding support for new chips is nowhere
near as simple as doing it for the Radeon driver. All Nvidia
"nv" driver related bug reports if filed in Red Hat bugzilla,
should also be filed at: http://bugs.xfree86.org including
complete details of any problems, and having config file and log
file attachments.
Where possible, I will try to also update the Nvidia "nv" driver
to support newer Nvidia hardware as volunteer time permits.
NOTE: This is STRICTLY for the Red Hat/XFree86 supplied "nv"
driver. DO NOT file bug reports about using the proprietary
Nvidia video drivers, as we do not support those drivers at all.
Any problems experienced while using the Nvidia proprietary
drivers should be reported to Nvidia directly and discussed on
their end user web support forums (don't have the URL handy) as
this is Nvidia Inc.'s preferred mechanism for handling problems
in their drivers. If a user is using both the proprietary and
the "nv" driver on their system and having problems with the "nv"
driver, before reporting problems, disable the proprietary driver
and it's kernel module completely, then do a full system reboot
in order to reset the video hardware to it's default power on
state, as the different drivers can and do program the Nvidia
hardware a bit differently and this can cause the 'nv' driver to
fail once the proprietary driver has been used since boot time.
Final comments:
I must ask politely that people please do NOT email me personally
for help configuring their hardware or solving X configuration
problems, etc. I generally get 20-50 or more email requests for
special help from people when I send an email like this out, and
unfortunately, I really truely do not have time to help that many
people out individually.
Any email based tech support or discussion of any problems should
take place on xfree86-list(a)redhat.com, or
fedora-devel-list(a)redhat.com, or even xfree86(a)xfree86.org, so
that numerous developers and other people can possibly assist
with a given problem someone is experiencing. Any generic
questions about future X support or development should also be
directed to one of those mailing lists, or dri-devel on
sourceforge, rather than directly to me.
Bug reports and RFEs should be filed at:
http://bugzilla.redhat.com
http://bugs.xfree86.org
While this email is rather lengthy, if I've missed anything and
someone decides to respond, please respond on the mailing list
that you received this email from and do not reply directly to me
privately. I'll probably reply to any discussions on our mailing
lists that crop up from this mail, but probably ignore all
private replies. ;o)
Thanks in advance for testing out this new hardware support, and
for contributing bug reports and enhancement requests so that we
can hopefully end up being able to support the latest video
hardware for y'all. ;o)
Enjoy.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
20 years, 6 months
Repository feature proposal
by Peter Backlund
Hi.
I've been thinking a bit of how to make it easier for people to use
repositories as opposed to downloading single pieces of software from
the web. Normally, if you come from another operating system, you're
used to going to a website, downloading a single installation program,
installing it and you're done.
So let's say some project or even some company wants to distribute
software for Linux (Fedora to be specific). The best way would of course
be if they set up a repository with their stuff, since downloading,
installation _and_ automatic update checking can be performed within a
single application (apt/yum/up2date).
>From an (inexperienced) end user perspective, it's not really practical
to edit some file in a text editor. It's the weak link in the gui chain.
Now, my idea is to create some sort of file format describing the
repository, that can be "imported" by the software management program
(up2date/r-c-packages). That way, you can publish one such repository
description file on your website, that users download an import (or even
open directly from in the browser), and then all your software can be
accessed from the same management tool. Perhaps one could create
"repository rpms", similar to how public GPG keys are imported and
stored in the rpm db?
Advantages over even the Windows(r)(tm)(c) way are:
- Automatic update checking.
- Consistent installation (and removal) procedure across all
applications.
An example of how another distribution handles 3:rd party repositories
can be found at
http://plf.zarb.org/~nanardon/
It boils down to "paste these commands in a root terminal". This is a
very small step up from the traditional "put this in your source.list".
So, what do you all think about this?
/Peter
20 years, 6 months
new release of mach
by Thomas Vander Stichele
Hey people,
With the new severn beta 3 out, I updated mach to work for this one as
well. If someone could try it with fedora core 0.95 *as the host*, let
me know how it works out.
Release notes attached.
Thomas
Dave/Dina : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
They say if you love somebody
you have got to set them free
but I would rather be locked to you
than living in this pain and misery
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/
20 years, 6 months