Postings by Tom "spot" Callaway

glibc-arm-linux-gnu help

A few years ago, I packaged up glibc-arm-linux-gnu, so that Fedora could
have a packaged arm cross-toolchain that was useful (with glibc, it
cannot build anything in userspace). It worked for a while, but lately,
all builds have been failing with this error:

/usr/bin/arm-linux-gnu-ld: skipping incompatible
/usr/lib/gcc/arm-linux-gnueabi/8/libgcc_eh.a when searching for -lgcc_eh

I've looked at it and poked it quite a bit locally, but I can't seem to
get around that.

Proposal: Abandon v8 package

I made the original v8 Fedora package many moons ago, when I was more
optimistic about the possibility of separating the useful components
inside of chromium. Since that point, it has become clear that while v8
is useful software, the following facts are also true:

1. The v8 upstream is entirely disinterested in the concept of
maintaining any sort of ABI/API consistency between releases.
2. The v8 that is used in chromium is not necessarily compatible with
the upstream v8, as they have a history of picking and choosing code
changes (and even applying chromium specific changes locally).

Friendly Reminder: Your Legal Responsibilities as a Fedora Community Member

This should go without saying, but in Fedora, the following things
should be kept in mind:

1) Copyright infringement is not permitted. This includes code, fonts,
docs, or content like art/sprites taken from other works, either without
permission or under non-free licenses.

2) Trademark infringement is not permitted.

asymptote segfaulting in rawhide/f28, maybe gcc issue?

I'm not sure if this is a gcc issue or not, but asymptote segfaults in
some situations (which is causing the FTBFS, since it bootstraps itself
with itself). I filed a bug upstream with the crash and gdb backtrace:

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

If any gcc c++ people could look at it, I would appreciate it. It's one
of the few FTBFS bugs I have left.


License tag change (EPL)

Hi Fedorans,

If your package uses code under the Eclipse Public License, please take
a moment and change the license tag to reflect the version. There are
now two versions of the EPL, 1.0 and 2.0.

libvpx 1.7.0 update in rawhide

The new libvpx 1.7.0 update in rawhide bumped SOVER because of an ABI
break. I rebuilt all the dependent packages I could find with dnf
repoquery, except for firefox and thunderbird due to lack of access.

Apologies if I missed something.


P.S. I will not be pushing libvpx 1.7.0 into any stable Fedora releases.

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?