Re: New(ish) Framework review: kstatusnotifieritem

[Albert Astals Cid]

El dimecres, 16 d’agost de 2023, a les 13:35:44 (CEST), Nicolas Fella va 
escriure:
> Hi,
> 
> at the last meeting we decided to extract KStatusNotifierItem from
> KNotifications into a separate Framework.
> 
> Reasons are:
> 
> - They are rather distinct in scope/concept
> 
> - They negatively affect each other's dependencies
> 
> I've now created https://invent.kde.org/frameworks/kstatusnotifieritem
> and started porting users of KStatusNotifierItem to it.
> 
> Given that this is 100% pre-existing Frameworks code I don't think an
> in-depth "new framework review" is really appropriate, but if you have
> important and/or actionable points then we can of course discuss them.

It's missing a Messages.sh file

Cheers,
  Albert

> 
> Cheers
> 
> Nico

Re: Per project repository snapcraft files?

[Scarlett Moore]

On Fri, Aug 18, 2023, 12:53 PM Ben Cooksley  wrote:

> On Sat, Aug 19, 2023 at 7:45 AM Nicolas Fella 
> wrote:
>
>> Am 18.08.23 um 21:41 schrieb Ben Cooksley:
>>
>> On Fri, Aug 18, 2023 at 10:17 PM Scarlett Moore <
>> scarlett.gately.mo...@gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Aug 18, 2023, 12:55 AM Ben Cooksley  wrote:
>>>
 On Fri, Aug 18, 2023 at 3:53 AM Scarlett Moore <
 scarlett.gately.mo...@gmail.com> wrote:

> Hello everyone,
>

 Hey Scarlett,


> I am asking to revisit per project repo snapcraft files. I see now
> that flatpak files are in project repos but I understand this was
> rejected for snapcraft. I would like to re-propose the idea, and here
> is why.
> The CI jobs for snap builds is cludgy at best. We have huge amounts of
> failures because we must do a public upload to launchpad which places
> us at the lowest priority and we have many timeouts etc. Their
> solution is to create proper snap recipes pointing to our repos with
> the snapcraft.yaml. Our current setup won't work because we use
> subdirectories in one repo.
> Thoughts?
>

 My understanding (when automating the triggering of these builds on
 invent.kde.org was discussed with Sysadmin) was that the Snap folks
 had wanted to have everything in one repository.
 I had queried at the time why we weren't adding a file into each
 repository (which is what we do with Flatpak, and now with Craft as well -
 although those builds have yet to be widely rolled out)

 With regards to the triggering of these builds, how will this happen?
 It sounds like what you are describing here will result in Canonical
 servers polling invent.kde.org for changes, which is something we're
 not huge fans of as most projects only change every couple of days.


>
> Thanks for your time,
> Scarlett
>

 Cheers,
 Ben

>>>
>>>
>>> Hi!
>>>
>>> Thanks all for responding.
>>>
>>> Albert: snapcraft files have been ironed out. I have been quite busy
>>> over the last year doing so.
>>>
>>> Ben: There is an option to have launchpad build on changes which would
>>> have polling. However, I would opt out of this feature and instead write
>>> some tooling using launchpad API and Neons watcher tooling to update
>>> versions and trigger launchpad builds. It would actually lighten the load
>>> on KDE servers significantly.
>>>
>>
>> Yes, we would definitely want to opt out of that completely - due to the
>> number of repositories we have, any kind of polling quickly turns into a
>> fairly significant number of requests.
>>
>> Wouldn't you want to trigger this from a .gitlab-ci.yml job definition
>> though like we do for Flatpak and will be doing very soon for all of the
>> Craft builds that support Android, Windows and Linux appimage binaries?
>>
>> I am definitely game for following a standard and do what everyone else
is doing. Just point me to instructions and I will do it.
Thanks!
Scarlett

