howto push dependencies into sub packages
by Peter Robinson
Hi All,
I maintain the geoclue package. It has a number of providers that can
be compiled in. I've tried to introduce a couple of subpackages for
the gpsd and gypsy providers so that you can just install the
providers you need and not have to pull in extra packages that you
might not need (gpsd and gypsy do essentially the same thing so you
probably don't need both). The problem I'm having is that with the
addition of the gpsd provider (see F-9 testing if you aren't on
rawhide) pulls in gpsd for the main package and not for the
geoclue-gpsd package. How do I push this requirement down to the sub
package so that it doesn't affect the main package (I've got the gpsd
requirements in the sub package).
Cheers,
Peter
12 years, 9 months
Cross toolchain support for SPUs on Cell / ppc64
by Jochen Roth
A lot of people using the PS3 and / or Cell based systems suffer from
missing toolchain support for building SPU applications just after they
installed Fedora. They have to download the necessary packages from
various places and have to do the package management by their own.
I think that the time is right to support SPUs right out of the box
after installing the latest Fedora release. Therefore we'd need to have
the following packages in Fedora.
spu-binutils
spu-gcc
spu-newlib
spu-gdb
Before we start opening Review Requests in Bugzilla we want to start the
discussion what the best approach for supporting cross compiling
toolchains like the SPU toolchain in Fedora is. As far as I know there
is only one example for cross compiler support in Fedora which is Atmels
AVR.
Our suggestion would be to build spu-binutils from the same source as
the system gcc for ppc is build. Here we'd have to change the ppc
binutils package and add --enable-target=spu . A separate spu-binutils
package including the spu assembly is needed anyhow.
It would also be good to be able to build the spu-gcc from the same
sources as the system gcc is build. It would be even better if the
spu-gcc is build from the same .spec file. Of course this needs a lot of
configuration and adjustments.
For spu-newlib we'd have to create a separate package as we'd have for
spu-gdb.
Thanks for any comment, suggestion and help.
--
Jochen
12 years, 9 months
comps.rng
by Will Woods
If you check the 'comps' module in package CVS, you'll see the new file
comps.rng[1]. This is a RELAX NG[2] schema for validating the grammar of
our comps.xml files.
We're hoping to rig this up to the CVS checkin procedure to ensure that
all changes result in valid comps files. We're also going to use it as
part of the daily acceptance testing for Rawhide.
Nicolas Mailhot gets all the thanks for writing the schema - I just
checked it into CVS.
If anyone would care to comment on the undocumented[3] parts of comps -
especially what the heck metapkg is for and whether we need it - it
would be greatly appreciated.
Thanks!
-w
1 http://cvs.fedoraproject.org/viewcvs/comps/comps.rng?rev=1.1&view=log
2 http://relaxng.org/
3 Look for <a:documentation> tagged items in comps.rng to see what's
documented so far.
12 years, 9 months
Evolution glib problems anyone?
by Paul F. Johnson
Hi,
I'm trying to start up evolution and all I seem to get are the following back
[paul@t7 ~]$ evolution
CalDAV Eplugin starting up ...
** (evolution:4765) : DEBUG: mailto URL command: evolution %s
** (evolution>7465) : DEBUG: mailto URL program: evolution
GLib-ERROR **: gmem.c:136: failed to allocate 31740376080 bytes
aborting...
Trace/breakpoint trap
I'm not sure why it's trying to allocate such a huge amount of memory either.
TTFN
Paul
--
Programmer, GirlGamer
www.girlgamer.com
12 years, 9 months
Backporting some F9 packages to F8
by Joshua C.
Can someone backport some of the F9 packages to F8? Especially some of the
following:
firefox 3
openoffice.org 2.4.1 (3 beta)
kdebase 4.0.83 beta
mesa
xorg-x11-drv-ati
pulseaudio
gdm
gcc
............................
and other "basic" packages. It would be nice to have up-to-date F8.
-joshua
12 years, 9 months
CreatingPackageHowTo
by David A. Wheeler
I think there that there is a real need for the
"CreatingPackageHowTo" page. The "RPM Guide" by
Eric Foster-Johnson is not a bad book, nor is "Maximum RPM". However...
Documents like the "RPM Guide" tend to be generic for any distro, and fail
to give enough Fedora-specific info. E.G, for _Fedora_:
* You need to know about "yum install rpmdevtools", and "rpmdev-setuptree".
* For each tag, you need to know the Fedora rules, right when you learn
about the tag. E.G., generic docs will tell you "Summary:" exists,
but not "Use American English". For "Group:" where do you find the
list of groups? For "License:", where's the list of license abbreviations?
* %build should use%{?_smp_mflags} with make, where appropriate.
* There are lots of Fedora-specific guidelines that should an intro document
should link to, if you're creating Fedora packages.
Many of the documents on RPM don't seem have clear statements explaining
misleading terminology, and as a result they're very confusing.
The "build directory" and "build root" are fundamentally different, yet
many existing docs don't make it _clear_ that there is a difference.
The "%install" section doesn't actually do the final software install
(when you have a build root), but this is often not made clear; a reader
might think that's what is run when users install a binary RPM.
Finally, most of the RPM docs aren't well-maintained.
For example, Fedora packages are supposed to use "%check",
which is essentially undocumented, and are supposed to AVOID
"%makeinstall" if they can. WHY aren't the docs maintained?
I believe a key reason is that they aren't on a Wiki.
Wikis (by their nature) are easy to update/fix, and thus they
tend to be more up-to-date.
I don't think it has to be either/or. The "CreatingPackageHowTo"
page gives the overall info, and then links to specific chapters
for specific information when it's needed.
--- David A. Wheeler
12 years, 9 months