DevHeads.net

Postings by Rex Dieter

orphaning vnc-ltsp-config

Orphaning vnc-ltsp-config. Haven't used it in quite awhile and don't have
time to give it any love and attention.

-- Rex

linker errors (since binutils-2.30.90-1.fc29?) : _end: invalid version 21 (max 0), error adding symbols: bad value

See bug <a href="https://bugzilla.redhat.com/1599521" title="https://bugzilla.redhat.com/1599521">https://bugzilla.redhat.com/1599521</a>

Haven't been able to successfully build anything in rawhide recently.

-- Rex

Qt 5.9.6 for f27

fyi, I've begun work to bring Qt 5.9.6 LTS/bugfix release to fedora 27.

orphaning vnc-ltsp-config

Not something I have time or interest for awhile, so I'm orphaning it,
<a href="https://src.fedoraproject.org/rpms/vnc-ltsp-config" title="https://src.fedoraproject.org/rpms/vnc-ltsp-config">https://src.fedoraproject.org/rpms/vnc-ltsp-config</a>

-- Rex

Qt 5.11.0 to rawhide soon

Qt 5.11.0 will be coming to rawhide soon.

I'll be importing git sources first starting later today, and then proceed
to do requisite builds in a side koji target (
<a href="https://pagure.io/releng/issue/7516" title="https://pagure.io/releng/issue/7516">https://pagure.io/releng/issue/7516</a> ).

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
...
Macaulay2-0:1.9.2-8.fc28.x86_64
aisleriot-1:3.22.4-3.fc28.x86_64
asymptote-0:2.41-1.fc27.x86_64
autogen-0:5.18.12-6.fc28.x86_64
bigloo-0:4.3a-3.fc28.x86_64
bigloo-libs-0:4.3a-3.fc28.x86_64
clover2-0:3.6.1-1.D20180216gitb392824.fc28.x86_64
denemo-0:2.2.0-2.fc28.x86_64
ecl-0:16.1.3-5.fc28.x86_64
flint-0:2.5.2-18.fc28.x86_64
freehoo-0:3.5.3-25.20100314cvs.fc28.x86_64
gc-devel-0:7.6.0-8.fc28.i686
gc-devel-0:7.6.0-8.fc28.x86_64
gdb-

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:
libQt5Core.so.5(Qt_5_PRIVATE_API)

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
up.

-- 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="https://cgit.kde.org/lightdm.git/" title="https://cgit.kde.org/lightdm.git/">https://cgit.kde.org/lightdm.git/</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:

kdebindings
kimono
perl-Qt
ruby-korundum
ruby-qt
smokeqt
smokekde
qyoto

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:
nepomuk-core
nepomuk-widgets
will be eol'd.

Packages affected by this include:

nepomuk(kdelibs)

nepomuk-core:
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="http://bugzilla.redhat.com/1279265" title="http://bugzilla.redhat.com/1279265">http://bugzilla.redhat.com/1279265</a>

Qt4's qmake will no longer inject $RPM_OPT_FLAGS any more, starting with
qt-4.8.7-6.f24

Packages that use qmake will have to find some other mechanism, options
include:
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
library
soname bump, affected packages appended at the end.

I'll take care of necessary rebuilds.

-- Rex

calligra-0:2.9.5-1.fc23.src
darktable-0:1.6.7-1.fc23.src
geeqie-0:1.2-0.3.20141130gita1afabd.fc23.src
gegl-0:0.2.0-24.fc23.src
gegl03-0:0.3.0-3.fc23.src
gipfel-0:0.4.0-6.fc23.src
gnome-color-manager-0:3.16.0-2.fc23.src
gnome-commander-4:1.4.7-1.fc23.src
gpscorrelate-0:1.6.1-15.fc23.src
gthumb-1:3.4.0-2.fc23.src
gwenview-0:15.04.2-1.fc23.src
hugin-0:2014.0.0-6.fc23.src
immix-0:1.3.2-22.fc23.src
kde-runtime-0:15.04.2-1.

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:

gdl
octave
vdr
vdr-skinnopacity
vdr-tvguide

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="http://kmplayer.kde.org/" title="http://kmplayer.kde.org/">http://kmplayer.kde.org/</a> is no more.

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

-- Rex

recent/new Plasma5 crashes under investigation

FYI,

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

"Could not sync environment to dbus." (startkde)
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1191171" title="https://bugzilla.redhat.com/show_bug.cgi?id=1191171">https://bugzilla.redhat.com/show_bug.cgi?id=1191171</a>

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

Qt5 application crashes when connecting/disconnecting displays
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1083664" title="https://bugzilla.redhat.com/show_bug.cgi?id=1083664">https://bugzilla.redhat.com/show_bug.cgi?id=1083664</a>
<a href="https://bugreports.qt.io/browse/QTBUG-44388" title="https://bugreports.qt.io/browse/QTBUG-44388">https://bugreports.qt.io/browse/QTBUG-44388</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
packages.

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 comps-f22.xml.in 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="https://koji.fedoraproject.org/koji/taskinfo?taskID=7452802" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=7452802">https://koji.fedoraproject.org/koji/taskinfo?taskID=7452802</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="https://bugzilla.redhat.com/show_bug.cgi?id=1115547" title="https://bugzilla.redhat.com/show_bug.cgi?id=1115547">https://bugzilla.redhat.com/show_bug.cgi?id=1115547</a>

Looks like it's as easy as dropping an xml snippet into
/usr/lib/firewalld/services/

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="http://fedoraproject.org/wiki/SIGs/KDE/Update_policy" title="http://fedoraproject.org/wiki/SIGs/KDE/Update_policy">http://fedoraproject.org/wiki/SIGs/KDE/Update_policy</a>

There have been kde-4.13.1 packages available for testing and feedback in a
3rd-party kde-unstable repo (see
<a href="http://fedoraproject.org/wiki/SIGs/KDE/Testing" title="http://fedoraproject.org/wiki/SIGs/KDE/Testing">http://fedoraproject.org/wiki/SIGs/KDE/Testing</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
/usr/include
to
/usr/include/qt4

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="http://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM" title="http://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM">http://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM</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="http://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM#Contingency_Plan" title="http://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM#Contingency_Plan">http://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM#Contingency_Plan</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.

thanks.

-- rex

macros.cmake: set -DCMAKE_BUILD_TYPE=ReleaseWithDebInfo by default

See also,
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=875954" title="https://bugzilla.redhat.com/show_bug.cgi?id=875954">https://bugzilla.redhat.com/show_bug.cgi?id=875954</a>

orionp and I were discussing on irc today, the idea to add
-DCMAKE_BUILD_TYPE=ReleaseWithDebInfo
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
handled.

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.

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

Diffs
cmake/modules/FindSamba.cmake 16522c6

Diff: <a href="http://git.reviewboard.kde.org/r/106861/diff/" title="http://git.reviewboard.kde.org/r/106861/diff/">http://git.reviewboard.kde.org/r/106861/diff/</a>

Testing
Tested on fedora 18 against samba-4.0-rc2

Thanks,

Rex Dieter