I have tryed to upgrade from FC4 -> FC5 using anaconda but it did not
detect my FC4 installation which is installed on /dev/md0.
It tryes to add a non raid partition to the array and ignores the raid
partition. This causes the initalisation of md0 to fail.
Is this a kernel or anaconda bug?
(no reply ...)
So I backuped my data dan tryed a reinstall and it detected the md0
array in diskdruid but showed "foreign" as filesystem..
did edit and set mount point to / and filesystem ext3
but it failed formating it with a messages saying that it failed and
that I should press enter to reboot the system.
What happend? How could such things happen with a *final* release? Raid
support seems broken and nobody has noticed.
I always updated my system from RH9->FC1->FC2->FC3->FC4 (then
reinstalled FC4 because of i386->x86_64) but it seems that upgrade is no
more possible to FC5 :(
Le Lun 27 mars 2006 22:39, sean a écrit :
> No matter what you come up with though, it will be many years before
> you see wide spread adoption. If anything, you might consider a
> project to create a system-wide config editor that knows all
> the different formats etc and provides a consistent CLI/GUI
Yay, return of the linuxconf
It will break for the same reason that linuxconf failed - even a GUI needs
some config file consistency to work. It will fail like the current
printer setup fails. If you want it to work conf syntax and GUI/CLI tools
must be carefuly thought of and aligned, or you'll only produce brittle
GUI tools which eat conf files at the first opportunity.
*If* a core set of apps could be moved to a modern consistent format then
one could try to evangelize it later. This is something the gconf people
botched big time by focusing on the GUI and generating files no one could
sanely modify in a text editor (and no xml is not the reason. Serializing
stuff without thinking is the reason. Abusing human-unfriendly UUIDs is
My suggesting if you want this to happen is :
1. create a new gconf backend with files people can actually change in vi
2. once you've proved you've a solid candidate both GUI and CLi cand work
with, try to sell it to everyone else
But if you're not able to switch gnome (which has a single point of entry
- gconf) you've got zip chances to get rid of the others legacy formats
Dear Linux hackers,
As you may be aware, we, the Computer Science
Linux User's Group, are attempting to make our own
re-branded distribution of Linux based on Fedora Core
This distribution is aimed at having a customised
set of packages that we need in our BCS/MCS/BE/ME/MCA/Diploma
syllabus so that one set of three or four CDs can be
moved around without carring peripheral CDs for Java,
plugins, multimedia, etc.
Moreover, we were mailed regularly by people that
they had trouble setting up Postgres, PHP, tomcat,
Perl, JDBC, etc. during their time of critical needs.
It is definately not fair to expect people to learn
how to configure these things at the last moment when
practicals are declared within a week.
Even if someone is capable of configuring these,
it is likely that they may forget at the last moment
and also likely that people wont want to spend time
configuring stuff on the day previous to the exam at
the cost of studying.
For this purpose, we also aim to provide
pre-configured RPMs and configuration scripts that can
achieve this task within a few minutes. In fact,
CSLinux version 1 released last year allowed even
first year students to set up many things that TYs
were having trouble with.
This version will be aimed at pushing this
simplicity and ease-of-use to the next level. With
GUIs, web-based tools for remote management of nodes
in labs, configuration replication scripts for
applying common settings to multiple laboratory nodes,
user management scripts for handling the thousads of
users on college servers, etc.
For more information on what's been going on in
regard to CSLinux, you are encouraged to join the
and go through the archives
. We have also started a Wiki
for simplifying this effort and the
link to it can be found in he CSLUG archives.
We request your participation, support and
encouragement in this effort. Please do spread the
We need all sorts of people to help us out. We
need graphics designers to design the themes, logos,
images, wallpapers, bootscreens, etc. for CSLinux. We
require people to modify the installer Anaconda. We
need people to modify RPM files and change the default
configuration in them. We need people to make and
build binary RPMs out of source tarballs for packages
whose RPMs that may not already be available or when
i686 RPMs may not be available.
We also need developers to develop the
configuration scripts, the small tools that we will
provide with CSLinux and changing initscripts.
Finally and most importantly, we also require the
BCS/MCS/BE/ME/MCA/Diploma community to contribute their academic
projects to be put up on CSLinux. This is to encourage
students to make professional-grade real-life
applicable projects by providing them a large exposure
within the peer community.
Also, we need people to search for sponsors. For
example, we may approach coaching classes to sponsor
the project in return for putting up their ads/banners
on our default wallpaper, the GNOME/KDE splash
screens, the default gdm login logo, and the CD covers
and the prints on the CD themselves.
Absolutely any help will be appreciated a lot. We
would like CSLinux to become a living example of an
open source project that is self-sustaining, started
off by students on their own, and a successful
business model within Pune (although it will be
If you feel that you have completed any
assignment from BCS/MCS/BE/ME/MCA/Diploma to perfection and would like
the community to see it, then we will also be
including such assignments for reference on the
distribution. This is a very highly-demanded feature
Your contribution on recommendations to what
tools, packages and documents that should be included
in CSL would be highly appreciated.
We thank you for all your support in this
For more information you may contact the following:
Amit Karpe: amitkarpe(a)vsnl.net, 9226745408
Archis Gore: archisgore(a)yahoo.com, 9371058022
It would be preferred if you could post your
suggesstions, ideas and contributions onto the list.
The CSL Team
P.S. Please forward this mail to as many mailing lists
and people that may be interested.
param vaibhavam netum etat swaraashtram
samrthaa bhavatwaashishaa tebhrusham
|| Bharat Maata Ki Jay ||
On Tue, 2006-03-28 at 05:24 -0500, sean wrote:
> On Tue, 28 Mar 2006 04:50:52 -0500
> "Eric S. Raymond" <esr(a)thyrsus.com> wrote:
> > 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.
> Hmmm, well that's interesting. So it should be possible to include
> an open source mp3 decoder like Underbit's MAD. 
Unfortunately, this info is about 5 years out of date. Fraunhofer
licensed the rights to Thomson Multimedia, who then made a big fuss
about players. They have a published rate of $0.75US per unit for mp3
decoding software, which would have to be paid by whoever distributes
Obviously this model is incompatible with Fedora Core and Extras.
On 3/28/06, Eric S. Raymond <esr(a)thyrsus.com> wrote:
> I'd be willing. But this really needs to be done by a lawyer.
Yes indeed it does which makes the fact that you have brought this
up.. on a list dedicated to discussing technical issues particularly
bemusing. So are you comments about it seeming to be reasonable path
for RedHat contrary to the current policy stance RedHat has taken.
How exactly do we as laypeople even begin to discuss with you the
feasibility of this idea ... if you don't even know what the terms of
the license being offered are? While a lawyer's review will be needed
before a serious effort at implementation can be done. Certaintly
knowing with specificity the exact language of the offered terms from
the patent holder can only help produce informed discussion. I fully
expect there to be conditions which will broadly be understood as
problematic to solve some of the issues you have with how things are
If you think there is a shred of hope for community members to have an
option to buy in towards a "pay up" for an open source project that is
actually worth buying into.. please be so kind as to do the necessary
inquiries with the patent holder about the available license terms and
conditions before making that suggestion public. Right now you are
taking about a 3 million mile view on the issue.. and everything that
matters in this discussion are details in the licensing terms, which
you don't know. Please refrain from speculation until you are in a
position to at least state clearly what the offered terms and
conditions are. We can't even have a well intentioned layperson
discussion as to what is or is not allowed without specific terms.
However I think its a waste of everyones valuable time to discuss the
pros and cons of implementation details like "pointing yum to a 3rd
party location by default" until you can present us with the terms of
the licensing that is being offered and there is informed opinion
about what is allow,what is not allow, and what is uncertaintly
allowed by the language of the terms that you are suggesting the
community spend resources in securing.
Tcl is designed as an embeddable scripting language, and it's simple
and easy to use. I've seen it embedded in several network
infrastructure devices. Perl ... emm... yech (just an opinion --
please don't flame me). If you use Java, BeanShell is nice. Also check
Ruby. I don't know anything about it yet, but is supposed to be the
best thing since sliced pan if you believe its advocates.
On 3/28/06, Kenneth Porter <shiva(a)sewingwitch.com> wrote:
> I've been thinking about incorporating either Perl or Tcl as my scripting
> language. Any other choices I should consider?
I have a couple of VT310-DP boards (together in a little 1U case,
nice) and found that FC-5 won't do SMP on them. (The i686 kernels
won't run on this chip.)
What's the cleanest way to add an i586-smp (or better yet, MVIAC3_2-smp)
build target to the existing kernel SRPM? Currently I'm working from
Fedora CVS (FC-5 branch) which looks like it has reorganized the
config generation a bit.
On Tue, 2006-03-28 at 13:04 -0500, sean wrote:
> On Tue, 28 Mar 2006 13:00:10 -0500
> Alan Cox <alan(a)redhat.com> wrote:
> > What would be useful (free or nonfree) is an xml/yum-repository type format
> > that could be hooked into firefox and friends so you can
> > "Click here to subscribe to fetchmail-pro"
> Already possible. Repository maintainer publishes a link on their
> website to a rpm that installs a repo file. Click on the link,
> click "Install RPM" when prompted and Bob's your uncle.
I just tried this. I clicked on the freshrpms-release RPM in Galeon, it
just prompts me to save it. However once saved, opening it in Nautilus
starts up system-install-packages and allows me to install it. Neat.
Nice to see this functionality return. Now if you could get it to go
direct from the browser to installing packages, you'd really have
something. (A vector for malware if you're not careful. Check those GPG
Le mardi 28 mars 2006 à 04:09 -0500, sean a écrit :
> As for XML, with a proper API there's no reason to worry much about the
> format of the configuration data files. The applications would never
> look directly inside any config file anyway.
That's what gconf authors obviously thought and look where it got them.
Thinking about file format may be a PITA, but if you skim on it you
won't ever have widespread adoption.
> "Additionally, patent holders declined to enforce license fees on
> open source decoders, allowing many free MP3 decoders to develop."
Yes, that's one of the statements I *did* find.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>