On Wednesday, June 29, 2016 11:11:42 PM CEST Ben Cooksley wrote: > 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.
Yeah, I know we discussed this before. I don't expect this to be enabled on the KDE CI, I'm just pointing out this is the reason we may be having more build failures than others.... > >> > 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) Well this is all related to the above, isn't it? Something we should be able to handle ourselves by rebuilding manually. > and sudden Qt version dependency > bumps without outside consultation. Right, that happened once and we said sorry already :-) > 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. I do "kdesrc-build kde-pimlibs kde-pim" quite often without any issues. If the devs don't contact us, we can hardly fix something.... > 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. Thanks, I triggered a rebuild of Akonadi-master. Dan > > > 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 -- 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
