It's a good idea. I thought about that briefly. Two problems
immediately came to mind that made me discard the idea:
a) for builds that are not from git we'd not know the commit count
(unless we glue that into the git release commit / tag - which I am
not sure we actually want, but is certainly a
The point is not to do a version compare against it, but to have the
actually available sha reported in the build logs.
e.g. cmake reports
```
-- Found KF5I18n:
/usr/lib/x86_64-linux-gnu/cmake/KF5I18n/KF5I18nConfig.cmake (found
version "5.64.0.abcd123")
```
On Thu, Dec 5, 2019 at 1:23 AM Kevin
Il giorno Thu, 05 Dec 2019 01:23:28 +0100
Kevin Kofler ha scritto:
> The git SHA is not going to work for this, because it is not
> monotonic. What you really want to know is whether you have something
> >= 5.65.0.abcd123, and having a 5.65.0.commithash version is not
> >going to tell you that.
Harald Sitter wrote:
> Random thought to make dependency problems more obvious: glue the git
> sha into the cmake package version for frameworks (when built from
> git) so it finds "5.65.0.abcd123" given us a lead on what is actually
> available.
The git SHA is not going to work for this, because
On Tue, Dec 3, 2019 at 8:55 PM Volker Krause wrote:
>
> On Sunday, 1 December 2019 04:00:19 CET Ben Cooksley wrote:
> > On Sun, Dec 1, 2019 at 10:17 AM Volker Krause wrote:
> > > On Saturday, 30 November 2019 19:14:38 CET Ben Cooksley wrote:
> [...]
> > > > Fixing the current set of failures
On Tuesday, 3 December 2019 22:13:43 CET Allen Winter wrote:
> On Tuesday, December 3, 2019 2:52:31 PM EST Volker Krause wrote:
> > The complexity of the dependency graph is also a problem for onboarding
> > new
> > people, and with kdelibs4support gone IMHO the largest technical dept
> > here.
>
On dinsdag 3 december 2019 22:13:43 CET Allen Winter wrote:
> On Tuesday, December 3, 2019 2:52:31 PM EST Volker Krause wrote:
> > The complexity of the dependency graph is also a problem for onboarding new
> > people, and with kdelibs4support gone IMHO the largest technical dept here.
> > It's
On Tuesday, December 3, 2019 2:52:31 PM EST Volker Krause wrote:
> The complexity of the dependency graph is also a problem for onboarding new
> people, and with kdelibs4support gone IMHO the largest technical dept here.
> It's being worked on, albeit slowly, currently we are losing ~1 module
On Sunday, 1 December 2019 04:00:19 CET Ben Cooksley wrote:
> On Sun, Dec 1, 2019 at 10:17 AM Volker Krause wrote:
> > On Saturday, 30 November 2019 19:14:38 CET Ben Cooksley wrote:
[...]
> > > Fixing the current set of failures will not prevent this blacklisting
> > > action from being carried
o improve the situation going forward
separately/later, I'm in a rush now, sorry).
Regards,
Volker
> > > In addition to all of the above, this round of updates was to lay the
> > > ground work for adding additional dependencies which are necessary for
> > > the builds o
tes was to lay the
> > ground work for adding additional dependencies which are necessary for
> > the builds of Digikam and SubtitleComposer to commence on the CI
> > system for Windows. These failures by PIM have therefore indirectly
> > harmed other KDE projects.
> >
&
ould therefore like to proceed with blacklisting PIM from
> the CI system. This would include prohibiting other projects from
> depending on any part of PIM, so those projects that have a required
> dependency on PIM would also have their builds removed by this.
Of course stuff tends to br
with blacklisting PIM from
the CI system. This would include prohibiting other projects from
depending on any part of PIM, so those projects that have a required
dependency on PIM would also have their builds removed by this.
Whilst I would prefer another solution to this, given that it is a
recurring issue
13 matches
Mail list logo
