DevHeads.net

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

Bugzilla auto-CC

There was some discussion a while back about Bugzilla auto-CC
<a href="https://pagure.io/fedora-infrastructure/issue/6315" title="https://pagure.io/fedora-infrastructure/issue/6315">https://pagure.io/fedora-infrastructure/issue/6315</a>

<a href="https://src.fedoraproject.org/rpms/gnome-terminal" title="https://src.fedoraproject.org/rpms/gnome-terminal">https://src.fedoraproject.org/rpms/gnome-terminal</a> has state "Unwatch"
for me, and has since definitely yesterday, perhaps longer, but I was
automatically added in CC to <a href="https://bugzilla.redhat.com/show_bug.cgi?i" title="https://bugzilla.redhat.com/show_bug.cgi?i">https://bugzilla.redhat.com/show_bug.cgi?i</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
equivalently.

who/where maintains http://mirrors.fedoraproject.org/releases.txt ?

<a href="http://mirrors.fedoraproject.org/releases.txt" title="http://mirrors.fedoraproject.org/releases.txt">http://mirrors.fedoraproject.org/releases.txt</a>

The fedora 16 section has
...mirrorlist?pub/...
while the other sections have
...mirrorlist?path=pub/...

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 ?

e.g.

<a href="http://koji.fedoraproject.org/koji/getfile?taskID=2589336&amp;name=build.log&amp;offset=-4000" title="http://koji.fedoraproject.org/koji/getfile?taskID=2589336&amp;name=build.log&amp;offset=-4000">http://koji.fedoraproject.org/koji/getfile?taskID=2589336&amp;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.

C.

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
compat-db47.

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="http://people.redhat.com/caolanm/ooocvs/mapabrtstack" title="http://people.redhat.com/caolanm/ooocvs/mapabrtstack">http://people.redhat.com/caolanm/ooocvs/mapabrtstack</a>

C.

A comps OpenOffice.org-devel group ?

As per <a href="http://fedoraproject.org/wiki/PackageMaintainers/CompsXml" title="http://fedoraproject.org/wiki/PackageMaintainers/CompsXml">http://fedoraproject.org/wiki/PackageMaintainers/CompsXml</a> I'm
wondering if a OpenOffice.org-development group makes sense for Comps ?

I see that openoffice.org-testtools and openoffice.org-pyuno 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.

C.

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="http://speakupmodified.org/HOWTO_INSTALL.html" title="http://speakupmodified.org/HOWTO_INSTALL.html">http://speakupmodified.org/HOWTO_INSTALL.html</a>

C.

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

So, <a href="https://bugzilla.redhat.com/show_bug.cgi?id=502226" title="https://bugzilla.redhat.com/show_bug.cgi?id=502226">https://bugzilla.redhat.com/show_bug.cgi?id=502226</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
subdirs.

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/foo.so will force sucking in a package
that provides /usr/lib/package/plugins/foo.so instead

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

cross-compilers...

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 ?

C.