Postings by Rex Dieter

gc-7.6.2 to rawhide, abi bump

Been putting it off, but finally going to work to bring gc-7.6.2 to rawhide,
includes a soname bump affecting

$ dnf repoquery --whatrequires gc --repoid=rawhide

Qt 5.10.1 coming to rawhide

Sorry for the late notice...

kde sig is working to import Qt 5.10.1 into rawhide starting today, so there
will be some related rawhide buildroot broken dependencies until this task
is complete

-- Rex

inject rpm dependency depending on library symbol?

I'm exploring possibilities on how to track usage of a particular library
symbol via rpm dependencies.

In particular, whenever a package is built that includes a dependency on
library symbol:

I'd like to inject additional dependencies, something like:
Requires: qt5-qtbase = %{_qt5_version}

I've been told debian does a variant of this, but I've not been able to come
up with any good way to do that here.

Orphaning ofono

I will be orphaning the ofono package today. I'd primarily packaged it with
the the intention that it may become a new dependency of pulseaudio (which
never happened), and I've not been able to give it the time it needs.

Recently updated to latest 1.22 release which fixed a long-standing FTBFS
issue, so at least it is in good shape for anyone interested in picking it

-- Rex

qt-5.9.1 coming to rawhide today

fyi, will be importing qt-5.9.1 into rawhide today. There may be temporary
periods of inconsistent dependencies while builds are underway, but it
should be sorted out quickly.

Please let us (kde-sig) know if anything breaks, thanks.

-- rex

orphaning lightdm-kde

fyi, I'm orphaning lightdm-kde (for rawhide/f27, probably too late for f26),
a kde4-based greeter for lightdm.

Main reasons include:
* I haven't personally used it in a long time
* there has been no upstream activity/development is over 3 years,
<a href="" title=""></a>

-- Rex

Qt 5.8 coming to rawhide

Mostly fyi/heads-up,

kde-sig members imported Qt 5.8 into git over the weekend (kudos to
heliocastro for initial packaging/copr and kkofler for merging import), and
bootstrap builds are under way.

orphaning clucene09

I'm orphaning clucene09 for f26+.

Reasons being mostly that it's FTBFS (and bundling requirements have relaxed
since it's introduction).

-- Rex

time to retire some kde4/smoke-based language bindings?

I was looking at rawhide (ppc64) broken deps, and was reminded of some
pretty old and unmaintained (upstream) kde4/smoke-based language bindings
(csharp, perl, ruby), affected packages include:


Of these, I can see *maybe* keeping perl-Qt (and dep smokeqt), primarily
because it is the only one in this list that's not a leaf package (debconf-
kde depends on it).

Any comments or objection to orphaning these for f26+ ?

-- Rex

orphaning virtuoso

I've been nmaintaining virtuoso-opensource primarily due to it being needed
by (kde) nepomuk, but as we've recently deprecated/retired nepomuk recently
in rawhide, I will be orphaning virtuoso (in the hopes that it finds a
better home).

-- Rex

deprecating nepomuk in f24+

kde-sig has tentative plans to remove support for kde4 nepomuk (starting
with f24).

What that means is soon kdelibs will be built without libnepomuk (and
friends), and packages:
will be eol'd.

Packages affected by this include:


bindings packages (smokekde, kimono, ruby-korundum, pykde4) will simply be
rebuilt with

qt (4) no longer injects $RPM_OPT_FLAGS by default (on f24+)

In response to recent additions to default $RPM_OPT_FLAGS that depend on
redhat-rpm-config to be present, and in response to bug
<a href="" title=""></a>

Qt4's qmake will no longer inject $RPM_OPT_FLAGS any more, starting with

Packages that use qmake will have to find some other mechanism, options
1. use %qmake_qt4 macro instead of calling qmake manually
2. set appropriate envrionment/qmake variables by hand
3. patch your buildsystem as needed
4. some better idea

Please let me know if you have any questions about this.

exiv2-0.25 coming to rawhide

I plan on updating rawhide to exiv2-0.25 this week, which involves a
soname bump, affected packages appended at the end.

I'll take care of necessary rebuilds.

-- Rex


GraphicsMagick-1.3.21: libGraphicsMagick++ soname bump

I'm planning in doing a GraphicsMagick-1.3.21 build for f22 soon (hopefully
by the end of this week), which includes a libGraphicsMagick++ soname bump
and affects the following packages:


Unless I hear otherwise, I can take care of doing all (re)builds and
submitting a batched update.

-- Rex

orphaning kmplayer

I'm orphaning the kmplayer package (for f22+), last release was ~3 years
ago, and it's project site @ <a href="" title=""></a> is no more.

