CI Requirements - Lessons Not Learnt?

David Faure faure at
Thu Jan 5 09:00:02 GMT 2017

On jeudi 5 janvier 2017 21:44:23 CET Ben Cooksley wrote:
> Hi all,
> It seems that my previous vocal complaints about system level /
> serious impact dependency bumps on the CI system have gone completely
> unnoticed by (some) members of our Community.
> This was demonstrated earlier this week when components of Plasma
> bumped their version requirements for XKBCommon and Appstream-Qt -
> without even a thought about notifying Sysadmin or checking which
> version the CI had, until their builds broke.
> Neither of these is easy to fix at this stage, as the system base is
> now too old to receive updates such as these. Base upgrades require a
> full rebuild of everything on the CI system, and usually involve
> significant additional churn and is a process that must be done
> roughly twice a year, depending on dependency bump demands.
> Does anyone have any suggestions as to how we may avoid this in the future?
> At this point i'm in favour of if you don't follow the rules your
> dependency bump just gets reverted out of existence, then you get to
> go through the process properly...

I agree that this is very annoying, it broke my own builds too and I complained
to Martin Graesslin already ;)

One thing though: note that you don't need to upgrade the base system to
get a newer xkbcommon. It's a lib that can be installed into a custom prefix.

My kdesrc-buildrc simply has this additional block, which solved the local compiling issue:

# OpenSuSE Leap 42.2 has libxkbcommon-devel-0.6.1-1.4.x86_64, but kwin requires 0.7
module libxkbcommon
  repository git at
  tag xkbcommon-0.7.0
end module

But you're asking about the more general issue of how to avoid breaking the CI,
and that indeed requires people to notify sysadmins when upgrading requirements.

David Faure, faure at,
Working on KDE Frameworks 5

More information about the kde-core-devel mailing list