> I was about to ask how the "future binary-factory" on invent will look
>> like and suggest to follow that precedent. Can you elaborate on that? Will
>> these be jobs in the relevant repos or will there be a meta-repo with all
>> of the "release" jobs?
>>
>
> The jobs will be sitting in the relevant repositories in a separate stage
> to the current CI.
> There will not be a meta repo for this.
>
> Individual applications for Craft will configure any extra behaviour they
> need via a .craft.ini file at top level in the repository, on the branch in
> question that the behaviour change is needed.
> This is keeping in line with how our CI works (with .kde-ci.yml) and the
> Flatpak builds work (with .flatpak-manifest.json/yml).
>
> Yet to be fully worked out how the triggering of them will be setup,
> whether it will be automatic or whether it will be manually run but that is
> an implementation detail.
>
> Cheers,
> Ben
>

Re: Per project repository snapcraft files?

[Ben Cooksley]

On Sat, Aug 19, 2023 at 7:45 AM Nicolas Fella  wrote:

> Am 18.08.23 um 21:41 schrieb Ben Cooksley:
>
> On Fri, Aug 18, 2023 at 10:17 PM Scarlett Moore <
> scarlett.gately.mo...@gmail.com> wrote:
>
>>
>>
>> On Fri, Aug 18, 2023, 12:55 AM Ben Cooksley  wrote:
>>
>>> On Fri, Aug 18, 2023 at 3:53 AM Scarlett Moore <
>>> scarlett.gately.mo...@gmail.com> wrote:
>>>
 Hello everyone,

>>>
>>> Hey Scarlett,
>>>
>>>
 I am asking to revisit per project repo snapcraft files. I see now
 that flatpak files are in project repos but I understand this was
 rejected for snapcraft. I would like to re-propose the idea, and here
 is why.
 The CI jobs for snap builds is cludgy at best. We have huge amounts of
 failures because we must do a public upload to launchpad which places
 us at the lowest priority and we have many timeouts etc. Their
 solution is to create proper snap recipes pointing to our repos with
 the snapcraft.yaml. Our current setup won't work because we use
 subdirectories in one repo.
 Thoughts?

>>>
>>> My understanding (when automating the triggering of these builds on
>>> invent.kde.org was discussed with Sysadmin) was that the Snap folks had
>>> wanted to have everything in one repository.
>>> I had queried at the time why we weren't adding a file into each
>>> repository (which is what we do with Flatpak, and now with Craft as well -
>>> although those builds have yet to be widely rolled out)
>>>
>>> With regards to the triggering of these builds, how will this happen?
>>> It sounds like what you are describing here will result in Canonical
>>> servers polling invent.kde.org for changes, which is something we're
>>> not huge fans of as most projects only change every couple of days.
>>>
>>>

 Thanks for your time,
 Scarlett

>>>
>>> Cheers,
>>> Ben
>>>
>>
>>
>> Hi!
>>
>> Thanks all for responding.
>>
>> Albert: snapcraft files have been ironed out. I have been quite busy over
>> the last year doing so.
>>
>> Ben: There is an option to have launchpad build on changes which would
>> have polling. However, I would opt out of this feature and instead write
>> some tooling using launchpad API and Neons watcher tooling to update
>> versions and trigger launchpad builds. It would actually lighten the load
>> on KDE servers significantly.
>>
>
> Yes, we would definitely want to opt out of that completely - due to the
> number of repositories we have, any kind of polling quickly turns into a
> fairly significant number of requests.
>
> Wouldn't you want to trigger this from a .gitlab-ci.yml job definition
> though like we do for Flatpak and will be doing very soon for all of the
> Craft builds that support Android, Windows and Linux appimage binaries?
>
> I was about to ask how the "future binary-factory" on invent will look
> like and suggest to follow that precedent. Can you elaborate on that? Will
> these be jobs in the relevant repos or will there be a meta-repo with all
> of the "release" jobs?
>

