RE: Re: xorg from 1.0.1-9 to 1.0.1-9.fc5
by Gianluca Cecchi
On Thu, 13 Apr 2006 23:39:20 -0400 Matthew Miller <mattdm mattdm org> wrote:
> There's no real standard for how updates like this are numbered/labeled;
> "-9.1.fc5" might have been more clear.
> In any case, "9.fc5" sorts as higher than "9", so RPM knows it's a new
> version.
I think you are under estimating hard job of package mantainers...
There is also a wiki on this, but I didn't find it useful to
understand this "fc5" appended to an already fc5 previous package...:
http://www.fedoraproject.org/wiki/Packaging/NamingGuidelines?action=show&...
18 years
RE: rawhide report: 20060413 changes
by Gianluca Cecchi
On Thu, 13 Apr 2006 03:24:14 -0400 Build System <buildsys redhat com> wrote:
>python-2.4.3-2
>--------------
>* Wed Apr 12 2006 Jeremy Katz <katzj redhat com> - 2.4.3-2
>- rebuild with new gcc to fix #188649
>
>* Thu Apr 06 2006 Mihai Ibanescu <misa redhat com> - 2.4.3-1
>- Updated to 2.4.3
>
>* Fri Feb 10 2006 Jesse Keating <jkeating redhat com> - 2.4.2-3.2.1
>- bump again for double-long bug on ppc(64)
In general is it supposed that minor version upgrades like this, from
2.4.2 to 2.4.3
for python, converge after some days to official fc5 too?
In this particular case I'm interested on testing plone 2.5 beta 1
with Zope 2.9.2
http://plone.org/products/plone/releases/2.5
for furhter adoption of upcoming offical 2.5 release,
so that I'd prefer to stay with fc5, but eventually I can also shift
to fc5-devel....
Thanks in advance.
Bye,
Gianluca
18 years
When do we get a more usable printer dialog for GNOME?
by Gérard Milmeister
The current printer dialog of GNOME applications (is this
supplied by gnome-print?) is only usable for printer
that do not have any important settings (mostly PostScript
laser printers). Colour printers have many settings, most
importantly print quality and paper type. These are all
configurable via CUPS. But the GNOME print dialog only
shows some standard options. Of course the options can
be set globally using system-config-printer, which is
not acceptable for such a task, which is independent of
the system settings.
After all cups is standard in most Linux distrbutions
for quite a long time, a KDE *does* allow advanced
settings (even if the dialog is not very well done).
Are there plans by the Fedora Core development team to
change this?
Regards,
Gérard
--
Gérard Milmeister
Langackerstrasse 49
CH-8057 Zürich
18 years
s-c-printer GUI ?
by Richard Hally
what is the correct fix for the following?
todays update from rawhide:
> [root@LinuxNew2 headers]# yum update
> Loading "installonlyn" plugin
> Setting up Update Process
> Setting up repositories
> development [1/1]
> development 100% |=========================| 1.1 kB 00:00
> Reading repository metadata in from local files
> Excluding Packages in global exclude list
> Finished
> Resolving Dependencies
> --> Populating transaction set with selected packages. Please wait.
> ---> Downloading header for system-config-printer to pack into transaction set.
> system-config-printer-0.7 100% |=========================| 8.4 kB 00:00
> ---> Package system-config-printer.i386 0:0.7.4-1 set to be updated
> --> Running transaction check
> --> Processing Dependency: system-config-printer = 0.6.151.2-1 for package: system-config-printer-gui
> --> Finished Dependency Resolution
> Error: Missing Dependency: system-config-printer = 0.6.151.2-1 is needed by package system-config-printer-gui
thanks,
rh
18 years
question on kickstart globs/everything
by Jane Dogalt
Even though today's messages started out with "@everything has been argued to
death in the archives", it seems like the time for comments is still open-
I have been a heavy user of (@)everything, (@)minimal, and kickstart for many
years. Before throwing my opinions in the ring, I have one simple question-
Is the globs(*) for package selection in kickstart documented anywhere (yet)?
My question is, is that going to be as sufficiently smart as the
old/current-but-deprecated @everything, as far as silently dropping those
packages that have exclusional anti-dependencies? (picking the 'preferred
default')
Even if so (which I could just check by doing an install), I would throw in my
opinion as being precisely one of those users that would like to do a
non-kickstart everything install, just to have all the available core (on
media) packages installed, including a hundred languages I would never use.
Because yes, disk space is cheap. Not because I was worried about
dependencies. I.e. I was using what the rh/fedora core decision makers decided
to decide what I wanted to install. Nothing new here, but FYI, another person
like that exists and appreciated the ability to do that (even in the
non-kickstart case). It was always fun to do an everything install, and then
just sit down in front of a fully populated gnome/redhat main menu and start
trying all the new toys, whose package names would never have even clued me in
as to what they do.
Now, on to @minimal (dunno if that still exists). I used to generate livecd's
from mandrake back when their @minimal yielded ~300MB. I was building
appliance livecd's that even stripped some more files, getting it compressed
down to 135M (fits on a 3" cdr, with X+windowmaker+mozilla+xmms). So @minimal
was very useful for me, and as I'm now trying to do the same sorts of things
with fedora, I would hope it still exists, though have been psyching up for
having to more or less do lots of manual deinstallations as I figure out what
packages aren't _really_ necessary (which I had to do anyway with the mandrake
@minimal, to _really_ shave the install size down). Of course, now my target
is looking more like a 3" 1.8G dvd, but still... I liked @minimal. a lot. I
hope it lives.
-jdog
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
18 years
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
rawhide report: 20060413 changes
by Build System
Updated Packages:
gdm-1:2.14.1-4
--------------
* Wed Apr 12 2006 Ray Strode <rstrode(a)redhat.com> - 1:2.14.1-4
- fix libexecdir substitution problem in configuration file
kernel-2.6.16-1.2131_FC6
------------------------
* Wed Apr 12 2006 David Woodhouse <dwmw2(a)redhat.com>
- Add include/{mtd,rdma,keys} directories to kernel-devel package
* Tue Apr 11 2006 Dave Jones <davej(a)redhat.com>
- 2.6.17rc1-git4
perl-DBD-Pg-1.48-1.FC6
----------------------
* Wed Apr 12 2006 Jason Vas Dias <jvdias(a)redhat.com> - 1.48-1
- Upgrade to upstream version 1.48
perl-XML-Dumper-0.81-1.FC6
--------------------------
* Wed Apr 12 2006 Jason Vas Dias <jvdias(a)redhat.com> - 0.81-1
- upgrade to 0.81
pirut-1.0.2-1
-------------
* Wed Apr 12 2006 Jeremy Katz <katzj(a)redhat.com> - 1.0.2-1
- Fix traceback with no groups defined (#186545)
- Mark desktop files for translation (#188319)
- Catch mirror error (#184326)
- Change display name for package installer (#185169)
- Improve progress bar updating a little
- Require rhpl (#186796)
- Add status bar and progress for searching from James Bowes (#186977)
- Grab focus for search entry by default (#187597)
- Give better error message about no network (#188529)
python-2.4.3-2
--------------
* Wed Apr 12 2006 Jeremy Katz <katzj(a)redhat.com> - 2.4.3-2
- rebuild with new gcc to fix #188649
* Thu Apr 06 2006 Mihai Ibanescu <misa(a)redhat.com> - 2.4.3-1
- Updated to 2.4.3
* Fri Feb 10 2006 Jesse Keating <jkeating(a)redhat.com> - 2.4.2-3.2.1
- bump again for double-long bug on ppc(64)
rpm-4.4.2-18
------------
* Wed Apr 12 2006 Paul Nasrat <pnasrat(a)redhat.com> - 4.4.2-18
- Resurrect doxygen (#187714)
* Tue Apr 11 2006 Jeremy Katz <katzj(a)redhat.com> - 4.4.2-17
- remove redundant elfutils-libelf buildrequires
- rpm-python doesn't require elfutils (related to #188495)
system-config-printer-0.7.4-1
-----------------------------
* Wed Apr 12 2006 Tim Waugh <twaugh(a)redhat.com> 0.7.4-1
- Updated to system-config-printer-0.7.4.
* Fri Apr 07 2006 Tim Waugh <twaugh(a)redhat.com> 0.7.3-1
- Added threads patch from pycups CVS.
- Updated to system-config-printer-0.7.3.
* Tue Apr 04 2006 Tim Waugh <twaugh(a)redhat.com>
- Updated to pycups-1.9.6.
valgrind-1:3.1.1-2
------------------
* Wed Apr 12 2006 Jakub Jelinek <jakub(a)redhat.com> 3.1.1-2
- handle many syscalls that were unhandled before, especially on ppc
valgrind-callgrind-0.10.1-3
---------------------------
* Wed Apr 12 2006 Jakub Jelinek <jakub(a)redhat.com> 0.10.1-3
- build also on ppc
xorg-x11-server-1.0.99.901-4
----------------------------
* Wed Apr 12 2006 Kristian Høgsberg <krh(a)redhat.com> 1.0.99.901-4
- Bump for rawhide build.
* Wed Apr 12 2006 Kristian Høgsberg <krh(a)redhat.com> 1.0.99.901-3
- Add xorg-x11-server-1.0.99.901-cow-fix.patch to fix crash when
releasing the COW.
* Tue Apr 11 2006 Kristian Høgsberg <krh(a)redhat.com> 1.0.99.901-2
- Bump for fc5 build.
Broken deps for i386
----------------------------------------------------------
GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5
GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5
GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp
GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5
GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5
GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5
GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU
cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5
cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5
cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp
cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5
cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5
cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5
cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU
dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5
dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5
dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp
dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5
dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5
dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5
dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU
gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5
gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5
gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp
gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5
gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5
gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5
gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU
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.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5
GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5
GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5
GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5
GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU
cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5
cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5
cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5
cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5
cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU
dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5
dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5
dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5
dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5
dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU
gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5
gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5
gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5
gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5
gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU
18 years
This is a development discussion list.
by Michael Favia
While i recognize that many subscribers may feel that their tangential
concerns and ideas are worthy of discussion on such a list i was under
the impression that this was a "just the facts" type of list that
concerned itself with the current actual development of the
distribution. I dont blame them for posting their issues here though
because they have no other official outlet for discussion.
This extra noise, though well intentioned, is making it difficult for me
(and i imagine many others) to justify the time necessary to weed out
the "philosophical type" posts. And while i frown on the creation of yet
another fedora list, perhaps the creation of a "sounder" style list
would allow the discussion on the list to revert to a more focused
state? I do think that the philosophical discussions are beneficial to
the evolution of fedora as a distribution i just dont think that it
relates to the actual development concerns any more then desktop or docs
do (i.e. they have lists).
Maybe im the only one with these issues but i have been considering
unsubscribing from the list as a result of shear number of the OT
discussions and wanted to know if others felt the same. So, any votes
for a "fedora-socrates" list :)?
--
Michael Favia michael.favia(a)insitesinc.com
Insites Incorporated http://michael.insitesinc.com
18 years
GCC optimization bug (was python memory usage)
by Shahms King
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jakub,
I see that bug #188649 is fixed in rawhide. I just ran my test case and
it is, indeed, fixed. Can this updated gcc and recompiled (possibly
updated to 2.4.3) be pushed to updates-testing soon? I don't know how
many other packages or people are affected by the bug, but it causes a
pretty serious memory problem for python (bug #188327) and it would be
nice to get this fixed.
- --
Shahms E. King <shahms(a)shahms.com>
Multnomah ESD
Public Key:
http://shahms.mesd.k12.or.us/~sking/shahms.asc
Fingerprint:
1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEPS3r/qs2NkWy11sRAlLtAJ9oQVvN8Ul9vwqANjoAdj3e/2vZOQCdEuRe
Ee6eIn3OEMJndQEUuXRoYDc=
=ofrh
-----END PGP SIGNATURE-----
18 years