On Wed, Jun 29, 2016 at 10:49 PM, Daniel Vrátil <[email protected]> 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 [email protected] >> > https://mail.kde.org/mailman/listinfo/kde-pim >> > KDE PIM home page at http://pim.kde.org/ >> >> _______________________________________________ >> KDE PIM mailing list [email protected] >> https://mail.kde.org/mailman/listinfo/kde-pim >> KDE PIM home page at http://pim.kde.org/ > > > -- > Daniel Vrátil > www.dvratil.cz | [email protected] > IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) > > GPG Key: 0x4D69557AECB13683 > Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