The jobs will be sitting in the relevant repositories in a separate stage
to the current CI.
There will not be a meta repo for this.

Individual applications for Craft will configure any extra behaviour they
need via a .craft.ini file at top level in the repository, on the branch in
question that the behaviour change is needed.
This is keeping in line with how our CI works (with .kde-ci.yml) and the
Flatpak builds work (with .flatpak-manifest.json/yml).

Yet to be fully worked out how the triggering of them will be setup,
whether it will be automatic or whether it will be manually run but that is
an implementation detail.

Cheers,
Ben

Re: Per project repository snapcraft files?

[Nicolas Fella]

Am 18.08.23 um 21:41 schrieb Ben Cooksley:

On Fri, Aug 18, 2023 at 10:17 PM Scarlett Moore
 wrote:



On Fri, Aug 18, 2023, 12:55 AM Ben Cooksley  wrote:

On Fri, Aug 18, 2023 at 3:53 AM Scarlett Moore
 wrote:

Hello everyone,


Hey Scarlett,

I am asking to revisit per project repo snapcraft files. I
see now
that flatpak files are in project repos but I understand
this was
rejected for snapcraft. I would like to re-propose the
idea, and here
is why.
The CI jobs for snap builds is cludgy at best. We have
huge amounts of
failures because we must do a public upload to launchpad
which places
us at the lowest priority and we have many timeouts etc. Their
solution is to create proper snap recipes pointing to our
repos with
the snapcraft.yaml. Our current setup won't work because
we use
subdirectories in one repo.
Thoughts?


My understanding (when automating the triggering of these
builds on invent.kde.org  was discussed
with Sysadmin) was that the Snap folks had wanted to have
everything in one repository.
I had queried at the time why we weren't adding a file into
each repository (which is what we do with Flatpak, and now
with Craft as well - although those builds have yet to be
widely rolled out)

With regards to the triggering of these builds, how will this
happen?
It sounds like what you are describing here will result in
Canonical servers polling invent.kde.org
 for changes, which is something we're
not huge fans of as most projects only change every couple of
days.


Thanks for your time,
Scarlett


Cheers,
Ben



Hi!

Thanks all for responding.

Albert: snapcraft files have been ironed out. I have been quite
busy over the last year doing so.

Ben: There is an option to have launchpad build on changes which
would have polling. However, I would opt out of this feature and
instead write some tooling using launchpad API and Neons watcher
tooling to update versions and trigger launchpad builds. It would
actually lighten the load on KDE servers significantly.


Yes, we would definitely want to opt out of that completely - due to
the number of repositories we have, any kind of polling quickly turns
into a fairly significant number of requests.

Wouldn't you want to trigger this from a .gitlab-ci.yml job definition
though like we do for Flatpak and will be doing very soon for all of
the Craft builds that support Android, Windows and Linux appimage
binaries?

I was about to ask how the "future binary-factory" on invent will look
like and suggest to follow that precedent. Can you elaborate on that?
Will these be jobs in the relevant repos or will there be a meta-repo
with all of the "release" jobs?

Re: Per project repository snapcraft files?

[Ben Cooksley]

On Fri, Aug 18, 2023 at 10:17 PM Scarlett Moore <
scarlett.gately.mo...@gmail.com> wrote:

