I made a first contribution package for xedit, that happens to be the
text editor I use for most tasks :-) see
I would like to contribute to SciTech SIG. I notice there is
https://fedoraproject.org/wiki/SIGs/SciTech/SAGE, and actually, I have
packaged sagemath in Mandriva, and kept the package functional and updated
to latest upstream for around 3 years.
Sagemath itself depends on roughly 300 different upstream packages, and
other packages I would like to contribute at some point is salome, that
I also packaged in Mandriva, http://www.salome-platform.org/. Currently it
is not functional in Mandriva cooker but should be in released versions,
I got a hacked workaround described at
Other large "scientific" system I package is texlive, that I made several
perl and sh scripts that allows translating texlive package management
control files, etc to rpm specs, so that can keep up to date with latest
TeX Live. This is a very large set of packages, due to matching 1 to 1 with
$ urpmq -a texlive- | sort -u | wc -l
There is already such a texlive packaging schema for fedora described
at http://fedoraproject.org/wiki/Features/TeXLive so I should at least be
able to help a bit :-)
I understand that there is plenty of bureaucracy to get packages in the
distro, and do not expect them to be "core" packages, but expect them to
be unsupported, contrib packages.
Most important packages I maintain in Mandriva should be gcc, glibc,
valgrind and java-1.*.0-openjdk.
Note that I am a Mandriva employee and my major interest is to become
more aware of how Fedora works, so, I want to contribute like I did with
several other projects in the past, that is, after work at home and/or
I'm orphaning papyon, since Empathy no longer uses telepathy-butterfly
for MSN support. papyon is pretty much dead upstream, but I believe a
few of the lesser known IM clients may still be using.
Brian Pepple <bpepple(a)fedoraproject.org>
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
This is very much a draft, but I'd like to start a discussion regarding
what we expect from primary architectures. Feedback not only welcome,
but actively desired.
Secondary architectures in Fedora are subject to looser constraints than
primary architectures for two primary reasons:
1) To make it easier to bootstrap an architecture without the overhead
of the primary architecture release engineering process
2) To avoid primary architecture development being held up by poorly
developed or niche architectures
Promoting an architecture to primary architecture status is a
significant responsibility. It implies that the port is sufficiently
mature that little in the way of further architecture-specific changes
or rebuilds will be required, and also that it has enough development
effort to avoid it delaying the development of other primary
architectures. Further, it means that the architecture becomes part of
the overall Fedora brand. Fedora is an integrated Linux distribution
rather than a technology collection, and as such there are various
expectations that the overall Fedora experience will be consistent over
all primary architectures.
In order to ensure that these expectations are met, secondary
architectures must meet various criteria before they can be promoted:
1) There must be adequate representation for the architecture on the
Fedora infrastructure and release engineering teams.
2) All builds must occur on Fedora-maintained build servers.
3) Where technically possible, all supported hardware targets must be
supported via Anaconda. Exceptions are limited to highly resource
constrained devices or hardware which provides no means for simultaneous
support of install and target media.
4) All supported platforms must have kernels built from the Fedora
kernel SRPM and enabled by default in the spec file. Each kernel must be
built in a timely manner for every SRPM upload.
5) Sufficient developer resources must be available to fix any
architecture-specific issues in such a way that they do not delay
overall Fedora development.
6) It must be possible for maintainers of critical-path hardware
dependent packages to have direct access to supported hardware in order
to rectify any release-blocking issues. For example, X maintainers must
have direct access to any hardware with graphics capabilities.
7) The port must not rely on sourceless binaries unless they fall under
the generic firmware exemption. Where source and toolchain are
available, the binaries must be built in the Fedora build
As such, promotion to primary architecture status will require agreement
from the Fedora infrastructure, release engineering, kernel and
installer teams and is subject to overall approval by the Fedora
Matthew Garrett | mjg59(a)srcf.ucam.org
Hi, a new cfistio package (3.300) as landed in rawhide. Packages
depending on cfitsio should be rebuilt.
Sergio Pascual http://guaix.fis.ucm.es/~spr +34 91 394 5018
gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC
Departamento de Astrofísica -- Universidad Complutense de Madrid (Spain)
I recently release libffi 3.0.11, and ABI changes are mandating a .so
number change. Despite the ABI change, I suspect that simple rebuilds
are all that will be required for dependent packages.
The ABI changes are simply:
1. Some internal debugging functions that should never have been
exported have been removed:
void ffi_assert(char *expr, char *file, int line)
void ffi_type_test(ffi_type *a, char *file, int line)
2. A new function has been introduced to support
variadic functions (ffi_prep_cif_var).
Libtool's guidelines for .so versioning mandate that I move from
libffi.so.5.0.11 to libffi.so.6.0.0 (because functions have been
There are more than a handful of packages that depend on libffi, so
I'm looking for advice on when to make this change. Also, is there a
convenient way to determine which packages in all of Fedora depend on
libffi? I would like to notify the maintainers that rebuilds will be
required. Or is there some other way to do this?
I plan on importing exiv2-0.23 into rawhide soon'ish. It includes an
ABI bump, so dependent packages will require rebuilding, including:
I'll take care of kicking off a round of rebuilds for these.
devel-announce mailing list