Re: PIM versioning and dependencies
On Mon, Aug 28, 2017 at 11:09 AM, Albert Astals Cid wrote: > El diumenge, 27 d’agost de 2017, a les 16:00:29 CEST, Adriaan de Groot va > escriure: >> On Sunday 27 August 2017 22:40:18 Ben Cooksley wrote: >> > In the case of FreeBSD, those slaves are manually managed at the >> > moment so there is no easy outside way to check i'm afraid, aside from >> > examining the CMake output, which should include details on versions >> > which have been found. >> >> The FreeBSD CI builders have Qt 5.7, which is (as far as I know) the >> documented minimum required Qt version for KDE Frameworks. I assume that >> that is followed by the rest of KDE code unless well documented on a >> "required dependencies for this bit" wiki page. > > KDE Frameworks is on the "conservative" side, assuming Qt 5.7 is enough for > each and every of the KDE produced code is assuming too much. > > Projects are not depending on new versions of stuff just to annoy CI or > FreeBSD people, if they are using new verisons of stuff is because they need > them so that they software works better. > > Let's not forget we're all trying to make the world a better place by > delivering the best software we can. I was primarily referring to https://community.kde.org/Policies/Dependency_Changes_and_CI in my original mail. The dependency bump was not announced in advance leaving no space for discussion or anyone to mention the consequences of the bump. Which is why we have that policy and why i'd like the PIM developers to let us know why they skipped over it. > > Cheers, > Albert > >> >> [ade] > > Regards, Ben
Re: PIM versioning and dependencies
El diumenge, 27 d’agost de 2017, a les 16:00:29 CEST, Adriaan de Groot va escriure: > On Sunday 27 August 2017 22:40:18 Ben Cooksley wrote: > > In the case of FreeBSD, those slaves are manually managed at the > > moment so there is no easy outside way to check i'm afraid, aside from > > examining the CMake output, which should include details on versions > > which have been found. > > The FreeBSD CI builders have Qt 5.7, which is (as far as I know) the > documented minimum required Qt version for KDE Frameworks. I assume that > that is followed by the rest of KDE code unless well documented on a > "required dependencies for this bit" wiki page. KDE Frameworks is on the "conservative" side, assuming Qt 5.7 is enough for each and every of the KDE produced code is assuming too much. Projects are not depending on new versions of stuff just to annoy CI or FreeBSD people, if they are using new verisons of stuff is because they need them so that they software works better. Let's not forget we're all trying to make the world a better place by delivering the best software we can. Cheers, Albert > > [ade]
Re: PIM versioning and dependencies
On Sunday 27 August 2017 22:40:18 Ben Cooksley wrote: > In the case of FreeBSD, those slaves are manually managed at the > moment so there is no easy outside way to check i'm afraid, aside from > examining the CMake output, which should include details on versions > which have been found. The FreeBSD CI builders have Qt 5.7, which is (as far as I know) the documented minimum required Qt version for KDE Frameworks. I assume that that is followed by the rest of KDE code unless well documented on a "required dependencies for this bit" wiki page. [ade] signature.asc Description: This is a digitally signed message part.
Re: PIM versioning and dependencies
On Sun, Aug 27, 2017 at 8:47 PM, Daniel Vrátil wrote: > On Saturday, August 26, 2017 11:02:21 PM CEST Ben Cooksley wrote: >> Hi all, >> >> We have a little bit of an issue in PIM at the moment. It can be >> broken down into 3 separate issues, but overall from my perspective >> the PIM team is violating established practice in the community. >> >> The first issue concerns the dependency bump to Qt 5.8. This has not >> announced or discussed on any community wide list, either prior or >> after the bump was made. As a consequence of this, a series of >> Extragear applications which previously could be built on FreeBSD can >> no longer be built. > > Are the CI requirements for each platform documented somewhere? Where can we > see which versions of which dependencies we can use on each platform? In the case of Qt, it's part of the platform name on the CI system which is part of the job name. For everything else it's a bit more difficult as some of our images are based on rolling distributions. The versions for Linux images will be viewable in the latest "Docker Generate " job. A similar job called "Craft Cache Rebuild" is also available for Windows. In the case of FreeBSD, those slaves are manually managed at the moment so there is no easy outside way to check i'm afraid, aside from examining the CMake output, which should include details on versions which have been found. > >> The second issue concerns maintenance of our internal metadata files, >> which define the dependencies between various bits of KDE software. >> These files are used by the CI system to provision dependencies, and >> kdesrc-build to sequence items to be built. >> >> Since the last release was branched the PIM developers have added a >> new dependency to kdepim-runtime. This change happened well over a >> week ago, and they have yet to update the metadata files accordingly. >> While this may seem minor, if someone is trying to build a single >> application and it's corresponding dependencies they'll run into >> problems because neither the CI system or kdesrc-build will know about >> this new dependency they've added. > > My bad, I was convinced we were already building kdepim-runtime with libkgapi. > I have corrected it now. Thanks. > >> The third issue concerns the practice of version management within >> PIM. Currently the master branch of PIM is broken because it appears >> that one or more repositories have been missed in the latest round of >> bumping. > > All master versions are >= 5.6.40. Hmm, I don't see this commit at https://build.kde.org/job/Applications%20syndication%20kf5-qt5%20FedoraQt5.8/changes ? > > I see KBlog and Akregator build failed due missing Syndication dependency. > Looks like the Syndication build was triggered after KBlog and Akregator, > triggering a new build of those two should fix it. I've triggered a build now of all the "Dependency Build" jobs for Applications. These are special in that they rebuild everything that anything within it's given product/platform/branch group combination depends on. If there are any sequencing issues then those jobs will eliminate it, however they will take several hours to complete. (They start from ECM, working their way up through Frameworks and then everything else which is required, and don't reuse any previously built binaries) > > Looks like I lost the rights to manually trigger builds on CI after the > upgrade, so I can't fix it until we make a commit. I've now given you those rights. > > > Dan Cheers, Ben > >> >> Can the PIM developers please provide an explanation for these various >> breakages which they've made? >> >> Cheers, >> Ben > > > -- > Daniel Vrátil > www.dvratil.cz | dvra...@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
Re: PIM versioning and dependencies
On Saturday, August 26, 2017 11:02:21 PM CEST Ben Cooksley wrote: > Hi all, > > We have a little bit of an issue in PIM at the moment. It can be > broken down into 3 separate issues, but overall from my perspective > the PIM team is violating established practice in the community. > > The first issue concerns the dependency bump to Qt 5.8. This has not > announced or discussed on any community wide list, either prior or > after the bump was made. As a consequence of this, a series of > Extragear applications which previously could be built on FreeBSD can > no longer be built. Are the CI requirements for each platform documented somewhere? Where can we see which versions of which dependencies we can use on each platform? > The second issue concerns maintenance of our internal metadata files, > which define the dependencies between various bits of KDE software. > These files are used by the CI system to provision dependencies, and > kdesrc-build to sequence items to be built. > > Since the last release was branched the PIM developers have added a > new dependency to kdepim-runtime. This change happened well over a > week ago, and they have yet to update the metadata files accordingly. > While this may seem minor, if someone is trying to build a single > application and it's corresponding dependencies they'll run into > problems because neither the CI system or kdesrc-build will know about > this new dependency they've added. My bad, I was convinced we were already building kdepim-runtime with libkgapi. I have corrected it now. > The third issue concerns the practice of version management within > PIM. Currently the master branch of PIM is broken because it appears > that one or more repositories have been missed in the latest round of > bumping. All master versions are >= 5.6.40. I see KBlog and Akregator build failed due missing Syndication dependency. Looks like the Syndication build was triggered after KBlog and Akregator, triggering a new build of those two should fix it. Looks like I lost the rights to manually trigger builds on CI after the upgrade, so I can't fix it until we make a commit. Dan > > Can the PIM developers please provide an explanation for these various > breakages which they've made? > > Cheers, > Ben -- Daniel Vrátil www.dvratil.cz | dvra...@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 signature.asc Description: This is a digitally signed message part.
PIM versioning and dependencies
Hi all, We have a little bit of an issue in PIM at the moment. It can be broken down into 3 separate issues, but overall from my perspective the PIM team is violating established practice in the community. The first issue concerns the dependency bump to Qt 5.8. This has not announced or discussed on any community wide list, either prior or after the bump was made. As a consequence of this, a series of Extragear applications which previously could be built on FreeBSD can no longer be built. The second issue concerns maintenance of our internal metadata files, which define the dependencies between various bits of KDE software. These files are used by the CI system to provision dependencies, and kdesrc-build to sequence items to be built. Since the last release was branched the PIM developers have added a new dependency to kdepim-runtime. This change happened well over a week ago, and they have yet to update the metadata files accordingly. While this may seem minor, if someone is trying to build a single application and it's corresponding dependencies they'll run into problems because neither the CI system or kdesrc-build will know about this new dependency they've added. The third issue concerns the practice of version management within PIM. Currently the master branch of PIM is broken because it appears that one or more repositories have been missed in the latest round of bumping. Can the PIM developers please provide an explanation for these various breakages which they've made? Cheers, Ben