>
>
> On Fri, Aug 18, 2023, 12:55 AM Ben Cooksley  wrote:
>
>> On Fri, Aug 18, 2023 at 3:53 AM Scarlett Moore <
>> scarlett.gately.mo...@gmail.com> wrote:
>>
>>> Hello everyone,
>>>
>>
>> Hey Scarlett,
>>
>>
>>> I am asking to revisit per project repo snapcraft files. I see now
>>> that flatpak files are in project repos but I understand this was
>>> rejected for snapcraft. I would like to re-propose the idea, and here
>>> is why.
>>> The CI jobs for snap builds is cludgy at best. We have huge amounts of
>>> failures because we must do a public upload to launchpad which places
>>> us at the lowest priority and we have many timeouts etc. Their
>>> solution is to create proper snap recipes pointing to our repos with
>>> the snapcraft.yaml. Our current setup won't work because we use
>>> subdirectories in one repo.
>>> Thoughts?
>>>
>>
>> My understanding (when automating the triggering of these builds on
>> invent.kde.org was discussed with Sysadmin) was that the Snap folks had
>> wanted to have everything in one repository.
>> I had queried at the time why we weren't adding a file into each
>> repository (which is what we do with Flatpak, and now with Craft as well -
>> although those builds have yet to be widely rolled out)
>>
>> With regards to the triggering of these builds, how will this happen?
>> It sounds like what you are describing here will result in Canonical
>> servers polling invent.kde.org for changes, which is something we're not
>> huge fans of as most projects only change every couple of days.
>>
>>
>>>
>>> Thanks for your time,
>>> Scarlett
>>>
>>
>> Cheers,
>> Ben
>>
>
>
> Hi!
>
> Thanks all for responding.
>
> Albert: snapcraft files have been ironed out. I have been quite busy over
> the last year doing so.
>
> Ben: There is an option to have launchpad build on changes which would
> have polling. However, I would opt out of this feature and instead write
> some tooling using launchpad API and Neons watcher tooling to update
> versions and trigger launchpad builds. It would actually lighten the load
> on KDE servers significantly.
>

Yes, we would definitely want to opt out of that completely - due to the
number of repositories we have, any kind of polling quickly turns into a
fairly significant number of requests.

Wouldn't you want to trigger this from a .gitlab-ci.yml job definition
though like we do for Flatpak and will be doing very soon for all of the
Craft builds that support Android, Windows and Linux appimage binaries?
The Neon watcher stuff is more intended for actually packaged releases from
what I understand.


>
> Thank you for your time,
> Scarlett
>

Cheers,
Ben

Re: Review of Codevis (ie - Making Codevis a KDE Project)

[Ben Cooksley]

On Sat, Aug 19, 2023 at 3:37 AM Tomaz Canabrava  wrote:

> (some help / I need to set the default branch to master, from main,
> because the tooling doesn't accept the later, I don't think I have the
> permission to do that).
>

That has been done now.

Cheers,
Ben


