CI Requirements - Lessons Not Learnt?

[Martin Gräßlin]

Am 2017-01-05 16:11, schrieb Kevin Kofler:
> Ben Cooksley wrote:
> 
>> On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin wrote:
>>> It should be rather obvious that we don't introduce new dependencies
>>> because we like to. There is a very important software reason to it.
>>> That's the case for the xkbcommon dependency increase. Should I have 
>>> let
>>> the code broken as it was, expecting half a year of bug reports till
>>> build.kde.org has the base upgraded to Ubuntu 16.04?
>> 
>> That's what #ifdef is for...
> 
> +1

So you are also stepping up to maintain this! Awesome. If not please 
don't tell me anything about how to maintain KWin.

> 
> The new xkbcommon requirement is also an issue for us in Fedora. The 
> new
> xkbcommon 0.7.0 is only available in Rawhide and it is doubtful that it 
> will
> ever be backported to Fedora 25 or 24.

We are providing an LTS release for a reason. Please do not backport to 
older Fedora! It will have less support from upstream than 5.8.

> So, if we cannot get libxkbcommon
> updated, we will either be unable to provide your new Plasma releases 
> for
> our stable releases, or we will be forced to add a patch to revert your
> dependency bump, as we already had to do for Qt in the past:
> http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtbase.git/tree/qtbase-opensource-src-5.3.2-old_xkbcommon.patch?id=e26fd4ffda851bfe13d975547e218e16f72ce556
> (Yes, this reintroduced a bug. It was just not possible to fix that bug 
> with
> the xkbcommon that was available in the Fedora 19 release. Fedora 20
> eventually got the xkbcommon update, so we were able to drop this patch
> there. We still had to patch Qt for the old xcb-xkb (which could not be
> updated due to a soname bump) though.)
> 
>>> Similar for Mesa 13 which I'm also eagerly waiting for build.kde.org 
>>> to
>>> fetch it.
>> 
>> Mesa 13 is news to me.
> 
> This is also an issue for us: Mesa 13 is only available in Fedora 25
> (updates) and Rawhide, not in Fedora 24.

This is not an issue to you at all, because it is a runtime dependency 
of a system only used in tests.

Cheers
Martin