D24826: Enforce 100 chars line width

[Allan Sandfeld Jensen]

carewolf added a comment.


  I agree. A limit of 100 is arbitrary and harmful. Unfortunately clang-format 
doesn't seem to have a way to make lines over a certain length less desirably, 
but still allowed if the break would be ugly, so it is better to just allow 
long lines.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D24826

To: romangg, #frameworks, cullmann
Cc: carewolf, winterz, zzag, kde-frameworks-devel, kde-buildsystem, LeGast00n, 
cblack, bencreasy, michaelh, ngraham, bruns

Re: KIO on Android Failure

[Ahmad Samir]

On 18/08/2020 13:52, Ben Cooksley wrote:

Hi all,

At some point recently functionality was added to KIO which broke the
build on Android.

I'm not sure why we're building KIO on Android, but it appears that
some applications may be using it - and this in turn causes the
Dependency Build jobs to fail.

Could someone take a look please?
https://build.kde.org/job/Administration/job/Docker%20Generate%20AndroidQt5.14%20KF5-SDK/lastFailedBuild/console

Thanks,
Ben



It looks like it's caused by systemd integration in kprocessrunner; also it seems Q_OS_UNIX includes 
Android systems, so we need to guard it with !defind(Q_OS_ANDROID). Should hopefully be fixed by 
https://invent.kde.org/frameworks/kio/-/merge_requests/107 .


--
Ahmad Samir

KDE CI: Frameworks » kirigami » kf5-qt5 FreeBSDQt5.15 - Build # 76 - Fixed!

[CI System]

BUILD SUCCESS
 Build URL
https://build.kde.org/job/Frameworks/job/kirigami/job/kf5-qt5%20FreeBSDQt5.15/76/
 Project:
kf5-qt5 FreeBSDQt5.15
 Date of build:
Tue, 18 Aug 2020 14:19:33 +
 Build duration:
20 min and counting
   JUnit Tests
  Name: projectroot.usr.home.jenkins.workspace.Frameworks.kirigami.kf5-qt5_FreeBSDQt515 Failed: 0 test(s), Passed: 9 test(s), Skipped: 0 test(s), Total: 9 test(s)

KDE CI: Frameworks » kirigami » kf5-qt5 FreeBSDQt5.15 - Build # 75 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kirigami/job/kf5-qt5%20FreeBSDQt5.15/75/
 Project:
kf5-qt5 FreeBSDQt5.15
 Date of build:
Tue, 18 Aug 2020 14:01:10 +
 Build duration:
18 min and counting
   JUnit Tests
  Name: projectroot.usr.home.jenkins.workspace.Frameworks.kirigami.kf5-qt5_FreeBSDQt515 Failed: 2 test(s), Passed: 7 test(s), Skipped: 0 test(s), Total: 9 test(s)Failed: projectroot.usr.home.jenkins.workspace.Frameworks.kirigami.kf5-qt5_FreeBSDQt515.autotests.tst_keynavigation.qmlFailed: projectroot.usr.home.jenkins.workspace.Frameworks.kirigami.kf5-qt5_FreeBSDQt515.autotests.tst_listskeynavigation.qml

KIO on Android Failure

[Ben Cooksley]

Hi all,

At some point recently functionality was added to KIO which broke the
build on Android.

I'm not sure why we're building KIO on Android, but it appears that
some applications may be using it - and this in turn causes the
Dependency Build jobs to fail.

Could someone take a look please?
https://build.kde.org/job/Administration/job/Docker%20Generate%20AndroidQt5.14%20KF5-SDK/lastFailedBuild/console

Thanks,
Ben

Re: Extend metainfo.yaml files with License Information

[Andreas Cord-Landwehr]

On Dienstag, 18. August 2020 12:34:42 CEST Harald Sitter wrote:
[...]
> > Ouch, yes, the obvious choice, no idea why I did not see that by myself :)
> > Yes, SPDX expressions should be the obvious way to go IMO. For the
> > questions: - for libraries, I agree that the target name should be
> > easiest
> > - for plugins, we could use the library name as it is still a shared
> > object
> > - for applications, we could use the executable name
> > - for anything that is "not changed but only installed" during the
> > compile/
> > install steps, I would say for now that those are out of scope
> > In my understanding, we should strive for encoding all artifacts, but if
> > we
> > miss some we do not state something wrong. Moreover, what we state there
> > should be covered by automated tests (see link above).
> 
> It all sounds reasonable to me.
> 
> I'm pipedreaming a bit ... but given the ultimate goal of stringing
> artifacts to licenses maybe a thing to consider is to actually encode
> this stuff as cmake properties on the actual cmake targets. Perhaps
> not as a first step, but as a longer term goal. The cmake targets
> already know the output name of their artifact is (resolving the
> what-do-we-call-it problem), they also know which sources contribute
> to a target (improving the context capabilities for api.kde.org + the
> plausability tooling could actually look at the targets rather than
> the explicit list of files which of course are subject to human
> error).
> 
> https://cmake.org/cmake/help/latest/command/define_property.html#command:def
> ine_property https://cmake.org/cmake/help/latest/prop_tgt/SOURCES.html

