Is there any plans to add a PowerPC build of Fedora?
I am a long time fan and user of Red Hat's Linux distribution. However,
recently I was forced to move away from Red Hat when I replaced my computer
with an Apple iBook.
I am very interested in contributing to the new Fedora project and am hoping
that this project will bring Red Hat to my iBook. I would like to help get
Fedora working on PowerPC-based architectures. Perhaps the folks at Terra
Soft Solutions would be interested as well?
Are there any like-minded folks out there?
I know you won't enable NTFS support, but...
If I supply a patch for the new NTFS driver, against Fedora's kernel,
can I get it applied?
Why? I maintain a set of NTFS driver rpms for various RedHat kernels.
I'd like to add support for Fedora, but I would prefer to use the *new*
By making a few small changes outside the /fs/ntfs directory, I can
create rpms containing the new NTFS driver.
IRC: #ntfs on irc.freenode.net
So here comes my impressions on my first date with this Core
* I decided not to install all packages, then I found that I
cannot select individual ones. So I tried adding packages from
the add/remove program. Then I selected my packages, and tried
to install them, when found that:
a) /dev/cdrom is pointed to /dev/hdc, this used to work
on previous Red Hats, but this time I had to calibrate it to
point to /dev/scd0.
b) Even after that, the add/remove program cannot find
the CD there, and keeps asking for CD. When I mount the CD, and
press Ok in the dialog, I find it unmounted..
c) I even couldn't copy/paste the list of selected
packages, so I wrote them down by hand, to feed them to up2date.
* Then I proceeded with up2date, to install some new packages.
Then I got the following weird error. Someone let me know if I'm
getting faked packages?
Testing package set / solving RPM inter-dependencies...
apel-10.6-1.noarch.rpm: ########################## Done.
The package apel-10.6-1 is not signed with a GPG signature.
Package apel-10.6-1 does not have a GPG signature.
* Bitstream-vera fonts are installed, but are not default. It
was really hard to read the other fonts, after two months with
vera fonts from Ximian. I took me a while to findout that they
are installed, and are available under name Bitstream Vera, not
* Many many places here and there, there are still Red Hat's,
that should be replaced by Fedora equivalents. One funny example
is the Login Screen chooser which has the thumbnail from Red Hat 9.
* Cool thing, DRI works!
* Nothing more yet.
Well, I reported a serious initscripts problem way back when Red
Hat 9 was released, but now I see that the same problem exists in
Fedora. Bill, would you clarify?
Here is the bug:
Actually, it's kinda disappointing...
The way this would work is that we need a volunteer to package gretl for
the Fedora Project (see http://fedora.redhat.com/). Red Hat Linux has
split into two descendants, the Fedora Project and Red Hat Enterprise
Linux (see http://fedora.redhat.com/about/rhel.html).
I'm forwarding your mail to the Fedora Project developer's mailing list
where potential package maintainers are likely to see it.
resending too ;)
>From: Nils Philippsen <nphilipp(a)redhat.com>
>Subject: Re: fedora only for US users ?
>Date: Sat, 27 Sep 2003 13:25:33 +0200
>[ resending without signature due to sutpid mailing list software ]
>On Sat, 2003-09-27 at 11:47, Nils Philippsen wrote:
> > On Sat, 2003-09-27 at 10:18, Cosmic Flo wrote:
> > > this message is a little hard but :
> > I wouldn't say it's hard, I would say these are bug reports. Consider
> > checking the various Bugzillas for these and submitting reports if
> > they're not in there already.
> > > - at first time wizard, keyboard configuration is US, not the selected
> > > language at install.
> > Bug. --> bugzilla.redhat.com
> > > - mozilla is only configured for US (language for web page,
> > > selected language at install have no importance.
> > Upstream bug I guess (is Mozilla multi-language aware? I don't see any
> > message catalogs...). --> bugzilla.mozilla.org
Here the .xpi for Mozilla 1.4 french language, for exemple :
Here the line for "language for web page" in
user_pref("intl.accept_languages", "fr, en-us, en");
Can't prefs.js with the good language value be added in /etc/skel ?
> > > - evolution's meteo is Boston US, I have selected an other city in
> > Upstream bug I guess. Evolution needs to differentiate locales in the
> > GConf schema files for the defaults. --> bugzilla.ximian.com
Working fine in Mdk.
> > > - the fedora.redhat.com web site (presentation, pages, documentation)
> > > only in English language, I have made some propositions to translate
> > > no translation project have started.
and ? Web site and documentations are very importants !
> > Nils
Trouvez l'âme soeur sur MSN Rencontres http://g.msn.fr/FR1000/9551
Le lun 29/09/2003 à 23:38, Seth Nickell a écrit :
> > It's nice but it won't fly with java daemons for example.
> > Java people do not care nor want to know about system stuff. You'll
> They do on "that other platform". Anyone who wants their code to be used
> either has to find somebody to do the "last mile" work for them
> (distributions currently)
Or community packaging projects:).
But I freely admit packaging java is a major pain - most upstream
developers have not got the faintest idea what a properly managed system
can look like (like they do not even know they have a problem).
Some java apps are really nice once packaged though.
> , or they have to do it themselves.
> distros got into this "last mile initscripts" business because their
> systems were different and incompatible, not because it was usually a
> good thing.
As someone that has written its share of last mile scripts I'd very much
like not to have to dump them now.
> > always need a shell wrapper to launch the jvm for example (well people
> > may use gcj one day but you get the point), change system users and so
> > on.
> Well, until we get dbus/shell bindings, you can't write shell scripts
> that aren't "legacy initscripts". But you can write tiny python
> wrappers, and probably perl in the not so distant future.
Well if one has to do python or perl you'll make it that more difficult
to package non-python or non-perl stuff. When the projects we work with
provide an unix layer it's always in shell (and most often in a very
primitive dialect since Jakarta for example wants its scripts to run on
everything from cygwin to os X including strange and retarded Sun/HP
> probably makes it much easier to write shell wrappers than initscripts,
> just because the necessary boilerplate is like 4x less.
I'll wait eagerly for the shell interface then.