Postings by Tom "spot" Callaway

CDDL 1.0 and 1.1

Hi Fedorans,

Fernando Nasser noticed that there were now two versions of the CDDL.
Accordingly, we have created new shortname identifiers:

* CDDL-1.0
* CDDL-1.1

We have also retired the old, unversioned, "CDDL" shortname identifier.

If you maintain a package which includes CDDL code, please check to see
which version of the license applies, and update the License tag

You do not need to make an update to your package in Stable branches of
Fedora solely to reflect this change, it is sufficient to make this
change in Rawhide, and inherit it into all future builds.

You can see m

Announcement: fdk-aac

Hi Fedorans!

Today, a Third-Party Modified Version of the Fraunhofer FDK AAC Codec
Library for Android has been cleared for inclusion in Fedora.

Arduino in Fedora

In attempting to figure out why the lulzbot-marlin-firmware was not
being compiled properly, I noticed that the arduino packages in Fedora
were a bit out of date. To remedy this, I made updated versions of them
and put them in my copr here:

<a href="" title=""></a>

Testing of these packages would be greatly appreciated.

R packages needing review

required all "compiled" R modules to be rebuilt against it. I've been
working over the last week or so to do this, and at the same time, bring
them to the latest revisions.

Unfortunately, CRAN and Bioconductor (where the majority of R modules
live) have a bit of a dependency creep problem, where almost every
update adds new dependencies on other R modules (it's even worse if you
run the test suites).

Policy change on emulators

To the Fedora Community,

The Fedora policy on emulators has been in place for quite some time, it
is one of the first legal rules we put in place. Recently, we
reconsidered that rule and have amended our position (with discussion
from Red Hat Legal).

Previously, the guidelines forbid the majority of emulators from being
included in Fedora, but the new guidelines, while longer, are more

=== Emulators ===

Some emulators (applications which emulate another platform) are not
permitted for inclusion in Fedora.