(not sure if it's related at all to <a href="" title=""></a> , but that one
doesn't appear to be opensource)

-- Rex

recent/new Plasma5 crashes under investigation


KDE SIG is investigating some recent/serious reported crasher bugs in
rawhide, notably:

"Could not sync environment to dbus." (startkde)
<a href="" title=""></a>

and (an older one, but the situation has gotten worse recently):

Qt5 application crashes when connecting/disconnecting displays
<a href="" title=""></a>
<a href="" title=""></a>

Initial theories are that gcc5 landing may have something to do with it,
since the recent crashes go away reverting to pre-gcc5 builds of the same

More debugging

comps multimedia group: switch to gstreamer1 default?

I see comps' "multimedia" group still defaults to installing gstreamer-0.10
plugins (with gstreamer1 conditional). Any comments about switching this
the other way around?

Possible patch attached.

If I'd noticed earlier, I'd have advocated adjusting comps-f21 too, but I
figure it's a bit late in the cycle (unless others feel strongly otherwise).

-- Rex

p.s. not sure the origins of gstreamer-plugins-espeak, but that feels out of
place here (though I can't find any *better* place offhand, don't see any
accessibility-related groups)

fakesystemd package breaking builds

Seems the fakesystemd package is breaking some rawhide builds, particularly
because it is getting pulled into the buildroot and that it contains:
Conflicts: systemd

Example qt:
<a href="" title=""></a>

(which is no direct systemd dependencies, mind you)

I can guess why this fakesystemd package came into existence, but I question
the wisdom behind it's implementation.

defining firewalld services

I'm looking into providing a predefined firewalld service definition for
kde-connect, per
<a href="" title=""></a>

Looks like it's as easy as dropping an xml snippet into

I'm also noticing currently that the only package besides fallwalld itself
doing this is cockpit, which includes a %post scriptlet:

# firewalld only partially picks up changes to its services files
# without this
test -f %{_bindir}/firewall-cmd && firewall-cmd --reload --quiet || true

Is this the recommended approach?

kde-4.13.x update for f20

KDE SIG has been discussing moving forward with another kde x.y+1 update for
Fedora 20, largely due to it's extended lifetime (and f21's delayed
release), extending the same rationale per
<a href="" title=""></a>

There have been kde-4.13.1 packages available for testing and feedback in a
3rd-party kde-unstable repo (see
<a href="" title=""></a> ) for quite some time.

qt(4) header prefix moving to /usr/include/qt4

The KDE SIG is considering moving qt(4)'s default header prefix path from

Primary reasons for doing this is to help minimize conflicts between
anything qt5-based.

When/if this is implemented, Qt4-based library packages, those that provide
-devel subpkgs at least, will (likely) need a mass rebuild. I would likely
help do most of the heavy-lifting required to implement that.

Comments, objections?

-- Rex

SDDMinsteadOfKDM Change pushed back to f21

At the KDE SIG meeting today, we made the hard decision to push
<a href="" title=""></a>
change/feature back to f21. There were simply too many sddm-related
blocker issues that would not be safely resolvable in time for f20 release.

As such, effective immediately, we're implementing
<a href="" title=""></a>
to revert back to using kdm for f20 release.

kde-4.9.90 (4.10beta2) coming to rawhide

Just a quick heads-up, kde-sig will be working to import kde-4.9.90
(4.10beta2) into rawhide over the course of this week. Feel free to
poke me or any other kde-sig member in #fedora-devel or #fedora-kde if
you encounter anything out-of-sorts related to this.


-- rex

macros.cmake: set -DCMAKE_BUILD_TYPE=ReleaseWithDebInfo by default

See also,
<a href="" title=""></a>

orionp and I were discussing on irc today, the idea to add
to %cmake by default in /etc/rpm/macros.cmake , while making it easy to
set/override manually, similar to how %_cmake_lib_suffix64 is currently

the idea being that many cmake projects default to Release (or not,
sometimes goofy things like Debug)

The idea being that many projects default to CMAKE_BUILD_TYPE=Release and
end up pulling in -O3 (and -DNDEBUG).

There's 2 issues we'd like some wider input.

Review Request: Add pkgconfig hints to FindSamba.cmake

Review request for kdelibs.

Add pkgconfig hints to FindSamba.cmake, helps find samba4 libs on non-standard-ish locations.

cmake/modules/FindSamba.cmake 16522c6

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

Tested on fedora 18 against samba-4.0-rc2


Rex Dieter

DisplayManagerRework: how to handle upgrades?

OK, so we have
<a href="" title=""></a>

that tells one how to enable the display manager of your choice, via
systemctl enable --force xyzdm.service

But, how to handle upgrades? (or is this case already handled somehow?)

Off the top of my head, perhaps create some sort of scriptlet (probably to
live in initscripts, since that's what owned prefdm) to parse
/etc/sysconfig/desktop to make some educated guess about which dm service to


-- rex

hunspell-en not installed by default anymore

Seems as of f17, kde live image no longer has hunspell-en installed by
default anymore. I'm *guessing* it's due to comps-related changes dropping
<packagereq type="conditional" requires="hunspell">hunspell-en</packagereq>
in favor of yum-langpacks to handle it and that yum-langpacks doesn't get
used during spin creation.

Followup similar question is whether yum-langpacks gets used during non-live
anaconda installed either.

Anyway, what's the best way out of this mess? some options off the top of
my head:
1. hunspell re-add hard requirement on hunspell-en

KDE-SIG meeting report (26/2012)

This is a report of the weekly KDE-SIG-Meeting with a summary of the
topics that were discussed.

orphaning cmucl

I'm going to be orphaning cmucl, CMU Common Lisp

It's a i686-only lisp implementation, which I brought into fedora
primarily for maxima back in the day. Since it doesn't work all that
great with maxima anyway, and that it's i686-only (and I have only
x86_64 hardware/os these days), doesn't make much sense to carry on the

-- rex

exiv2-0.23 coming soon

I plan on importing exiv2-0.23 into rawhide soon'ish.