Yeah, I full agree!

In my opinion adding these information to the yaml files is a first step, which 
allows to work separately on the build system tooling part and the API 
documentation part. Actually, for the very same reason 
ecm_check_outbound_license already has a FILES parameter, which later could be 
simply replaced by a TARGET parameter to retrieve files automatically form a 
target ;)

To extend your pipedreaming, I even hope to get same standardized format out 
of this, which simply is generated by an arbitrary build system... :)

As first incremental step, I will prepare a MR for adding functionality to 
api.kde.org and a PoC yaml file for some of the repositories.

Cheers,
Andreas

Re: Extend metainfo.yaml files with License Information

[Harald Sitter]

On Mon, Aug 17, 2020 at 8:24 PM Andreas Cord-Landwehr
 wrote:
>
> Thanks! I will answer inline:
>
> On Montag, 17. August 2020 17:47:40 CEST Harald Sitter wrote:
> [...]
> > > **First question:** Shall we only list ONE or ALL licenses, same for the
> > > license information overview that should be on api.kde.org?
> >
> > The primary use would be api.kde.org, no? A third party looks for a
> > solution to hardware shenanigans with Qt and finds the solid docs and
> > the solid docs say "you may use this thingy under LGPL-2.1". If so,
> > then surely we ought to encode all artifacts and their licensing
> > terms. What's more,. the artifact a given class belongs to becomes
> > relevant and I guess that's a bit tricky to sort out.
>
> api.kde.org will be the first user, but I already see more in the pipeline:
> - for this plausibility tooling 
>  I 
> would love to get a connection of the
> CMake target name and the stated outbound license
> - for Yocto recipes we already have to state the licenses by hand and it
> should not be too hard to generate the Yocto information from a Yaml file
> - in the long term I expect that this is what is useful for packages, who
> currently mostly look at the source files and have to guess
>
> > > Now, I am wondering about the best approach to encode something like this
> > > into the metainfo.yaml. I am currently considering a structure as
> > > follows:
> > >
> > > Attica's metainfo.yaml
> > > [...]
> > >
> > > outboundLicenses:
> > > libattica:
> > > - LGPL-2.1-only
> > > - LGPL-3.0-only
> > >
> > > Baloo's metainfo.yaml
> > > [...]
> > >
> > > outboundLicenses:
> > > libbaloo:
> > > - LGPL-2.1-only
> > > - LGPL-3.0-only
> > >
> > > baloo-kioslave:
> > > - GPL-2.0-only
> >
> > Why not actually use a SPDX expression? `LGPL-2.1-only OR LGPL-3.0-only`.
> >
> > Some additional concerns that come to mind:
> > - what 's the actual artifact name? for libraries we already have a
> > target name so I guess we might just use that so for example that'd be
> > KF5::Baloo. What about plugins or binaries though?
> > - how would we make sure all artifacts are encoded? do we want to even?
>
> Ouch, yes, the obvious choice, no idea why I did not see that by myself :)
> Yes, SPDX expressions should be the obvious way to go IMO. For the questions:
> - for libraries, I agree that the target name should be easiest
> - for plugins, we could use the library name as it is still a shared object
> - for applications, we could use the executable name
> - for anything that is "not changed but only installed" during the compile/
> install steps, I would say for now that those are out of scope
> In my understanding, we should strive for encoding all artifacts, but if we
> miss some we do not state something wrong. Moreover, what we state there
> should be covered by automated tests (see link above).

It all sounds reasonable to me.

I'm pipedreaming a bit ... but given the ultimate goal of stringing
artifacts to licenses maybe a thing to consider is to actually encode
this stuff as cmake properties on the actual cmake targets. Perhaps
not as a first step, but as a longer term goal. The cmake targets
already know the output name of their artifact is (resolving the
what-do-we-call-it problem), they also know which sources contribute
to a target (improving the context capabilities for api.kde.org + the
plausability tooling could actually look at the targets rather than
the explicit list of files which of course are subject to human
error).

https://cmake.org/cmake/help/latest/command/define_property.html#command:define_property
https://cmake.org/cmake/help/latest/prop_tgt/SOURCES.html

HS