>
> On Fri, Aug 18, 2023 at 5:10 PM Tomaz Canabrava 
> wrote:
>
>> Small update that the CI is now fully passing.
>>
>> On Fri, Aug 18, 2023 at 2:25 PM Tomaz Canabrava 
>> wrote:
>>
>>> Carl, Sysadmins:
>>>
>>> The current error on the KDE ci is this:
>>>
>>> Looking for clang tool headers at /usr/lib64/clang/16.0.6/include. You
>>> can change this by defining CT_CLANG_HEADERS_DIR
>>> CMake Error at CMakeLists.txt:87 (message):
>>> Cannot find clang tool headers at /usr/lib64/clang/16.0.6/include
>>> -- Configuring incomplete, errors occurred!
>>>
>>> (to which I understand that carl said there's an error with Clang6. This
>>> is not an error - it basically says that we are unable to find `stddef.h`
>>> on the  path `${LLVM_LIBRARY_DIR}/clang/${LLVM_PACKAGE_VERSION}/include`
>>>
>>> This is needed for the tool to run properly, but not compile, so I
>>> removed the FATAL from the message.
>>>
>>> On Thu, Aug 17, 2023 at 6:51 PM Tomaz Canabrava 
>>> wrote:
>>>


 On Thu, 17 Aug 2023 at 18:29 Carl Schwan  wrote:

> On Thursday, August 17, 2023 11:18:24 AM CEST Tomaz Canabrava wrote:
> > Hello Fellow KDE Devs,
> >
> > I'm here, formally asking for a review of the Codevis project, to
> move
> > forward and make it a part of kdesdk.
>
> Very cool project, I was amazed by the presentation of it from
> tarcisio at
> Akademy.
>
> > Currently we are using parts of KWdigetsAddons as a submodule
> > Most things that are related to buildsystems will be moved to craft /
> > kdesrc-build as soon as possible, right now we rely in conan for
> windows
> > and mac, plus a hand-written build script that downloads and builds
> llvm
> > for those platforms.
> >
> > Things that I know that are out of KDE Accordance:
> > - Translation System (uses Qt's tr() system)
>
> This isn't an issue and we have other KDE projects using the tr()
> system. But
> if you want to port to ki18n, it's best to do it now since you don't
> seems to
> have any translations yet.
>
> > - Settings System (it uses my own configuration parser that
> resembles QML)
>
> Yeah probably best to use kconfigxt or make your configuration parser
> part of
> kconfigxt next gen ;)
>
> > - Folder naming specification (follows the lakosian naming
> specification)
>
> I don't think we have any folder (and file) naming specification in
> kde, or at
> least if we have one, it varies a lot between projects.
>
> > - CI used is based on Gitlab, but fails on KDE
>
> When trying to build it on my laptop it failed, due to the requirement
> of
> clang 16. This might also be an issue with the kde ci on tumbleweed.


 Carl,

 There’s no requirement for clang16 (I build with 15, tarcisio builds
 with 14, the previous ci had 13, I believe)

 Mind if you share the build logs?

 Best




>
> > The current repository of Codevis is:
> > https://invent.kde.org/tcanabrava/codevis
> >
> > The KDE developers on this project are me, tarcisio fischer (that
> presented
> > Codevis on Akademy), and Richard Dale.
> >
> > Best regards,
> > Tomaz
>
>

Re: Review of Codevis (ie - Making Codevis a KDE Project)

[Tomaz Canabrava]

(some help / I need to set the default branch to master, from main, because
the tooling doesn't accept the later, I don't think I have the permission
to do that).

On Fri, Aug 18, 2023 at 5:10 PM Tomaz Canabrava  wrote:

> Small update that the CI is now fully passing.
>
> On Fri, Aug 18, 2023 at 2:25 PM Tomaz Canabrava 
> wrote:
>
>> Carl, Sysadmins:
>>
>> The current error on the KDE ci is this:
>>
>> Looking for clang tool headers at /usr/lib64/clang/16.0.6/include. You
>> can change this by defining CT_CLANG_HEADERS_DIR
>> CMake Error at CMakeLists.txt:87 (message):
>> Cannot find clang tool headers at /usr/lib64/clang/16.0.6/include
>> -- Configuring incomplete, errors occurred!
>>
>> (to which I understand that carl said there's an error with Clang6. This
>> is not an error - it basically says that we are unable to find `stddef.h`
>> on the  path `${LLVM_LIBRARY_DIR}/clang/${LLVM_PACKAGE_VERSION}/include`
>>
>> This is needed for the tool to run properly, but not compile, so I
>> removed the FATAL from the message.
>>
>> On Thu, Aug 17, 2023 at 6:51 PM Tomaz Canabrava 
>> wrote:
>>
>>>
>>>
>>> On Thu, 17 Aug 2023 at 18:29 Carl Schwan  wrote:
>>>
 On Thursday, August 17, 2023 11:18:24 AM CEST Tomaz Canabrava wrote:
 > Hello Fellow KDE Devs,
 >
 > I'm here, formally asking for a review of the Codevis project, to move
 > forward and make it a part of kdesdk.

 Very cool project, I was amazed by the presentation of it from tarcisio
 at
 Akademy.

 > Currently we are using parts of KWdigetsAddons as a submodule
 > Most things that are related to buildsystems will be moved to craft /
 > kdesrc-build as soon as possible, right now we rely in conan for
 windows
 > and mac, plus a hand-written build script that downloads and builds
 llvm
 > for those platforms.
 >
 > Things that I know that are out of KDE Accordance:
 > - Translation System (uses Qt's tr() system)

 This isn't an issue and we have other KDE projects using the tr()
 system. But
 if you want to port to ki18n, it's best to do it now since you don't
 seems to
 have any translations yet.

 > - Settings System (it uses my own configuration parser that resembles
 QML)

 Yeah probably best to use kconfigxt or make your configuration parser
 part of
 kconfigxt next gen ;)

 > - Folder naming specification (follows the lakosian naming
 specification)

 I don't think we have any folder (and file) naming specification in
 kde, or at
 least if we have one, it varies a lot between projects.

 > - CI used is based on Gitlab, but fails on KDE

 When trying to build it on my laptop it failed, due to the requirement
 of
 clang 16. This might also be an issue with the kde ci on tumbleweed.
>>>
>>>
>>> Carl,
>>>
>>> There’s no requirement for clang16 (I build with 15, tarcisio builds
>>> with 14, the previous ci had 13, I believe)
>>>
>>> Mind if you share the build logs?
>>>
>>> Best
>>>
>>>
>>>
>>>

 > The current repository of Codevis is:
 > https://invent.kde.org/tcanabrava/codevis
 >
 > The KDE developers on this project are me, tarcisio fischer (that
 presented
 > Codevis on Akademy), and Richard Dale.
 >
 > Best regards,
 > Tomaz

Re: Review of Codevis (ie - Making Codevis a KDE Project)

[Tomaz Canabrava]

Small update that the CI is now fully passing.

On Fri, Aug 18, 2023 at 2:25 PM Tomaz Canabrava  wrote:

> Carl, Sysadmins:
>
> The current error on the KDE ci is this:
>
> Looking for clang tool headers at /usr/lib64/clang/16.0.6/include. You can
> change this by defining CT_CLANG_HEADERS_DIR
> CMake Error at CMakeLists.txt:87 (message):
> Cannot find clang tool headers at /usr/lib64/clang/16.0.6/include
> -- Configuring incomplete, errors occurred!
>
> (to which I understand that carl said there's an error with Clang6. This
> is not an error - it basically says that we are unable to find `stddef.h`
> on the  path `${LLVM_LIBRARY_DIR}/clang/${LLVM_PACKAGE_VERSION}/include`
>
> This is needed for the tool to run properly, but not compile, so I removed
> the FATAL from the message.
>
> On Thu, Aug 17, 2023 at 6:51 PM Tomaz Canabrava 
> wrote:
>
>>
>>
>> On Thu, 17 Aug 2023 at 18:29 Carl Schwan  wrote:
>>
>>> On Thursday, August 17, 2023 11:18:24 AM CEST Tomaz Canabrava wrote:
>>> > Hello Fellow KDE Devs,
>>> >
>>> > I'm here, formally asking for a review of the Codevis project, to move
>>> > forward and make it a part of kdesdk.
>>>
>>> Very cool project, I was amazed by the presentation of it from tarcisio
>>> at
>>> Akademy.
>>>
>>> > Currently we are using parts of KWdigetsAddons as a submodule
>>> > Most things that are related to buildsystems will be moved to craft /
>>> > kdesrc-build as soon as possible, right now we rely in conan for
>>> windows
>>> > and mac, plus a hand-written build script that downloads and builds
>>> llvm
>>> > for those platforms.
>>> >
>>> > Things that I know that are out of KDE Accordance:
>>> > - Translation System (uses Qt's tr() system)
>>>
>>> This isn't an issue and we have other KDE projects using the tr()
>>> system. But
>>> if you want to port to ki18n, it's best to do it now since you don't
>>> seems to
>>> have any translations yet.
>>>
>>> > - Settings System (it uses my own configuration parser that resembles
>>> QML)
>>>
>>> Yeah probably best to use kconfigxt or make your configuration parser
>>> part of
>>> kconfigxt next gen ;)
>>>
>>> > - Folder naming specification (follows the lakosian naming
>>> specification)
>>>
>>> I don't think we have any folder (and file) naming specification in kde,
>>> or at
>>> least if we have one, it varies a lot between projects.
>>>
>>> > - CI used is based on Gitlab, but fails on KDE
>>>
>>> When trying to build it on my laptop it failed, due to the requirement
>>> of
>>> clang 16. This might also be an issue with the kde ci on tumbleweed.
>>
>>
>> Carl,
>>
>> There’s no requirement for clang16 (I build with 15, tarcisio builds with
>> 14, the previous ci had 13, I believe)
>>
>> Mind if you share the build logs?
>>
>> Best
>>
>>
>>
>>
>>>
>>> > The current repository of Codevis is:
>>> > https://invent.kde.org/tcanabrava/codevis
>>> >
>>> > The KDE developers on this project are me, tarcisio fischer (that
>>> presented
>>> > Codevis on Akademy), and Richard Dale.
>>> >
>>> > Best regards,
>>> > Tomaz
>>>
>>>

Re: Review of Codevis (ie - Making Codevis a KDE Project)

[Tomaz Canabrava]

Carl, Sysadmins:

The current error on the KDE ci is this:

Looking for clang tool headers at /usr/lib64/clang/16.0.6/include. You can
change this by defining CT_CLANG_HEADERS_DIR
CMake Error at CMakeLists.txt:87 (message):
Cannot find clang tool headers at /usr/lib64/clang/16.0.6/include
-- Configuring incomplete, errors occurred!

(to which I understand that carl said there's an error with Clang6. This is
not an error - it basically says that we are unable to find `stddef.h` on
the  path `${LLVM_LIBRARY_DIR}/clang/${LLVM_PACKAGE_VERSION}/include`

This is needed for the tool to run properly, but not compile, so I removed
the FATAL from the message.

On Thu, Aug 17, 2023 at 6:51 PM Tomaz Canabrava  wrote:

>
>
> On Thu, 17 Aug 2023 at 18:29 Carl Schwan  wrote:
>
>> On Thursday, August 17, 2023 11:18:24 AM CEST Tomaz Canabrava wrote:
>> > Hello Fellow KDE Devs,
>> >
>> > I'm here, formally asking for a review of the Codevis project, to move
>> > forward and make it a part of kdesdk.
>>
>> Very cool project, I was amazed by the presentation of it from tarcisio
>> at
>> Akademy.
>>
>> > Currently we are using parts of KWdigetsAddons as a submodule
>> > Most things that are related to buildsystems will be moved to craft /
>> > kdesrc-build as soon as possible, right now we rely in conan for windows
>> > and mac, plus a hand-written build script that downloads and builds llvm
>> > for those platforms.
>> >
>> > Things that I know that are out of KDE Accordance:
>> > - Translation System (uses Qt's tr() system)
>>
>> This isn't an issue and we have other KDE projects using the tr() system.
>> But
>> if you want to port to ki18n, it's best to do it now since you don't
>> seems to
>> have any translations yet.
>>
>> > - Settings System (it uses my own configuration parser that resembles
>> QML)
>>
>> Yeah probably best to use kconfigxt or make your configuration parser
>> part of
>> kconfigxt next gen ;)
>>
>> > - Folder naming specification (follows the lakosian naming
>> specification)
>>
>> I don't think we have any folder (and file) naming specification in kde,
>> or at
>> least if we have one, it varies a lot between projects.
>>
>> > - CI used is based on Gitlab, but fails on KDE
>>
>> When trying to build it on my laptop it failed, due to the requirement of
>> clang 16. This might also be an issue with the kde ci on tumbleweed.
>
>
> Carl,
>
> There’s no requirement for clang16 (I build with 15, tarcisio builds with
> 14, the previous ci had 13, I believe)
>
> Mind if you share the build logs?
>
> Best
>
>
>
>
>>
>> > The current repository of Codevis is:
>> > https://invent.kde.org/tcanabrava/codevis
>> >
>> > The KDE developers on this project are me, tarcisio fischer (that
>> presented
>> > Codevis on Akademy), and Richard Dale.
>> >
>> > Best regards,
>> > Tomaz
>>
>>

Re: Per project repository snapcraft files?

[Scarlett Moore]

On Fri, Aug 18, 2023, 12:55 AM Ben Cooksley  wrote:

> On Fri, Aug 18, 2023 at 3:53 AM Scarlett Moore <
> scarlett.gately.mo...@gmail.com> wrote:
>
>> Hello everyone,
>>
>
> Hey Scarlett,
>
>
>> I am asking to revisit per project repo snapcraft files. I see now
>> that flatpak files are in project repos but I understand this was
>> rejected for snapcraft. I would like to re-propose the idea, and here
>> is why.
>> The CI jobs for snap builds is cludgy at best. We have huge amounts of
>> failures because we must do a public upload to launchpad which places
>> us at the lowest priority and we have many timeouts etc. Their
>> solution is to create proper snap recipes pointing to our repos with
>> the snapcraft.yaml. Our current setup won't work because we use
>> subdirectories in one repo.
>> Thoughts?
>>
>
> My understanding (when automating the triggering of these builds on
> invent.kde.org was discussed with Sysadmin) was that the Snap folks had
> wanted to have everything in one repository.
> I had queried at the time why we weren't adding a file into each
> repository (which is what we do with Flatpak, and now with Craft as well -
> although those builds have yet to be widely rolled out)
>
> With regards to the triggering of these builds, how will this happen?
> It sounds like what you are describing here will result in Canonical
> servers polling invent.kde.org for changes, which is something we're not
> huge fans of as most projects only change every couple of days.
>
>
>>
>> Thanks for your time,
>> Scarlett
>>
>
> Cheers,
> Ben
>


Hi!

Thanks all for responding.

Albert: snapcraft files have been ironed out. I have been quite busy over
the last year doing so.

Ben: There is an option to have launchpad build on changes which would have
polling. However, I would opt out of this feature and instead write some
tooling using launchpad API and Neons watcher tooling to update versions
and trigger launchpad builds. It would actually lighten the load on KDE
servers significantly.

Thank you for your time,
Scarlett

>

Re: Per project repository snapcraft files?

[Ben Cooksley]

On Fri, Aug 18, 2023 at 3:53 AM Scarlett Moore <
scarlett.gately.mo...@gmail.com> wrote:

> Hello everyone,
>

Hey Scarlett,


> I am asking to revisit per project repo snapcraft files. I see now
> that flatpak files are in project repos but I understand this was
> rejected for snapcraft. I would like to re-propose the idea, and here
> is why.
> The CI jobs for snap builds is cludgy at best. We have huge amounts of
> failures because we must do a public upload to launchpad which places
> us at the lowest priority and we have many timeouts etc. Their
> solution is to create proper snap recipes pointing to our repos with
> the snapcraft.yaml. Our current setup won't work because we use
> subdirectories in one repo.
> Thoughts?
>

My understanding (when automating the triggering of these builds on
invent.kde.org was discussed with Sysadmin) was that the Snap folks had
wanted to have everything in one repository.
I had queried at the time why we weren't adding a file into each repository
(which is what we do with Flatpak, and now with Craft as well - although
those builds have yet to be widely rolled out)

With regards to the triggering of these builds, how will this happen?
It sounds like what you are describing here will result in Canonical
servers polling invent.kde.org for changes, which is something we're not
huge fans of as most projects only change every couple of days.


>
> Thanks for your time,
> Scarlett
>

Cheers,
Ben