Removed and orphaned:
asp2php - does not show any history of usage, not really a core package
Suggested for removal:
- 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
- legacy interface (motif)
- doesn't support Unicode
- doesn't support Unicode
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
I thought that maybe you guys would have some input on this?
---------------------------- 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"
On Fri, 28 Jan 2005 14:39:32 -0000 (GMT), "Gavin Henry"
> <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
> 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
> 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.
fedora-docs-list mailing list
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
"It's always better to hurt a little now, than to hurt a lot later!"
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?
I have D-BUS version 0.30 in my yum repository at
name=J5's Experimental Project Utopia Repository
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.
John (J5) Palmieri
Associate Software Engineer
Red Hat, Inc.
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
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
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
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 -
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
Ville Skyttä wrote:
>>"apt-get build-dep" does not need SRPMS at all except the local
>>SRPM, which you already have locally because you want to build it.
> Right, but the source _indexes_ need to be available for build-dep to
> work in the first place, no?
apt-get build-dep TARGET_LOCAL.src.rpm does not require SRPMS in the apt
repository. This only resolves and installs stuff from binary RPMS
needed to build that local package. Am I missing something else?