Fedora PPC things...
by Colin Charles
CC'ing fedora-devel-list because there are some things that need to be
sorted for a possible FC-4/ppc _release_
Now, a list of known issues:
0. this boot.iso + nfs installation system has to go away - so we need
to give anaconda love
1. out of the box video detection - system-config-display needs to be
hacked on to recognise all the common Mac hardware bits out there. We
can't be pushing Xautoconfig or something similar... but we can lean on
it for inspiration if need be
2. anaconda and partitioning - auto partitioning possibly still fails (I
don't think the Apple Bootstrap partition gets created); running
yabootconfig automatically after installation, with an appropriate
initrd and so on needs to happen (we can't depend on users breaking out
into a shell)
3. sound is still relatively broken - dmasound_pmac tends to work, but
is not the default config. system-config-soundcard definitely needs some
work to make it play well with the Macs
4. power management - we need either pmud or pbbuttonsd. The latter has
received no love from most fedora/ppc users, so pmud seems to be the
winner, I'd guess. We need this included in Core (building only for ppc,
and possibly later ppc64). We know yellow dog add some nice patches for
disabling the touchpad in pmud - I guess the package maintainer can be
free to include such patches at will if need be
5. updates - we can't have david woodhouse (dwmw2) grabbing packages
from the RH build system and having to host them at ftp.linux.org.uk -
we need a better mechanism. i.e. the normal way package updates go out,
can the ppc and ppc64 packages go out with them too? This might involve
some policy change at Red Hat, so can someone in the know, speak up?
6. back to the topic of power management; there are some patches out
there that help G4 iBooks and newer powerbooks sleep (and wake up).
They're not in the upstream kernel.org kernel, but with good benh
approval (!), we might consider patching the kernel to make it more
useful. dwmw2 currently builds kernels with these patches enabled
7. we'll be upfront about modems and Airport Extreme probably never
working for free. Modems have drivers at linuxant (though they still
might be flaky with our stack size in the kernel), but the Airport
Extreme stuff is probably a no go (not yet at least)
8. 64-bit support. I personally don't have a G5 or anything ppc64, but I
know that dwmw2 has one sitting at work, as probably does nasrat. We
need more 64-bit testing, and making sure that anaconda boots on them
too (if not we need more anaconda hacking). There have been reports that
things were (or are still) broken on a 64-bit arch
9. PegasosPPC (Genesi) makers of PPC boards have thought of getting
FC4/ppc to work on their machines. I'll be taking a look at this, though
does anyone else have such machines around?
10. spanking MiniMac support?
I guess this is a list of outstanding issues that we need to fix before
Fedora Core 4 gets a PPC release. If I missed anything glaring, do add
on the the thread
Otherwise, lets get some C and Python hackers hacking on the packages
above, and making things "just work" for FC/ppc. PPC specific discussion
can take place at fedora-ppc(a)lists.infradead.org
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
"First they ignore you, then they laugh at you, then they fight you,
then you win." -- Mohandas Gandhi
19 years, 2 months
further package removals/potential package removals
by Bill Nottingham
Removed and orphaned:
asp2php - does not show any history of usage, not really a core package
Suggested for removal:
xloadimage
- there are better apps for displaying images (ImageMagick,
eog, gthumb, kview, etc)
- there are better apps for setting the root window (xsri)
- it's *ancient* code that doesn't even support PNG
nedit
- legacy interface (motif)
- doesn't support Unicode
jed
- doesn't support Unicode
Opinions?
Bill
19 years, 2 months
rawhide firefox and background colour of webpages (CSS broken?)
by Kyrre Ness Sjobak
I have installed rawhide firefox on my fc3 computer, and it is pretty
nice - exept two thing.
Background color on several webpages (phpBB forums f.ex.) are now
grayish. Not white (?) as they should be, judging from the white
"border" around buttons.
Also, it has no norwegian language support.
This is version 1.0.8
19 years, 2 months
Our Discussion on Fedora-docs [Fwd: Re: Fedora Documentation Search Engine]
by Gavin Henry
Dear all,
I thought that maybe you guys would have some input on this?
Gavin.
---------------------------- Original Message ----------------------------
Subject: Re: Fedora Documentation Search Engine
From: "Stuart Ellis" <s.ellis(a)fastmail.co.uk>
Date: Fri, January 28, 2005 3:24 pm
To: "For participants of the docs project"
<fedora-docs-list(a)redhat.com>
--------------------------------------------------------------------------
On Fri, 28 Jan 2005 14:39:32 -0000 (GMT), "Gavin Henry"
<ghenry(a)suretecsystems.com> said:
> <quote who="Stuart Ellis">
> >
> > On Fri, 28 Jan 2005 12:56:58 -0000 (GMT), "Gavin Henry"
> > <ghenry(a)suretecsystems.com> said:
> >> Dear all,
> >>
> >> Has there been any discussion about this?
> >>
> >> I thinking along the lines of htdig/swish-e that indexes all man
pages/howto/README after every rpm is installed.
> >>
> >> Something like a post entry in the spec file, or similar.
> >
> > I haven't seen any on this list, but essentially this is a function of
having a desktop search/indexing engine since there isn't a common
format to this stuff. The next release of yelp (GNOME help browser)
will display info and man pages, but can't index the random txt, html,
pdf etc. that goes into /usr/share/doc/.
>
> We heavily use Swish-e (www.swish-e.org) for the fileservers we install.
This can handle html, xhtml, txt, pdf and the like.
I've just looked at the page now, but it looks like a very useful bit of
software.
> Maybe something like this or a updatedocdb crontab, like slocate has and
we just put the standard doc pathnames in a config file. The customize
the
> web search page.
>
My understanding is that this is where things become quite technical and
problematic. There is always a disjunct between what's actually on the
disk and what is listed in the index. On portable computers it's harder
to guarantee that batch indexing jobs will be completed regularly as well.
Beagle and Spotlight use kernel hooks to update the index as changes
occur. I suppose that RPM packages could run post-install scripts that
update a document registry (kind of like you suggested) would be a
relatively non-invasive way to implement something.
I definitely think that the default start page of the Web browser could be
used very effectively by the docs project. The details of
implementing an index might be a good question for fedora-devel.
--
Stuart Ellis
s.ellis(a)fastmail.co.uk
--
fedora-docs-list mailing list
fedora-docs-list(a)redhat.com
To unsubscribe:
http://www.redhat.com/mailman/listinfo/fedora-docs-list
19 years, 2 months
Starting sshd errors
by Mike Chambers
Up until a few weeks (couple I guess) openssh was working fine. But now
when trying to start it, I get "initlog not found", which is around line
107, when the /etc/init.d/sshd file has "initlog -c blah blah".
Have been away from home last few weeks so haven't really been able to
pay attention if this problem already has a fix, so sorry if asking
again.
Thanks,
--
Mike Chambers
Madisonville, KY
"It's always better to hurt a little now, than to hurt a lot later!"
19 years, 2 months
Building subversion javahl bindings
by Pedro Lamarão
I've got this patch to subversion.spec that allows optional building of
javahl bindings with a variable-specified JDK path.
I've built it as I need Subclipse to work.
What do you all think?
--
Pedro Lamarão
19 years, 2 months
D-BUS 0.30 in my yum repository - porting guide attached
by John (J5) Palmieri
I have D-BUS version 0.30 in my yum repository at
[j5utopia]
name=J5's Experimental Project Utopia Repository
baseurl=http://people.redhat.com/johnp/redhat/experimental/utopia
You will have to --force --nodeps the packages for now until all the
packages are updated to use the new dbus.
Attached is a short porting guide. Ask me if you have any more
complicated questions about the new API's.
Please patch your rpm's to reflect the new API. We will make the
switchover in a couple of weeks or whenever all the packages are done.
Send me the srpm's so I can add packages to the repository as they are
done. Here is a list of packages in core that need to be updated:
gnome-volume-manager - me
hal - davidz
NetworkManager - dcbw
NetworkManager-gnome - dcbw
desktop-printing - walters
cups - twaugh
I'm posting this to fedora-devel so that packagers outside of core can
consider themselves warned. Massive API breakage for anything that uses
D-BUS is on the horizon as we move closer to 1.0. The 0.30 series
should mark the biggest change moving to 1.0 and I don't expect anymore
API breakage other than the glib bindings in the future. If there is
I'll let you know.
Thanks
--
John (J5) Palmieri
Associate Software Engineer
Desktop Group
Red Hat, Inc.
Blog: http://martianrock.com
19 years, 2 months
repository creation
by seth vidal
After all this absolutely enjoyable discussion of repodata format I
figured I'd mention something that would help users tremendously to
reducing the amount of data they might have to download.
right now when a repository is created for use it's just made on ALL
packages in the install tree.
so you end up with srpms and debuginfo rpms in there.
So you get 2623 pkgs to read through for fc3 base
but if you just read through binary rpms you only have 1653 pkgs to read
through. A pretty serious savings, almost 1000 packages.
Now, yum prunes out the packages it can't use right away, but it is
still having to read through all that data.
so why not make the repo like this:
createrepo -x *.src.rpm -x *.debuginfo* -g Fedora/base/comps.xml .
and then make another srpm repository in the SRPMS dir all on its own.
Ditto with debuginfo.
but then we should add disabled-by-default srpm and debuginfo repos to
each .repo file in yum.repos.d
fedora.repo:
[base]
....
enabled=1
[base-srpm]
...
enabled=0
[base-debug]
....
enabled=0
then the user, if they need the debuginfo rpms, for example, can run:
yum --enablerepo=base-debug install foo-debuginfo
We should do the same for extras and updates, updates-testing repos, and
rawhide too.
I think, on the whole, we'd see a huge increase in speed for going
through repos b/c we simply would have less data for 95% of the users to
go through.
-sv
19 years, 2 months
gnome-vfs2 and cdda
by John Thacker
So I created bug #137250 a while back, and no one seems to have claimed it.
( https://bugzilla.redhat.com/beta/show_bug.cgi?id=137250 )
I can understand why, as it's a bit complicated.
gnome-vfs2 has a CDDA module which uses cdparanoia. By default, it's
enabled in /etc/gnome-vfs-2.0/modules/default-modules.conf.
However, it doesn't get built because of the unusual location of the
cdparanoia include headers in RedHat and Fedora. They're located in
/usr/include/cdda/cdda_paranoia.h and /usr/include/cdda/cdda_interface.h
instead of just in /usr/include. Therefore, gnome-vfs2 doesn't build
the CDDA module, and, since it's enabled in the default configuration,
there are tons and tons of warnings when adding new files in totem or
anything else which uses gstreamer and/or gnome-vfs2, and prevents totem
from playing audio CDs. (Bug 144803 -
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144803 )
Other programs which use cdparanoia have been patched to detect the
header files in their special location. See various bugs dealing with
grip and kde ( such as 62852 )
Why is it in a non-standard place? Well, cdparanoia header files include
a file called utils.h that includes a couple standard macros. Originally
this wasn't included in RHL because of a reluctance to include a file
called utils.h in /usr/include. (See bugs 38223 and 62852)
As a result, they were put into /usr/include/cdda. (As it turns out,
grip doesn't use utils.h anymore, it seems.)
So, there are a couple of options:
1) Comment out the cdda plugin in default-modules.conf.
Advantages: easy, no more warnings
Disadvantages: still can't play audio CDs in totem
2) Patch gnome-vfs2 build process so that it finds the include files in
the proper place
Advantages: plugin builds, everything works
Disadvantages: possibly annoying
3) (Drop utils.h and?) Put cdparanoia includes in the standard place.
Advantages: easy, everything works
Disadvantages: someone might want utils.h, changes old workaround,
reasons for workaround might still exist
I'd like to have some sort of fix for this, or at least a comment or two.
I imagine that responsibility for the bug or the proper fix is difficult
to identify, though, which probably has slowed things.
See also bug 102754 for another problem having to do with compiling using
cdparanoia.
John Thacker
19 years, 2 months