Look, I know review requests suck. Especially when they're for
toolchains, and packages like "native_client" that is a giant pain of
bundled and twisted bits. But I'd really like to get chromium into
Fedora proper. (Does that make me crazy? Yes.

Another GCC 6 & Rawhide build failure

First the C++ code:

namespace Amanith {

struct GNamedSVGcolor {
GChar8 Name[22];
GVector4 RGBA;

static const GNamedSVGcolor SVGColors[147] = {

{ "aliceblue", GVector4(0.941, 0.973, 1.000, 1.000) },
{ "antiquewhite", GVector4(0.980, 0.922, 0.843, 1.000) },
{ "aqua", GVector4(0.000, 1.000, 1.000, 1.000) },
{ "aquamarine", GVector4(0.498, 1.000, 0.831, 1.000) },
{ "azure", GVector4(0.941, 1.000, 1.000, 1.000) },
{ "beige", GVector4(0.961, 0.961, 0.863, 1.000) },
{ "bisque", GVector4(1.000, 0.894, 0.769, 1.000) },

Review requests that need reviewers

The easy ones (some R packages I need as deps for updating R-DBI):
<a href="" title=""></a>
<a href="" title=""></a>
<a href="" title=""></a>
<a href="" title=""></a>
<a href="" title=""></a>

The hard ones (chromium and friends):
<a href="" title=""></a>
<a href="" title=""></a>
<a href="" title=""></a>
<a href="" title=""></a>
<a href="" title=""></a>

texlive 2015 in rawhide

TeXLive 2015 has now landed in rawhide. (Don't worry, it's not coming
into Fedora 23 this late in the cycle.)

This should not result in any changes on your end (famous last words),
but if you notice something in rawhide fail to build because of a tex
related issue, please be sure to point it out in either an email to me
(or better, a bug against texlive in rawhide).

Warning: Looking at how texlive packaging works will make you go blind,
mad, and possibly incontinent. Ask your doctor if texlive packaging is
right for you.


Red Hat

efl review swap?

I sure could use a review on efl so that we can update Enlightenment to
0.19. Will swap for a review, or other Fedora related bribery.

<a href="" title=""></a>


Red Hat

Changes to the Packaging Guidelines

We've been very bad at announcing changes to the Packaging Guidelines.
So very bad. Bear with us as we announce all the changes we should have
been announcing in the past, but failed to do. Again, so bad.

The Mersenne Twister implementation (mt19937ar) has been granted a
general bundling exception. ​
<a href="" title=""></a>

After an unintentional delay, the Haskell Guideline revision approved
four months ago has been officially written into the Guidelines.

Retiring: R-RScaLAPACK

This package makes baby seals wish they could be clubbed. Upstream has
killed it. I disavow any knowledge of it.

Retired: R-RScaLAPACK


¸.·´¯`·.´¯`·.¸¸.·´¯`·.¸><(((º> OSAS @ Red Hat
University Outreach || Fedora Special Projects || Fedora Legal

%ifarch note

Since I hit this, I'd imagine other people might.

If your package has:

BuildArch: noarch

It will set %{_target_cpu} to "noarch".

If you also use %ifarch in that spec file, you might be expecting it to
match %{_arch} (the architecture of the build server). It does not. It
matches %{_target_cpu}.

If you need to conditionalize on the value of %{_arch} in such a spec
file, you need to do it explicitly:

%if %{_arch} == x86_64 || %{_arch} == i686

Hope that helps other folks,


Fedora Project

Flock proposals now open for community voting

Thanks to the Fedora Community for submitting 125 awesome talks,
hackfests, sprints and workshops for Flock, our new contributor conference!

We've taken those submissions and put them in the Fedora Elections web
application, and now, it is time for you to give us your feedback. These
proposals have been submitted by the Fedora community and we want the
Fedora community to tell us what _you_ want to see!

lua 5.2

You may have noticed me poking random packages, I'm preparing rawhide
(and only rawhide) for an update to lua 5.2.

Please be patient. :)


Fedora Project

Open Seat on the Fedora Packaging Committee

The Fedora Packaging Committee has one open seat and is accepting
submissions from interested candidates to serve on the FPC.

The FPC would like to thank Rex Dieter for his service, as he is
stepping down after several years.

This position involves not only reviewing Packaging Guideline drafts
submitted to the FPC for consideration, but also rewriting drafts
(sometimes from scratch) to resolve the issue in a more acceptable
fashion. Additionally, the FPC reviews bundling exceptions (and UID/GID
soft static assignment).

Changes to the Packaging Guidelines

Another round of changes to the Fedora Packaging Guidelines have been made:

A new section on packaging cron jobs has been added:

<a href="" title=""></a>

The guidelines for migrating from sysv init scripts to systemd were
clarified to state that the migration triggers only need to be kept for
two releases (to cover the range of supported upgrades). For example, if
the package converted to systemd unit files in F18, the migration
support could be dropped in the F21.

Changes to the Packaging Guidelines

Some more changes to the Fedora Packaging Guidelines have been made:

The Packaging Guidelines covering Desktop files have been amended to say
that for Fedora 19 and beyond, the vendor tag must not be used. If it
was being used in a previous release, it may continue to be used for
that previous release, but must be removed in Fedora 19. New packages
must not add the vendor tag for any release.

Changes to the Packaging Guidelines

Some changes to the Fedora Packaging Guidelines have been made:

If a package is exempt from multilib, it may use %{_prefix}/lib instead
of %{_libdir}. Packages that contain architecture specific files that
would ordinarily be installed into %{_libexecdir} are always considered
ineligible for multilib. However, you should be sure that the
(sub)package that they are in does not have other content that would be
considered eligible for multilib.

Retiring packages due to broken deps

Since the following packages seem to be unmaintained and have broken
deps in Fedora 18, I propose that they be retired and blocked before


These retirements would result in the following broken dependency:


However, since nothing depends on libopensync-plugin-syncml, I propose
that it also be retired and blocked.

Additionally, these packages are already retired in Rawhide, I propose
that they also be blocked in Fedora 18:


Changes to the Packaging Guidelines

Some changes to the Fedora Packaging Guidelines have been made:

In the specific case where multiple software components generate
identically named (but incompatible) binaries, Fedora Packagers should
make every effort to convince the upstreams to rename the binaries to
resolve the conflict (see: Packaging:Conflicts#Binary_Name_Conflicts).
However, if neither upstream is willing to rename the binaries to
resolve the conflict, AND the binaries are not viable candidates for
alternatives or environment modules (incompatible runtimes), as long as
there are no clear cases for both packages to

Update to Binary Firmware Exceptions

Two minor exceptions have been added to the Licensing Guidelines:

A new exception has been added to permit prebuilt binary QEMU ROMs
implementing BIOS or Firmware for QEMU system targets to be packaged in
those situations where it is not practical or possible to build them
from source, as long as the corresponding source code is also included
in the Source RPM package.

<a href="" title=""></a>

The wording of the Binary Firmware exception has been amended slightly
to permit the packaging and inclusion of firmware files which are
necessary to boot Fedor

Change to the Packaging Guidelines

A few minor changes to the Fedora Packaging Guidelines have been made:

The Ruby Packaging guidelines were updated to reflect the fact that
rubygem packages must have a Requires: rubygems, because that package
(rubygems) owns the RubyGems?

Change to the Packaging Guidelines

Here is one late change to the Fedora Packaging Guidelines:

The systemd scriptlet guidelines have been updated for Fedora 18. In
Fedora 18, the systemd package now provides helper macros to simplify
%post, %preun, and %postun invocations in packages with systemd unit

Changes to the Packaging Guidelines

Here are the latest set of changes to the Fedora Packaging Guidelines:

A new section has been added to the SysV Initscripts section, discussing
the proper use of subsys locking. Even though Fedora packages should no
longer be using SysV Initscripts as a primary service mechanism, Red Hat
Enterprise Linux and EPEL do.

Changes to the Packaging Guidelines

Here is the latest set of changes to the Fedora Packaging Guidelines:

In Fedora, you can assume that the default shell (/bin/sh) is bash.
Thus, all scriptlets can safely assume that if they are running in shell
code, they are running within bash.

<a href="" title=""></a>

A bundling exception was granted for calibre to bundle their forked
version of pyPdf.

<a href="" title=""></a>

A new set of MinGW guidelines are in place for Fedora 17+.

Changes to the Packaging Guidelines

Here is the latest set of changes to the Fedora Packaging Guidelines:

A bundling exception for boost within Passenger was granted, due to the
intrusive nature of the forked changes, the efforts of the maintainer to
merge as many of them as possible into the upstream boost source tree,
and the visible efforts of the upstream to keep the bundled copy of
boost in sync with the current boost releases.

The package must also include a Requires: bundled(boost) = $VERSION
where $VERSION is the boost version being bundled.

<a href="" title=""></a>

openvrml patches for f17 and rawhide

I've spent far too much time working on this, but I still haven't gotten
it 100% working (the browser tests still fail). I'm not entirely sure
these fixes are correct either, so I'm just sharing what I've
accomplished here and moving on.


Fedora Project

Fedora Engineering "Open House" IRC Meeting - Thursday, February 23, 2012 - 1800 UTC

Apologies in advance for the wide distribution of this message.

The Fedora Engineering team is holding an "Open House" IRC meeting on
Thursday, February 23, 2012 at 18:00 UTC (12:00 PM EST). This will be a
moderated meeting in which we will briefly present the upcoming projects
for the Fedora Engineering team, then take questions, suggestions, and
feedback from the Fedora Community.