gnutls upgrade in rawhide to 2.4.0 and license change
by Tomas Mraz
I plan to do gnutls library update in rawhide to version 2.4.0 soon.
Unfortunately the ABI of this version is different from 2.0.4 as is
currently in rawhide. That means that all the libraries and applications
which depend on it will have to be rebuilt.
The new version also changes license on the libgnutls-extra and
libgnutls-openssl libraries and on the utilities which are part of this
package from GPLv2+ to GPLv3+. The main libgnutls library is unaffected
by this licence change as it stays at LGPLv2.1+. It seems that the only
packages currently in rawhide which depend on these two extra libraries
are mcabber and gkrellm which have compatible license with GPLv3 so
there should be no problem with that.
The packages which will have to be rebuilt due to the ABI change are
here:
aiccu-2007.01.15-3.fc9.src.rpm
aria2-0.12.0-4.fc9.src.rpm
bitlbee-1.2-1.fc9.src.rpm
buoh-0.8.2-4.fc9.src.rpm
climm-0.6.2-1.fc9.src.rpm
ctrlproxy-3.0.5-2.fc9.src.rpm
cups-1.3.7-9.fc10.src.rpm
drivel-2.1.1-0.5.20071130svn.fc9.src.rpm
ekg2-0.2-0.1.rc1.fc10.src.rpm
filezilla-3.0.11-1.fc10.src.rpm
gkrellm-2.3.1-3.fc9.src.rpm
gnutls-2.0.4-3.fc10.src.rpm
gobby-0.4.5-3.fc9.src.rpm
gtk-gnutella-0.96.5-1.fc9.src.rpm
gtk-vnc-0.3.6-1.fc10.src.rpm
gurlchecker-0.10.1-8.fc9.src.rpm
hardinfo-0.4.2.3-5.fc9.src.rpm
heartbeat-2.1.3-1.fc9.src.rpm
iksemel-1.3-4.fc9.src.rpm
jd-2.0.0-0.6.svn2129_trunk.fc10.src.rpm
kazehakase-0.5.4-4.fc9.src.rpm
kvm-70-1.fc10.src.rpm
libepc-0.3.5-1.fc10.src.rpm
libggz-0.0.14.1-1.fc9.src.rpm
libprelude-0.9.17.1-1.fc10.src.rpm
libpreludedb-0.9.14.1-2.fc9.src.rpm
libsoup22-2.2.105-2.fc9.src.rpm
libsoup-2.23.1-3.fc10.src.rpm
libtranslate-0.99-14.fc9.src.rpm
libvirt-0.4.3-1.fc10.src.rpm
liferea-1.4.15-5.fc9.src.rpm
loudmouth-1.4.0-1.fc10.src.rpm
mcabber-0.9.6-1.fc9.src.rpm
msmtp-1.4.13-4.fc9.src.rpm
mutt-1.5.18-2.fc10.src.rpm
neon-0.28.2-3.src.rpm
net6-1.3.5-3.fc9.src.rpm
ntfsprogs-2.0.0-7.fc10.src.rpm
obby-0.4.4-3.fc9.src.rpm
prelude-lml-0.9.12.2-1.fc10.src.rpm
prelude-manager-0.9.12.1-1.fc10.src.rpm
qemu-0.9.1-9.fc10.src.rpm
rsyslog-3.19.7-2.fc10.src.rpm
snort-2.8.1-3.fc10.src.rpm
sobby-0.4.4-2.fc9.src.rpm
vinagre-2.23.3.1-1.fc10.src.rpm
virt-viewer-0.0.3-1.fc9.src.rpm
weechat-0.2.6-3.fc9.src.rpm
wireshark-1.0.0-2.fc9.src.rpm
xen-3.2.0-12.fc9.src.rpm
xenwatch-0.5.2-3.fc9.src.rpm
xmlsec1-1.2.9-10.1.src.rpm
First all the library packages must be rebuilt because the dependent
applications will not build due to the buildroot inconsistency.
I'll rebuild all the packages where it is allowed by ACLs, if you have a
package on the list above and do not want me to rebuild it even though
the ACLs allow it please send me an e-mail.
If you have any comments/objections to the version update, please
respond soon before I'll start the rebuilds - most probably on Monday if
there will be no objections.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
15 years, 9 months
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
15 years, 10 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
15 years, 10 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.
15 years, 10 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
15 years, 10 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
15 years, 10 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
15 years, 10 months
