Postings by =?ISO-8859-1?Q?Caol=E1n?= McNamara

I'm dropping libreoffice-gtk2

In favour of the libreoffice-gtk3 which has already been the default
for the last few fedora releases

hunspell soname bump

rawhide hunspell has been bumped to 1.6.2 from 1.5.4, which bumps
libhunspell from 1.4 to 1.5. I believe everything that needs to be
rebuilt has been rebuilt except firefox whose build fails on armv7hl
with an apparently unrelated std::bad_alloc exception during its build

Bugzilla auto-CC

There was some discussion a while back about Bugzilla auto-CC
<a href="" title=""></a>

<a href="" title=""></a> has state "Unwatch"
for me, and has since definitely yesterday, perhaps longer, but I was
automatically added in CC to <a href="" title=""></a>
d=1491510 logged today

Where can I find the setting for getting unCCed for future gnome-
terminal bugs, and ideally explore what else I'm set to be cc-ed on

Calibri/Cambria replacements Carlito/Caladea

I see that recently chromium appears to have commissioned two fonts
claimed to be metrically equivalent to Calibri and Cambria. Which is
super great from the perspective of giving LibreOffice a decent shot at
laying out Microsoft Office documents that use the default Calibri

who/where maintains ?

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

The fedora 16 section has
while the other sections have

and correspondingly preupgrade is unable to find the repo.

debugging build hang in koji ?

So, local mock x86_64 builds work just fine. But AFAICS the build just
hangs in fairly random places when put through x86_64 koji, anyone got
any good ideas about how to find out even what process is hung ?


<a href=";name=build.log&amp;offset=-4000" title=";name=build.log&amp;offset=-4000">;name=build.log...</a>

is an example of the hang, i.e.

time taken was 0.004 seconds
zip warning: help.jar not found or empty
adding: com.sun.PresenterScreen-linux_x86_64/presenter.xhp (deflated 81%)

and nothing else.


F-13 packages still linked to db4-4.7

All these rpms are still linked to db4-4.7 instead of db4-4.8. They just
don't appear as broken dependencies because of the existence of

quick hack to reannotate abrt traces with missing debuginfo

In case its useful, I've hacked together a quick utility to reannotate
abrt traces which had missing debuginfo at the time of report with the
correct source lines according to the debuginfo installed on the
annotator's box. Should be safe for reports from prelinked binaries.

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


A comps group ?

As per <a href="" title=""></a> I'm
wondering if a group makes sense for Comps ?

I see that and are listed
at the moment in comps under Office/Productivity. Both of those are
targeted at development for or with OOo and so best listed elsewhere.
Other related packages, currently unlisted, such as the sdk, the rhino
and beanshell scripting integration packages and so on could be lumped
in there then.


Installing Fedora with software based synthesizer for sceenreader

Is is possible to *install* Fedora using our accessibility support out
of the box, specifically do we have support for installing fedora and
have a software based synthesizer available for the screen reader during
installation ?

I see that there was a previous fedora-derived effort but only as far as
F-9, and "A hardware speech synthesizer is required to install" though
after install supports "operation using software speech synthesizers",
i.e. <a href="" title=""></a>


rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?

So, <a href="" title=""></a> was logged a
while ago against OOo for the rpms "improperly" providing and
requiring .sos that are not in the linker path, but instead in OOo's own

The concern is that the autorequires/provides operate in a flat
namespace and that eventually there'll be some conflation where
something linking to /usr/lib/ will force sucking in a package
that provides /usr/lib/package/plugins/ instead

Clearly this isn't specific to OOo, e.g.


I see that our binutils has a very convenient binutils_target ifdef in
it to make cross-binutils. Before I home-cook something to hack up some
local up-to-date cross compilers for myself for icecream/distcc, do we
have any semi-standard hackery for making arbitrary cross-gcc gcc/g++
rpms from our vanilla gcc one ?