[Kde-pim] Unannounced dependency bump?
Daniel Vrátil
dvratil at kde.org
Wed Jun 29 11:30:05 UTC 2016
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 <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.
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 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
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20160629/93177117/attachment-0001.sig>
More information about the release-team
mailing list