Hardware detection problems on laptops -- how to file a report?
by Joe Desbonnet
Am I right in saying there has been substantial changes to the way in
which hardware detected works in FC5? (I see from the release notes
PCMCIA handling has changed and kudzu has been deprecated). I have
prepared a report of my (not good) experience with a Thinkpad T41p,
but right now there is very little hard data in there which can be
used for debugging.
Any advice how to file a useful report about hardware that did work
with FC4 and does not work with FC5?
Also: I was thinking about the testing of the install install process
prior to the final release. Since many people cannot afford the space
to have a spare partition for test releases (especially on laptops)
and it is not possible to install to a USB drive, it would be useful
to have some sort bootable live-CD with just enough software to test
the hardware detection. Eg something like the Windows Device Explorer
program. If I had something like that during the test phase I would
have caught all these problems a long time ago. (I did all my testing
in a virtual VMWare environment -- and it works great there!).
Joe.
18 years, 2 months
FC5 weird raid issues
by dragoran
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?
Bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186312
(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 :(
18 years, 2 months
Re: The Strengths and Weakness of Fedora/RHEL OS management
by Nicolas Mailhot
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
> interface.
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
the reason)
My suggesting if you want this to happen is :
1. create a new gconf backend with files people can actually change in vi
of emacs
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
--
Nicolas Mailhot
18 years, 2 months
Call for Developers for the CSLinux project
by Amit Karpe
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
5.
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
CSLUG group
http://groups.yahoo.com/group/cslug
and go through the archives
http://groups.yahoo.com/group/cslug/message
. We have also started a Wiki
seedwiki.com/wiki/computer_science_linux_users_group/
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
word around.
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
strictly not-for-profit).
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
by many.
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
matter.
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.
Thank you,
Yours sincerely,
The CSL Team
P.S. Please forward this mail to as many mailing lists
and people that may be interested.
E-mail: archisgore(a)yahoo.com
Homepage: http://www.geocities.com/archisgore
--
Amit.
______________________________________________________
param vaibhavam netum etat swaraashtram
samrthaa bhavatwaashishaa tebhrusham
|| Bharat Maata Ki Jay ||
18 years, 2 months
Re: Fedora's way forward
by Peter Jones
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. [1]
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
the software.
Obviously this model is incompatible with Fedora Core and Extras.
--
Peter
18 years, 2 months
Fedora's way forward
by Jef Spaleta
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
done now.
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.
-jef
18 years, 2 months
Re: GUI controls for instrumentation
by Joe Desbonnet
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.
Joe.
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?
18 years, 2 months
Kernel for SMP VIA C3 machines
by Jason L Tibbitts III
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.
- J<
18 years, 2 months
Re: Fedora's way forward
by Callum Lerwick
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
sigs...)
18 years, 2 months
Re: The Strengths and Weakness of Fedora/RHEL OS management
by Nicolas Mailhot
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.
--
Nicolas Mailhot
18 years, 2 months
