I would be glad, if the really brave could compile, install and test:
Beware this could end in a non-bootable system.
This version removes the hardware initializing/module loading phase from rc.sysinit. Udev should do most, if
not all job. I am interested in any missing modules, that were loaded before.
Thx for testing.
Hi all, just writing to say that on my Dell Inspiron 8000 laptop (latest
BIOS) with ATI Mobility M4 video the modular X vesa and r128 drivers do not
work properly. When X is configured to use the vesa driver it comes up, but
the picture is distorted (looks like 2 vertical desktops overlapping one
another at various points, also colors are messed up). As for trying to use
the r128 driver, X cannot even load when configured this way, it fails with
an error along the lines of the r128_drv.so could not be opened. Has anyone
else seen issues like this with the new modular X packages? Should I file
bugs for these in x.org <http://x.org>'s bugzilla? Thanks.
I just replaced with my laptop's OLD but working RHL73 with FC4.
Let me state a strong disappointment over acpid default config.
What "default config" ? Exactly, there is none (the sample config for
power button does not count).
I was stunned how FC could be making ACPI default while completely
ignoring adding any default configs for the users (e.g., starting from
something like http://www.thinkwiki.org/wiki/How_to_configure_acpid) ?
Looking at CVS, this problem doesn't seem to have been addressed in
FC5. I (or I'm sure a lot of other folks) could submit a patch for
starters if that'd be the problem.
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
B/c of the rapidly evolving nature of the gcj and related java tools,
what if we moved them to extras so that work on those packages could be
both public and move faster?
It would be a big savings on the size of core and it seems like adding
those packages over there would be the most correct as the java packages
don't really have any necessary reason to be in core.
What do you think?
Just wondering, I assume that FF 1.5 RPMs will be making their way into
rawhide in the next couple of days.
What are the chances of building their SRPMs on FC4? (x86-64 to be
Should I just give up and build the vanilla source package?
So, I noticed while doing my first FC5t1 install the upgrades aren't
currently supported in the reworked anaconda. Fair enough; there's a lot of
changes under the hood. But that got me thinking: hey, maybe this is a great
time to get it so that "yum upgrade" can actually easily bring one from one
FC release to the next. (More realistically, maybe FC6 is a great time. But
now might be a time to start thinking about it.)
I know there's historically been a lot of wacky special-casing in Anaconda,
much of it legacy cruft, and much of it kinda important for, y'know,
actually working upgrades.
With switching to a yum-based backend, I imagine that much of this cruft
must be updated. Maybe Jeremy's doing it this way already, but what about
packaging that special-case knowledge into a "distroupgrade" yum plugin
instead of into Anaconda itself, wherever possible? (Some things are easier
done off-line, of course, but maybe those could be made to happen in
firstboot or so?)
As an experiment in support of this hallucinogen-addled fantasy, I installed
a fresh system FC4 system (Workstation install), used yum to apply all
current updates, and then changed the repo config to point at FC5t1. I first
ran yum upgrade yum and then a full "yum -y upgrade".
After some time, this failed, because iiimf-libs is gone, with no
replacement or nothing to obsolete it but with a chain of dependencies.
Quick fix was to just remove that package and try again.
Now, two things -- initscript and kudzu -- failed because of requirements on
kernel < 2.6.12 and 2.6.13, respectively. After some head-scratching, this
turned out to be caused by Conflicts statements and the previously-installed
2.6.11 kernel. (The newly installed-then-yum-upgraded system had the
original FC4 2.6.11 and the newest FC4 2.6.14 both installed, of course.)
Sort ironically, the installonlyn plugin would have actually corrected this
situation, because the result after the upgrade would be to have the FC4
2.6.14 plus the FC5 2.6.14. Anyway, I worked around this by simply removing
the old 2.6.11 kernel.
After that, the yum upgrade went basically fine, and after Some Time passed,
I have what appears to be a fully functional FC5 system. I haven't poked
around too much to find broken spots, and there were a lot of messages about
.rpmsave and .rpmnew, so looking at those is probably in order. But I can
log in to Gnome, browse the web, run OpenOffice, and so on.
But overall, seemed like a pretty successful experiment. And, given the
super-short lifespan of FC releases, something I'd really be interested in
having as an option.
-- smokin' the good stuff,
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Is there any work being done for a modern update system that would only
download what is needed instead of an entirely new rpm? I'm sure everyone
has seen the updaet system that Firefox has. It's beautiful. How is that
going to work on Fedora Core 5? Is it disabled? Eitherway, such an update
system on Linux would be a watershed moment perhaps. A grand slam. It is a
bit ridiculous that FC4 updates have possibly mounted up to 10 GB for me..
maybe an exaggeration but you know what I'm getting at.
So any such project out there?
Here in swiss we are using fr_CH keyboards. Each time we are installing a
FC4, firstboot runs in FR keyboard layout. So it's difficult to add user at
Here is a little patch to allow rhgb to run in fr_CH keyboard layout when
/etc/sysconfig/keyboard KEYTABLE key is set to fr_CH or fr_CH-latin1.
Why is the "check_for_language" function in main.c splitting by the key "_"?
POSEIDON Project Manager
EPFL - DIT - DIT-SB
Ecole Polytechnique Fédérale de Lausanne - EPFL
Tel: (+41) 021 693 2266