[Kde-pim] Unannounced dependency bump?

[Ben Cooksley]

On Wed, Jun 29, 2016 at 10:49 PM, Daniel Vrátil <dvratil at kde.org> wrote:
> On Wednesday, June 29, 2016 12:24:10 PM CEST laurent Montel wrote:
>> Le mercredi 29 juin 2016, 21:02:24 CEST Ben Cooksley a écrit :
>> > Hi all,
>> >
>> > It would appear that PIM has bumped it's Grantlee dependency without
>> > any announcement.
>> >
>> > Failing that, commits are missing from one or more of the PIM family
>> > of repositories, the build metadata is out of date, or the CMake
>> > infrastructure of the PIM repositories is insufficient to work within
>> > the CI environment.
>> >
>> > Please see
>> > https://build.kde.org/view/FAILED/job/messagelib%20master%20kf5-qt5/325/PL
>> > A
>> > TFORM=Linux,compiler=gcc/console
>> >
>> > Please correct this and provide an explanation for the issue.
>>
>> The problem is a grantleetheme problem. It was a bad commit.
>> It's fixed.
>
> Note that GrantleeTheme is our internal library.
>
>>
>> > PIM buildability continues to be an ongoing and major issue -
>
> Excluding honest mistakes like this one, our only issue is with build order
> due to API changes across modules. If I break API in one module and push a fix
> to another module that depends on the new API, it will break if it finishes
> before the first one. If I wait with pushing the API adjustment in the other
> module but someone else triggers the build anyway, we have the same problem.
> We cannot prevent this easily unless the CI can ensure build order....

Something we can't do (imagine what would happen if kcoreaddons was
building - everything else would sit waiting for it to finish and so
on down the line).

The Jenkins mechanism for this is known as Upstream/Downstream jobs -
and I believe if the information is made available then Jenkins will
wait for upstream builds to finish and trigger downstream builds (a
main reason why we don't have this setup - a kcoreaddons build would
trigger a full CI rebuild effectively, something which takes many
hours).

You can already see that mechanism at work for part of Frameworks, and
the cascade that creates.

>
>> > at this
>> > point i'm considering whether we need to expel PIM from the mainline
>> > release modules to playground.
>
> I'd like to point out that Plasma 5.7 is currently way more broken than our
> stable release on the CI. Should we consider moving Plasma to playground as
> well....?

Do note that PIM has required Sysadmin intervention to fix it's CI on
enough occasions that i've lost count, due to CMake library version
bumps, unnecessary so-version bumps, binary incompatibility (requring
intermediary libraries to be rebuilt) and sudden Qt version dependency
bumps without outside consultation. It's not only CI that has issues
with PIM buildability as well - other KDE developers have issues with
it as well often being the sole source of failures in their
kdesrc-build runs.

In regards to Plasma - i've already discussed that with them, their
breakages are due to dependence on Qt 5.6 which the stable-kf5-qt5
branch group doesn't have available as it runs 5.5. The change in
stable-kf5-qt5 branch groups was normal - they're preparing for a
release I believe. This is something which will be fixed.

>
>> I think that we don't make error when we don't work!
>> So yep there is some CI error but we fix them.
>>
>> If you want to remove it from CI not a problem for me.
>
> Yeah, let's not do that. We need the CI to catch problems like this one and
> run our tests...
>
> ...speaking of which, Qt on the CI is broken: Cannot mix incompatible Qt
> library (version 0x50601) with this library (version 0x50602)
>
> https://build.kde.org/view/KDE-PIM/job/messagelib%20master%20kf5-qt5/327/
> PLATFORM=Linux,compiler=gcc/testReport/junit/(root)/TestSuite/
> akonadi_sqlite_followupreminderselectdatedialogtest/

Probably needs a rebuild of Akonadi - newer Qt won't like the plugin
being built against an older Qt even when it's within the same patch
version family.
Qt is known to be binary incompatible like this across even patch
releases (i've no idea why they enforce this silly restriction)

The installation of given dependencies is guaranteed to be consistent
by the method the CI system uses to build, install and distribute
projects - so this isn't within the installation of Qt.
Between projects though is another story - the Akonadi SQLite plugin
likely being the cause here.

>
> Cheers,
> Dan

Regards,
Ben

>
>>
>> Regards
>>
>> > Regards,
>> > Ben
>> > _______________________________________________
>> > KDE PIM mailing list kde-pim at kde.org
>> > https://mail.kde.org/mailman/listinfo/kde-pim
>> > KDE PIM home page at http://pim.kde.org/
>>
>> _______________________________________________
>> KDE PIM mailing list kde-pim at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-pim
>> KDE PIM home page at http://pim.kde.org/
>
>
> --
> Daniel Vrátil
> www.dvratil.cz | dvratil at kde.org
> IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)
>
> GPG Key: 0x4D69557AECB13683
> Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/