re: speed up Firefox start by a factor of 3 on x86
by Gianluca Cecchi
On Thu, 16 Mar 2006 17:35:03 -0800 John Reiser wrote:
>In contrast, Firefox always starts in 5 seconds or less on a kernel
which places
>the vDSO intelligently:
I read the long list of your reports at the bugzilla page, with the
many details and test cases provided, but apart the beginning, you
pratically received no feedback at all (at least inside bugzilla
itself): only periodically that "having merged with upstream kernel,
more than thousands of changes, so please test again and let know..."
I think you had better to submit your considerations to upstream kernel list.
In this way if accepted, they would be naturally incorporated also in fedora.
I'm not a kernel expert so sorry if this doesn't fit for you.
Juest my 0.02 euros...
18 years, 1 month
Fedora's way forward
by Eric S. Raymond
I've had a few days now to get through the expected upgrade teething
troubles, use FC5 for my normal tasks, and watch my non-techie wife
Cathy use FC5 for *her* normal tasks. I've been a Red Hat/Fedora user
and contributor for more than a decade now, since before 2.0 and
*well* before I became famous enough to show up in Red Hat's corporate
timeline :-). I've taken some time to reflect on FC5 and the trends
of the last decade, and where I think Fedora and Red Hat need to go in
the future to achieve the dreams they were founded on.
Let me start with some good things. I thought Fedora was in
desperately bad shape in the FC3/FC4 period, and as some of you know I
raised hell about it, threatening to jump very publicly to another
distribution and orphan several Fedora-related HOWTOs in the process.
I'm delighted to be able to report that much of what pushed me very
near to giving up on Fedora has been fixed.
Good thing the first: Maintainence of the core repositories is no
longer a disgraceful, poorly-documented shambles. Because of this, yum
is at last fulfilling the promise of (almost) friction-free upgrading
over the net. Such problems as I've encountered with FC5 upgrades
have been due to upstream bugs, not egregious fuckups in the Fedora
infrastructure. This had...ahem...not previously always been the case.
Good thing the second: this time around, I can ignore RPMForge. While
those guys have done excellent work and performed a valuable function
by keeping Fedora on its toes, one of the things I really, *really*
wanted as a sysadmin was to be able to point my yum at official Fedora
repos plus one (1) repo for Damned Things like proprietary codecs, and
be done. In FC5, core plus extras plus livna does as good a job as
core plus half-a-dozen RPMForge repos used to.
Good thing the third: it's clear from the devel-list traffic that the
submission pathway for new packages has got most if not all of the
process issues shaken out of it. I had meant to get more directly
involved in that, there are four or five things I want to package and
submit myself, but higher-priority tasks ate my bandwidth. One of my
resolutions for 2006 is to make time for those submissions.
Good thing the fourth: A combination of increased polish in various
distro components and significant upstream developments (one biggie
being OpenOffice 2.0) has, to my observation, inched FC across an
important functional threshold. My wife can use it with as little
pain as Windows now, rather than merely tolerating the crap because
she believes in what the Linux community is trying to do. This is
significant, because she's *not a geek*; she's a lawyer. She is,
in fact, perfectly representative of the kind of forward-looking
professional in non-technology fields that we must have on our
side if we're to take Linux all the places we want it to go.
Take a moment to savor these good things. Because the news is by no
means all good. We've come a long, long way, baby -- but having got
past some of the serious blocking issues, we now get to face a new set
of them. And at least one old issue everyone has been ducking...
First, a relatively minor issue that is nevertheless quite annoying.
It's the Fedora distribution art, the images in Anaconda and the
Fedora-customized graphics in the admin tools and elsewhere. It has
never been much better than mediocre, and in FC5 it hits a new low
with backgrounds that look like a Teletubby hocked loogies into a
dish full of soap scum. And whose bright idea, I have to wonder, was
it to abandon the attractive and recognizable Fedora icon for
something that's...not a fedora?
Cripes. By comparison, even the original BlueCurve was superior. And
original BlueCurve wasn't much to cheer about compared to the
decorative art on a Windows or (especially) a Mac -- acceptable, but
not a competitive plus, not something that would actually attract
users. The FedoraBubbles stuff is bland and tacky goo that I expect
will repel them.
Now that we've gotten past some of the key blockers on the functional
level, it's time to worry more about fit-and-finish issues like these.
Mediocre art, workmanlike images that convey information without
being ugly, is good enough for a niche product aimed at techies. If
we want Fedora -- and for that matter Linux in general -- to break out
of that niche, we have to make it *look* like we want it to.
That means high-quality art, art that makes people actually *want* to
look at the screen because it's a significant aesthetic experience.
Which, right now, we ain't got.
But the art problem pales compared to the issue that everyone has been
ducking, which is Fedora's support for DVDs and proprietary audio and
video and web-streaming formats and Java applets. That is to say, its
crummy-to-nonexistent-to-actually-toxic support. The tools in FC5
weren't better than they were in FC3/FC4; after installing the
critical bits from livna, they were *worse*. Totem tossed its cookies
with a cryptic pop-up error; xine white-screened under one card and
actually crashed my X under another!
It's 2006, people. The Web is fifteen years old. Even non-techies
have had a decade to form expectations about what constitutes a base
level of functionality. We don't have a prayer -- not a hope, not a
snowball's chance in a supernova -- of becoming competitive for
home and business-desktop use without delivering to those
expectations.
Those expectations include, without any doubt, multimedia playback,
web streaming, and never seeing the broken-puzzle-piece icon in
Firefox more than once per media type (if that often). When those
expectations are violated, it's not the content provider who gets
blamed for shipping a proprietary format. The customer interprets
that kind of failure as a bug in the client, *and the customer is
right*. All the idealism in the world about Ogg and Theora and
whatnot will not change this.
Let's start with the basics. For a consumer OS to be unable to play
MP3s and handle podcasts is just plain not acceptable, not in the
world after iTunes. Red Hat/Fedora's duck-and-cover on this would be
understandable if the Fraunhofer patents blocked decoders, but
Fraunhofer itself has only dunned for royalties on *encoders* -- thus
Red Hat/Fedora has ceded to Fraunhofer rights it has never claimed.
I know at least one fairly influential kernel developer who threw out
Red Hat/Fedora in disgust over this. When he asked me straight up how
I could defend what he bluntly called 'corporate cowardice', I didn't
feel like I had a good answer. And I still don't. In return for all
the free development work they get, it does seem to me that it's part
of Red Hat's job to shoulder risks like these -- and that Red Hat
hasn't held up its end.
AVI. Quicktime. ASF. MPEG. DVD playback. Flash. Java. These are
*not optional* in 2006, any more than the ability to read Microsoft
Word files in a word processor is optional; if we try to treat them
that way, consumers will blow Linux off. Evangelizing for SVG and Ogg
and Theora may change this someday (I hope it will, anyway), but if
that transition were going to happen soon enough to make supporting
proprietary formats unnecessary *we'd already be past it now*.
So. For each format, we have one of three choices:
1. We can end-run the patent restrictions on the technology (say,
by developing outside the U.S. and distributing through overseas sites
that are wink-wink-nudge-nudge unconnected with Fedora/Red hat).
2. We can put real resources into developing a decoder implementation
the blocking patents don't cover, and accept the risk that the
patent-holders will launch harassment lawsuits anyway as a cost of
doing business.
3. We can buy the rights to the technologies we want as a straight
commercial transaction from the patent-holder.
The community is already pursuing (1) for some formats. If Red Hat,
which likes to see itself as the market leader and senior commercial
distributor, isn't willing to take a swing at (2) or (3) for the
others, then I have to wonder what the hell having commercial Linux
distributors is actually good for.
If solving the multimedia problem takes having Red Hat sell a
plugins-and-drivers disk for each spin of FC, full of proprietary crap
that it negotiated rights for, that sucks -- but better that than
never getting any traction on the desktop because we got too caught up
in our own idealism to meet actual consumer needs.
And if Red Hat's answer is "we don't want the desktop", then my answer
back is "shame on you for forgetting where you came from!", and it
really would be time for those of us who care about the future of Linux to
find a commercial partner with more ambition and more guts.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
"This country, with its institutions, belongs to the people who inhabit it.
Whenever they shall grow weary of the existing government, they can exercise
their constitutional right of amending it or their revolutionary right to
dismember it or overthrow it." -- Abraham Lincoln, 4 April 1861
18 years, 1 month
Vim-7 Preview
by Karsten Hopp
Hello,
I've prepared vim-7 prerelease packages, they are available from http://people.redhat.com/karsten/
Most prominent new features are gvim with windows in multiple tab pages (:help tabpage),
spell checking (:help spell) and omni-completion (:help new-omni-completion).
A description of the new features of vim-7 is available with :help version7
Please report any problems in bugzilla and make sure to mention the package version
Have fun...
Karsten
--
Learn. Network. Experience open source.
Red Hat Summit Nashville | May 30 - June 2, 2006
Learn more: http://www.redhat.com/promo/summit/
18 years, 1 month
Fedora Looks Fresh and Functions Well
by Benjy Grogan
Hello,
I'm really enjoying using FC5. Tomboy is a great tool for jotting
down ideas. I actually put together this email using a few tomboy
notes. I have a few suggestions -- that you can take or leave -- that
I wanted to share to help out with 'Fedora's way forward'. :) Here
they are:
1) A welcome to Fedora (or RHEL) tutorial for new accounts and even
maybe a tips section everytime you log in. DAC would be a really good
topic for new users.
2) Have a place in Preferences set up for the two or three available
Javas (Sun's and the OSS ones). Then when you have installed Sun's
Java you have a place to switch back to the old one, and vice versa.
(Question: Is a compiled Azureus the same if it's based on Sun or
GCJ?)
3) I have a question on codecs. Is it possible to get all OSS codecs
these days based on the GStreamer plugin system? I think the whole
audio/video codec problem would go away if there was a GStreamer Codec
management system where OSS codecs would be there by default and then
the user would go out and get all the proprietary GStreamer codecs
he/she is missing. It should be simple to look at a Fedora system,
and say "alright, got those ones, but missing these ones (like
mp3/avi). And I can figure out where to get them." And this
presupposes a future where there are only Gstreamer codecs.
4) Since Firefox is one of the most important pieces of the Linux OS
these days, it would be great to have all of the alphas, betas and RCs
available in update-testing. That would allow some users to test
Firefox for bugs over an extended period of time before 2.0 or 3.0
comes out. Obviously, under some guidance from Fedora with all the
patches they put into it.
5) An updating system (maybe using deltarpms or smartrpms) that could
compete with the updating system available on Windows XP and OS/X.
Smaller updates are really needed.
That's all! Back to testing out FC5. And Thanks!
Benjy
18 years, 1 month
rawhide report: 20060328 changes
by Build System
Updated Packages:
checkpolicy-1.30.1-2
--------------------
* Mon Mar 27 2006 Dan Walsh <dwalsh(a)redhat.com> - 1.30.1-2
- Rebuild with new libsepol
cups-1:1.2-0.2.rc1.1
--------------------
* Mon Mar 27 2006 Tim Waugh <twaugh(a)redhat.com> 1:1.2-0.2.rc1.1
- Ship a printers.conf file, and a client.conf file. That way, they get
their SELinux file contexts set correctly.
* Mon Mar 27 2006 Tim Waugh <twaugh(a)redhat.com> 1:1.2-0.2.rc1.0
- 1.2rc1.
fribidi-0.10.7-1
----------------
* Mon Mar 27 2006 Caolan McNamara <caolanm(a)redhat.com> 0.10.7-1
- latest version
g-wrap-1.9.6-3
--------------
* Mon Mar 27 2006 Bill Nottingham <notting(a)redhat.com> 1.9.6-3
- build against glib2
gnucash-1.9.3-1
---------------
* Mon Mar 27 2006 Bill Nottingham <notting(a)redhat.com> - 1.9.3-1
- update to 1.9.x
inn-2.4.3-1
-----------
* Mon Mar 27 2006 Martin Stransky <stransky(a)redhat.com> 2.4.3-1
- new upstream
iproute-2.6.16-1
----------------
* Sun Mar 26 2006 Radek Vokál <rvokal(a)redhat.com> - 2.6.16-1
- upgrade to 2.6.16-060323
- don't hardcode /usr/lib in tc (#186607)
kbd-1.12-14
-----------
* Mon Mar 27 2006 Miloslav Trmac <mitr(a)redhat.com> - 1.12-14
- Don't install resizecons.8 on non-x86 (#186877, patch by Keiichi Mori
<kmori(a)redhat.com>)
kernel-2.6.16-1.2097_FC6
------------------------
* Mon Mar 27 2006 Dave Jones <davej(a)redhat.com>
- 2.6.16-git13
* Sat Mar 25 2006 Dave Jones <davej(a)redhat.com>
- 2.6.16-git10
* Fri Mar 24 2006 Dave Jones <davej(a)redhat.com>
- 2.6.16-git9
liboil-0.3.8-2
--------------
* Mon Mar 27 2006 Ray Strode <rstrode(a)redhat.com> 0.3.8-2
- Update to 0.3.8 (bug 186930)
* Tue Mar 21 2006 Matthias Saou <http://freshrpms.net/> 0.3.7.1-1
- Update to today's CVS code which should fix the PPC build issue.
- Include new oil-bugreport tool in the devel package.
* Mon Mar 06 2006 Matthias Saou <http://freshrpms.net/> 0.3.7-3
- FC5 rebuild (well, try at least since PPC fixes are required).
libsepol-1.12.3-1
-----------------
* Mon Mar 27 2006 Dan Walsh <dwalsh(a)redhat.com> 1.12.3-1
- Upgrade to latest from NSA
* Fixed attr_convert_callback and expand_convert_type_set
typemap bug.
logwatch-7.3-1
--------------
* Mon Mar 27 2006 Ivana Varekova <varekova@ redhat.com> 7.3-1
- update to 7.3
- added samba, up2date
mod_authz_ldap-0.26-7
---------------------
* Mon Mar 27 2006 Joe Orton <jorton(a)redhat.com> 0.26-7
- don't package INSTALL
- define -DLDAP_DEPRECATED=1 in CPPFLAGS
mysql-5.0.18-4
--------------
* Mon Mar 27 2006 Tom Lane <tgl(a)redhat.com> 5.0.18-4
- Modify multilib header hack to not break non-RH arches, per bug #181335
- Remove logrotate script, per bug #180639.
- Add a new mysql-test RPM to carry the regression test files;
hack up test scripts as needed to make them run in /usr/share/mysql-test.
mysql-connector-odbc-3.51.12-2
------------------------------
* Mon Mar 27 2006 Tom Lane <tgl(a)redhat.com> 3.51.12-2
- Remove DLL-unload cleanup call from connection shutdown (bz#185343)
postgresql-8.1.3-2
------------------
* Mon Mar 27 2006 Tom Lane <tgl(a)redhat.com> 8.1.3-2
- Remove JDBC from this build; we will package it as separate SRPM
* Mon Feb 13 2006 Jesse Keating <jkeating(a)redhat.com> - 8.1.3-1.1
- rebump for build order issues during double-long bump
pykickstart-0.25-1
------------------
* Mon Mar 27 2006 Chris Lumens <clumens(a)redhat.com> 0.25-1
- Add support for the logging command.
* Mon Mar 27 2006 Chris Lumens <clumens(a)redhat.com> 0.24-1
- Don't write out a blank xconfig line.
- Reorder output handlers to group like commands together.
- Mark strings for translation.
selinux-policy-2.2.25-2
-----------------------
* Wed Mar 22 2006 Dan Walsh <dwalsh(a)redhat.com> 2.2.25-2
- Fix pam_console handling of usb_device
- dontaudit logwatch reading /mnt dir
* Fri Mar 17 2006 Dan Walsh <dwalsh(a)redhat.com> 2.2.24-1
- Update to upstream
* Wed Mar 15 2006 Dan Walsh <dwalsh(a)redhat.com> 2.2.23-19
- Get transition rules to create policy.20 at SystemHigh
spamassassin-3.1.1-1.fc6
------------------------
* Sat Mar 11 2006 Warren Togami <wtogami(a)redhat.com> - 3.1.1-1
- 3.1.1
* Fri Feb 10 2006 Jesse Keating <jkeating(a)redhat.com> - 3.1.0-5
- bump again for double-long bug on ppc(64)
* Tue Feb 07 2006 Jesse Keating <jkeating(a)redhat.com> - 3.1.0-5
- rebuilt for new gcc4.1 snapshot and glibc changes
system-config-kickstart-2.6.8-1
-------------------------------
* Mon Mar 27 2006 Chris Lumens <clumens(a)redhat.com> 2.6.8-1
- Fix loading kickstart files (#186944).
* Mon Mar 27 2006 Chris Lumens <clumens(a)redhat.com> 2.6.7-1
- Fix support for --generate (#186635).
tix-1:8.4.0-5
-------------
* Mon Mar 27 2006 David Cantrell <dcantrell(a)redhat.com> - 1:8.4.0-5
- Make sure libTix8.4.so is in /usr/lib/Tix8.4
unixODBC-2.2.11-7
-----------------
* Mon Mar 27 2006 Tom Lane <tgl(a)redhat.com> 2.2.11-7
- Fix minor problems in desktop files (bug #185764)
wpa_supplicant-1:0.4.8-6.fc6
----------------------------
* Mon Mar 27 2006 Dan Williams <dcbw(a)redhat.com> - 0.4.8-6
- Add patch to make orinoco happy with WEP keys
- Enable Prism54-specific driver
- Disable ipw-specific driver; ipw2x00 should be using WEXT instead
Broken deps for i386
----------------------------------------------------------
GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5
GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5
GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5
cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5
cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5
dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5
dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5
gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5
gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp
gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5
gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5
gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU
gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5
Broken deps for ia64
----------------------------------------------------------
rgmanager - 1.9.31-3.ia64 requires ccs
Broken deps for ppc64
----------------------------------------------------------
avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5
hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5
jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5
struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5
velocity - 1.4-3jpp_4fc.noarch requires servletapi5
xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5
Broken deps for s390
----------------------------------------------------------
avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5
hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5
jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0
rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1
rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1
struts - 1.2.8-2jpp_9fc.s390 requires servletapi5
struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5
velocity - 1.4-3jpp_4fc.noarch requires servletapi5
xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5
xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5
Broken deps for s390x
----------------------------------------------------------
avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5
castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5
geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5
hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5
jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5
jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16
rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit)
rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit)
rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit)
struts - 1.2.8-2jpp_9fc.s390x requires servletapi5
struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5
velocity - 1.4-3jpp_4fc.noarch requires servletapi5
xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5
Broken deps for x86_64
----------------------------------------------------------
GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5
gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5
18 years, 1 month
Re: Fedora's way forward
by Eric S. Raymond
sean <seanlkml(a)sympatico.ca>:
> Well, Fraunhofer has this page:
>
> http://www.iis.fraunhofer.de/amm/licensing/index.html
>
> Which links to :
>
> http://www.mp3licensing.com/
>
> Which definitely shows royalty fees for decoders.
It does. I stand corrected.
The page says $50K one time flat fee for a decoder. Is there any good
reason Red Hat shouldn't simply buy that license for some outfit with
a track record, like the lame developers? MP3 problem solved,
relatively cheaply (e.g., less than half the annual cost ofjust one
additional full-time coder).
Yes, I know feeding patent parasites is unpleasant. But we come back to
the central question here: do we want ideological purity at the expense of
victory, or do we want actual victory so that *we* get to effectively set
the terms of software development in the future?
I know which side of that question *I* come down on...
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
18 years, 1 month
rawhide->fc5; X won't start
by sean darcy
I was running rawhide updated to March 10. Went on vacation, yesterday
did a full upgrade to fc5. Used yum to get updates released. Now X
won't start. I think it's some sort of xfs problem.
with gnome, I get the fedora bubble logo, then a black screen, alt-f1
gets me the console, which shows:
waiting for X server to shut down FreeFontPath: FPE "unix/7100" refcount
is 2, should be 1, fixing
syslog shows:
gnome_segv2[3263]: segfault at 0000000000xxxxxxxx .........
kde also won't start. The console shows:
xset: bad font path element (#76), .......
and syslog shows kded, ksplash, kcminit, and ksmserver segfaulting.
I've restarted xfs ( no errors in syslog ). I've rebooted.
Do I need to do some mkfontdir voodoo in each font directory? What did
the upgrade change? I've seen no similar problems posted, so I assume
it's a rawhide->fc5 issue.
puzzled.
sean
sean
18 years, 1 month
[ANN] Release Notes Errata - Wiki Freeze
by Robert 'Bob' Jensen
Hello Docs, Devel and Marketing,
I would like to take a snapshot of the Release Notes Beats on the Wiki
to be used as an errata release for the web on Tuesday, April 4, 2006 at
23:59 UTC, we will clean up and push to translation on Thursday, April
6, 2006 giving translation a week to get as many languages available to
us over the following week.
One question I have for Development is can we then roll these new
updated release notes and translations in to a package update for our
users?
The web and maybe package errata would be available on Friday, April 15,
2006.
--
Robert 'Bob' Jensen <docs-list(a)fedoralinks.org>
Fedora Documentation Projects
18 years, 1 month
Where is the kernel source package for FC5 GA?
by Allyn, Mark A
Hello:
I am trying to build kernel modules on a standard install
of Fedora Core 5 GA. I did select the development block
of packages.
However there do not seem to be any kernel sources available
to build kernel modules.
I tried yum and did a yum look for kernel-source and it came
up with nothing.
Where do I get enough of the kernel source to do compiles
of kernel driver modules?
Thank you
Mark Allyn
18 years, 1 month
