Re: "Gardening" old bugreports

[Justin]

Hi Nicolas,

This has been discussed with Nate Graham directly who has approved this 
cleanup of Bugzilla including the messaging behind it.


I am happy to discuss any concerns that people have around this. I 
understand Krita requested we exclude them from any gardening and that 
has been done, however this is the only feedback I have received.


The gardening team aims to find out if the bug reports are still 
relevant by involving the users who reported them in determining if they 
are still valid. This increases community involvement and helps KDE as 
there isn't anywhere near enough manpower to review the thousands upon 
thousands of bugs that haven't been touched in years.


The bugs that we are interacting with are ones that have not had any 
activity for over 2 years. We are simply trying to reinvigorate 
discussion on those bugs to see if they are still valid. If the user 
does not reply within the standard 30 day period after a bug is set to 
NEEDSINFO, it is automatically closed by the Bug Janitor.


I am not simply closing bugs, so I do take offense that care is not applied.

I will halt it until it is approved by more developers. However if it is 
decided that it isn't wanted then the KDE as a whole will need to entice 
more people in sorting old bugs individually as it is clearly not a 
priority right now for the majority.


Regards,

Justin

On 19/1/23 11:05, Nicolas Fella wrote:

Hi,

can we please put the effort of "gardening" old bugreports on hold until
we figured out whether this is actually something we want to do? Several
people already expressed concerns about this.

Improperly applied such mass changes can do more harm than good. We may
close bugreports that are actually still useful just because nobody
replied on then in a relatively short timeframe.

Properly cleaning up old bugreports is important. However, it requires
some level of care and expertise to judge whether a bugreport is still
useful. Judging by the volume of bugreports that is pinged with the same
copy&paste message this care is not  applied here.

At minimum such initiatives should be announced and discussed before
doing them, to allow people to give their input on the proposal. I am
not aware of any such announcement/discussion.

Cheers

Nicolas

Re: "Gardening" old bugreports

[Justin]

He mentioned that the activity he was getting on the reports was just 
noise to him and was ignoring them. So instead of causing more noise for 
him, I have excluded reports made by him. If he'd like to continue 
receiving them I'm happy to work on them.


On 28/1/23 08:51, Neal Gompa wrote:

On Fri, Jan 27, 2023 at 4:57 PM Justin Zobel  wrote:

Thanks for the feedback, everyone.

Given the distribution of positive vs negative feedback, we plan to
resume automatic bug triage of old non-wishlist bugs that have not
been updated in over 2 years. If you would like to opt your product
out of this initiative because you're able to keep on top of the
manual bug triage work, please let us know and we'll be happy to
accommodate you.

Exclusions so far:
- okteta
- krita
- any bug reported by sit...@kde.org


Hold up, what? Why is Harald being excluded?

Re: "Gardening" old bugreports

[Justin]

Hi Juraj,

Of course we are happy to exclude Falkon from the list.

Regards,

Justin

On 28/1/23 23:45, Juraj Oravec wrote:

Hello,


Exclusions so far:
- okteta
- krita
- any bug reported by sit...@kde.org

Thanks again for the feedback!

Can you also add Falkon to the exclusion list?
There are not that many bugs nor people working on it and at the moment
it is easy to browse the bugs.

Also I do not know if this was discussed, but some info message on the
bugzilla would be nice, if this project is managed by this BugBot or
not.

Thank you for the help.

Best regards,
Juraj.





On piatok 27. januára 2023 22:56:09 CET Justin Zobel wrote:

Thanks for the feedback, everyone.

Given the distribution of positive vs negative feedback, we plan to
resume automatic bug triage of old non-wishlist bugs that have not
been updated in over 2 years. If you would like to opt your product
out of this initiative because you're able to keep on top of the
manual bug triage work, please let us know and we'll be happy to
accommodate you.

Exclusions so far:
- okteta
- krita
- any bug reported by sit...@kde.org

Thanks again for the feedback!

On Sun, Jan 22, 2023 at 6:10 PM Thomas Baumgart 

wrote:

On Donnerstag, 19. Januar 2023 22:39:45 CET Johannes Zarl-Zierl

wrote:

Hi,

Am Donnerstag, 19. Jänner 2023, 12:26:08 CET schrieb Nicolas

Fella:

Am 19.01.23 um 04:04 schrieb Justin:

The gardening team aims to find out if the bug reports are
still
relevant by involving the users who reported them in
determining if
they are still valid. This increases community involvement and
helps
KDE as there isn't anywhere near enough manpower to review the
thousands upon thousands of bugs that haven't been touched in
years.

Anecdotally many people don't like such automated changes being
done to their bugreports that don't actually engage with the
content of the report.> >

Well, anecdotally you will mostly get feedback from people who
don't like it. Unless something is exceptionally great, few
people will take the time to speak out in favor of something that
is already happening.


The bugs that we are interacting with are ones that have not
had any
activity for over 2 years. We are simply trying to
reinvigorate
discussion on those bugs to see if they are still valid. If
the user
does not reply within the standard 30 day period after a bug
is set to NEEDSINFO, it is automatically closed by the Bug
Janitor.

I am not simply closing bugs, so I do take offense that care
is not
applied.

Properly "triaging" old reports requires at least some level of
understanding of the project, codebase etc. I'm afraid there is
no
simple solution to that and rule-based approaches aren't good
enough.
Even taking things like CONFIRMED status or wishlist priority
into
account assumes that these have actually been consistently
applied.

As a maintainer on a small project, I'm quite happy to get an
occasional nudge on old reports. Yes, I do occasionally go over
old reports to see if they are still valid, but having somebody
else doing this methodically makes sure I don't gloss over some
bug that could be closed or fixed.

Having this done by someone else without too much internal
knowledge is an absolute plus in my opinion. After all, if you
want to clean up your attic, you try to find a helper who does
not have the same emotional attachment as yourself.


I will halt it until it is approved by more developers.
However if it
is decided that it isn't wanted then the KDE as a whole will
need to
entice more people in sorting old bugs individually as it is
clearly
not a priority right now for the majority.

Speaking for KPhotoAlbum, I really appreciate the bugzilla
gardening. Thank you for doing it!

I can second that for the KMyMoney project. An occasional poke and
the automated cleanup when no response arrives where it is needed
helps a lot.


--

Regards

Thomas Baumgart

-
With every day I come closer to the grave and learn something new.
It all happens because I have wandered around too much and stumbled
into the Linux world - which is a fantastic place to be! (Algis
Kabaila †)
-

Re: About joining KDE on element

[Justin]

On February 3, 2025 5:45:24 AM GMT+10:30, Srishty Mangutte 
 wrote:
>Hello,
>I'm trying to join KDE server on element, but shows that registrations are
>closed
>how should I create an account here?
>Here is the window screenshot:
>[image: Screenshot_20250203_004100.png]
>
>In docs it's given that we can login using any homeserver but as you can
>see in screenshot, it only shows kde sever option
>https://community.kde.org/Matrix
>
>Please provide with a solution, looking forward to hearing from you.
>
>Respectfully,
>Srishty M
>srishtymangu...@gmail.com

You can join the Matrix rooms from other servers. You don't need a KDE Matrix 
server account.

Re: About joining KDE on element

[Justin]

On February 3, 2025 5:45:24 AM GMT+10:30, Srishty Mangutte 
 wrote:
>Hello,
>I'm trying to join KDE server on element, but shows that registrations are
>closed
>how should I create an account here?
>Here is the window screenshot:
>[image: Screenshot_20250203_004100.png]
>
>In docs it's given that we can login using any homeserver but as you can
>see in screenshot, it only shows kde sever option
>https://community.kde.org/Matrix
>
>Please provide with a solution, looking forward to hearing from you.
>
>Respectfully,
>Srishty M
>srishtymangu...@gmail.com

Click where it says KDE and it's underlined.

Licensing - KGet

[Justin Zobel]

Hey Team,

Been doing bug triage on bugs.kde.org and I came across this one. I'm
not going to touch it as licensing is a delicate subject.

Can someone familiar with or working on the kget team please action
this ticket, thanks.

https://bugs.kde.org/show_bug.cgi?id=330881

Regards,

Justin

Re: New releases for bugfixes

[Justin Zobel]

Same here, I like the idea of point releases to fix impactful bugs.

On Thu, Aug 25, 2022 at 6:56 PM Harald Sitter  wrote:

> make sense to me
>
> On Thu, Aug 25, 2022 at 6:55 PM Nate Graham  wrote:
> >
> > Hello everyone,
> > Right now when we fix a significant bug in our software that may take a
> > while to reach users to to the release schedule of its repo, we contact
> > distros and ask them to backport it. This puts the burden on distros to
> > react to us. I'm wondering how people feel about KDE instead making
> > immediate point releases ourselves. Thus we would take responsibility
> > for releasing fixes for our own regressions, and distros that monitor
> > KDE infrastructure for new tarballs could be notified automatically.
> >
> > Thoughts?
> >
> > Nate
>

Re: "Gardening" old bugreports

[Justin Zobel]

Wishlist items are already excluded for all projects.

On Thu, 19 Jan 2023, 7:39 pm David Jarvie,  wrote:

> I don't think that wishlist items should be treated in the same way as
> actual bugs. Even if the original reporter is no longer interested in a
> wishlist report or is no longer contactable, the feature asked for may
> still be valid.
>
> For KAlarm at least, please exclude wishlist reports from gardening
> processes.
>
> On 19 January 2023 06:17:23 GMT, AnnoyingRains 
> wrote:
>>
>> Also, note that we can provide exceptions when doing this, like we have
>> done with Krita, (excluded from both MR and bug report cleanup). If you
>> would like your project to be excluded, just let us know!
>>
>> Thanks
>> - Kye Potter, KDE Gardening
>>
>> On Thu, 19 Jan 2023 at 5:07 pm, Laurent Montel  wrote:
>>
>>> Hi,
>>> For pim* it’s ok for me.
>>> We have a very old bug, but pim* changed a lot.
>>> Or some apps are dead (blogilo etc.)
>>> A lot of bug report are duplicated or obsolete.
>>>
>>> Thanks for doing it.
>>> Regards
>>>
>>> Le jeudi 19 janvier 2023, 04:04:45 CET Justin a écrit :
>>> > Hi Nicolas,
>>> >
>>> > This has been discussed with Nate Graham directly who has approved this
>>> > cleanup of Bugzilla including the messaging behind it.
>>> >
>>> > I am happy to discuss any concerns that people have around this. I
>>> > understand Krita requested we exclude them from any gardening and that
>>> > has been done, however this is the only feedback I have received.
>>> >
>>> > The gardening team aims to find out if the bug reports are still
>>> > relevant by involving the users who reported them in determining if
>>> they
>>> > are still valid. This increases community involvement and helps KDE as
>>> > there isn't anywhere near enough manpower to review the thousands upon
>>> > thousands of bugs that haven't been touched in years.
>>> >
>>> > The bugs that we are interacting with are ones that have not had any
>>> > activity for over 2 years. We are simply trying to reinvigorate
>>> > discussion on those bugs to see if they are still valid. If the user
>>> > does not reply within the standard 30 day period after a bug is set to
>>> > NEEDSINFO, it is automatically closed by the Bug Janitor.
>>> >
>>> > I am not simply closing bugs, so I do take offense that care is not
>>> applied.
>>> >
>>> > I will halt it until it is approved by more developers. However if it
>>> is
>>> > decided that it isn't wanted then the KDE as a whole will need to
>>> entice
>>> > more people in sorting old bugs individually as it is clearly not a
>>> > priority right now for the majority.
>>> >
>>> > Regards,
>>> >
>>> > Justin
>>> >
>>> > On 19/1/23 11:05, Nicolas Fella wrote:
>>> > > Hi,
>>> > >
>>> > > can we please put the effort of "gardening" old bugreports on hold
>>> until
>>> > > we figured out whether this is actually something we want to do?
>>> Several
>>> > > people already expressed concerns about this.
>>> > >
>>> > > Improperly applied such mass changes can do more harm than good. We
>>> may
>>> > > close bugreports that are actually still useful just because nobody
>>> > > replied on then in a relatively short timeframe.
>>> > >
>>> > > Properly cleaning up old bugreports is important. However, it
>>> requires
>>> > > some level of care and expertise to judge whether a bugreport is
>>> still
>>> > > useful. Judging by the volume of bugreports that is pinged with the
>>> same
>>> > > copy&paste message this care is not  applied here.
>>> > >
>>> > > At minimum such initiatives should be announced and discussed before
>>> > > doing them, to allow people to give their input on the proposal. I am
>>> > > not aware of any such announcement/discussion.
>>> > >
>>> > > Cheers
>>> > >
>>> > > Nicolas
>>>
>>>
>>> --
>>> Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software
>>> Engineer
>>> KDAB (France) S.A.S., a KDAB Group company
>>> Tel: France +33 (0)4 90 84 08 53, http://www.kdab.fr
>>> KDAB - The Qt, C++ and OpenGL Experts
>>>
>>>
>>> --
> David Jarvie
> KAlarm author, KDE developer
>

Re: "Gardening" old bugreports

[Justin Zobel]

I'll have a look when I'm back at my PC and see if I can exclude bugs
reported by you.

On Thu, 19 Jan 2023, 8:57 pm Harald Sitter,  wrote:

> On Thu, Jan 19, 2023 at 4:05 AM Justin  wrote:
> > The gardening team aims to find out if the bug reports are still
> > relevant by involving the users who reported them in determining if they
> > are still valid.
>
> FWIW that probably doesn't work nearly as well as one would hope when
> the user is a developer. I for one just ignore the entire flood of
> ping comments. I'm 99% certain bugs I have reported have been closed
> as collateral damage.
>
> HS
>

Re: "Gardening" old bugreports

[Justin Zobel]

We can do that but not all developers use a KDE email address.

On Thu, 19 Jan 2023, 9:15 pm AnnoyingRains,  wrote:

> Actually, what if we just ignore reports that come from a *@kde.org email
> address?
>
> On Thu, 19 Jan 2023 at 9:42 pm, Justin Zobel 
> wrote:
>
>> I'll have a look when I'm back at my PC and see if I can exclude bugs
>> reported by you.
>>
>> On Thu, 19 Jan 2023, 8:57 pm Harald Sitter,  wrote:
>>
>>> On Thu, Jan 19, 2023 at 4:05 AM Justin  wrote:
>>> > The gardening team aims to find out if the bug reports are still
>>> > relevant by involving the users who reported them in determining if
>>> they
>>> > are still valid.
>>>
>>> FWIW that probably doesn't work nearly as well as one would hope when
>>> the user is a developer. I for one just ignore the entire flood of
>>> ping comments. I'm 99% certain bugs I have reported have been closed
>>> as collateral damage.
>>>
>>> HS
>>>
>>

Re: "Gardening" old bugreports

[Justin Zobel]

In the regard then it falls to developers with the understanding of the
codebase to triage these.

However it's clear due to the age of these bugs that most developers don't
have time or aren't prioritising these reports.

This is why I've volunteered time to try get engagement happening with
community (the bug reporters) to help confirm these issues still exist and
if they do, try and encourage evolvement from the project maintainers.

Regards,

Justin

On Thu, 19 Jan 2023, 9:56 pm Nicolas Fella,  wrote:

> Hi,
>
> Am 19.01.23 um 04:04 schrieb Justin:
> > Hi Nicolas,
> >
> > This has been discussed with Nate Graham directly who has approved
> > this cleanup of Bugzilla including the messaging behind it.
>
> KDE consists of more than Nate tough. We discuss and "review" things in
> the open.
>
> >
> > I am happy to discuss any concerns that people have around this. I
> > understand Krita requested we exclude them from any gardening and that
> > has been done, however this is the only feedback I have received.
> >
> > The gardening team aims to find out if the bug reports are still
> > relevant by involving the users who reported them in determining if
> > they are still valid. This increases community involvement and helps
> > KDE as there isn't anywhere near enough manpower to review the
> > thousands upon thousands of bugs that haven't been touched in years.
>
> Anecdotally many people don't like such automated changes being done to
> their bugreports that don't actually engage with the content of the report.
>
> >
> > The bugs that we are interacting with are ones that have not had any
> > activity for over 2 years. We are simply trying to reinvigorate
> > discussion on those bugs to see if they are still valid. If the user
> > does not reply within the standard 30 day period after a bug is set to
> > NEEDSINFO, it is automatically closed by the Bug Janitor.
> >
> > I am not simply closing bugs, so I do take offense that care is not
> > applied.
>
> Properly "triaging" old reports requires at least some level of
> understanding of the project, codebase etc. I'm afraid there is no
> simple solution to that and rule-based approaches aren't good enough.
> Even taking things like CONFIRMED status or wishlist priority into
> account assumes that these have actually been consistently applied.
>
> >
> > I will halt it until it is approved by more developers. However if it
> > is decided that it isn't wanted then the KDE as a whole will need to
> > entice more people in sorting old bugs individually as it is clearly
> > not a priority right now for the majority.
> >
> > Regards,
> >
> > Justin
> >
> Don't get me wrong, I do appreciate the initiative of cleaning up bugs.
> But we do need to handle this with a lot of care to avoid it backfiring.
>
> Cheers
>
> Nico
>
>
> > On 19/1/23 11:05, Nicolas Fella wrote:
> >> Hi,
> >>
> >> can we please put the effort of "gardening" old bugreports on hold until
> >> we figured out whether this is actually something we want to do? Several
> >> people already expressed concerns about this.
> >>
> >> Improperly applied such mass changes can do more harm than good. We may
> >> close bugreports that are actually still useful just because nobody
> >> replied on then in a relatively short timeframe.
> >>
> >> Properly cleaning up old bugreports is important. However, it requires
> >> some level of care and expertise to judge whether a bugreport is still
> >> useful. Judging by the volume of bugreports that is pinged with the same
> >> copy&paste message this care is not  applied here.
> >>
> >> At minimum such initiatives should be announced and discussed before
> >> doing them, to allow people to give their input on the proposal. I am
> >> not aware of any such announcement/discussion.
> >>
> >> Cheers
> >>
> >> Nicolas
> >>
>

Re: "Gardening" old bugreports

[Justin Zobel]

Involvement not evolvement.

On Thu, 19 Jan 2023, 10:06 pm Justin Zobel,  wrote:

> In the regard then it falls to developers with the understanding of the
> codebase to triage these.
>
> However it's clear due to the age of these bugs that most developers don't
> have time or aren't prioritising these reports.
>
> This is why I've volunteered time to try get engagement happening with
> community (the bug reporters) to help confirm these issues still exist and
> if they do, try and encourage evolvement from the project maintainers.
>
> Regards,
>
> Justin
>
> On Thu, 19 Jan 2023, 9:56 pm Nicolas Fella,  wrote:
>
>> Hi,
>>
>> Am 19.01.23 um 04:04 schrieb Justin:
>> > Hi Nicolas,
>> >
>> > This has been discussed with Nate Graham directly who has approved
>> > this cleanup of Bugzilla including the messaging behind it.
>>
>> KDE consists of more than Nate tough. We discuss and "review" things in
>> the open.
>>
>> >
>> > I am happy to discuss any concerns that people have around this. I
>> > understand Krita requested we exclude them from any gardening and that
>> > has been done, however this is the only feedback I have received.
>> >
>> > The gardening team aims to find out if the bug reports are still
>> > relevant by involving the users who reported them in determining if
>> > they are still valid. This increases community involvement and helps
>> > KDE as there isn't anywhere near enough manpower to review the
>> > thousands upon thousands of bugs that haven't been touched in years.
>>
>> Anecdotally many people don't like such automated changes being done to
>> their bugreports that don't actually engage with the content of the
>> report.
>>
>> >
>> > The bugs that we are interacting with are ones that have not had any
>> > activity for over 2 years. We are simply trying to reinvigorate
>> > discussion on those bugs to see if they are still valid. If the user
>> > does not reply within the standard 30 day period after a bug is set to
>> > NEEDSINFO, it is automatically closed by the Bug Janitor.
>> >
>> > I am not simply closing bugs, so I do take offense that care is not
>> > applied.
>>
>> Properly "triaging" old reports requires at least some level of
>> understanding of the project, codebase etc. I'm afraid there is no
>> simple solution to that and rule-based approaches aren't good enough.
>> Even taking things like CONFIRMED status or wishlist priority into
>> account assumes that these have actually been consistently applied.
>>
>> >
>> > I will halt it until it is approved by more developers. However if it
>> > is decided that it isn't wanted then the KDE as a whole will need to
>> > entice more people in sorting old bugs individually as it is clearly
>> > not a priority right now for the majority.
>> >
>> > Regards,
>> >
>> > Justin
>> >
>> Don't get me wrong, I do appreciate the initiative of cleaning up bugs.
>> But we do need to handle this with a lot of care to avoid it backfiring.
>>
>> Cheers
>>
>> Nico
>>
>>
>> > On 19/1/23 11:05, Nicolas Fella wrote:
>> >> Hi,
>> >>
>> >> can we please put the effort of "gardening" old bugreports on hold
>> until
>> >> we figured out whether this is actually something we want to do?
>> Several
>> >> people already expressed concerns about this.
>> >>
>> >> Improperly applied such mass changes can do more harm than good. We may
>> >> close bugreports that are actually still useful just because nobody
>> >> replied on then in a relatively short timeframe.
>> >>
>> >> Properly cleaning up old bugreports is important. However, it requires
>> >> some level of care and expertise to judge whether a bugreport is still
>> >> useful. Judging by the volume of bugreports that is pinged with the
>> same
>> >> copy&paste message this care is not  applied here.
>> >>
>> >> At minimum such initiatives should be announced and discussed before
>> >> doing them, to allow people to give their input on the proposal. I am
>> >> not aware of any such announcement/discussion.
>> >>
>> >> Cheers
>> >>
>> >> Nicolas
>> >>
>>
>

Re: "Gardening" old bugreports

[Justin Zobel]

Thanks for the feedback, everyone.

Given the distribution of positive vs negative feedback, we plan to
resume automatic bug triage of old non-wishlist bugs that have not
been updated in over 2 years. If you would like to opt your product
out of this initiative because you're able to keep on top of the
manual bug triage work, please let us know and we'll be happy to
accommodate you.

Exclusions so far:
- okteta
- krita
- any bug reported by sit...@kde.org

Thanks again for the feedback!

On Sun, Jan 22, 2023 at 6:10 PM Thomas Baumgart  wrote:
>
> On Donnerstag, 19. Januar 2023 22:39:45 CET Johannes Zarl-Zierl wrote:
>
> > Hi,
> >
> > Am Donnerstag, 19. Jänner 2023, 12:26:08 CET schrieb Nicolas Fella:
> > > Am 19.01.23 um 04:04 schrieb Justin:
> > > > The gardening team aims to find out if the bug reports are still
> > > > relevant by involving the users who reported them in determining if
> > > > they are still valid. This increases community involvement and helps
> > > > KDE as there isn't anywhere near enough manpower to review the
> > > > thousands upon thousands of bugs that haven't been touched in years.
> > >
> > > Anecdotally many people don't like such automated changes being done to
> > > their bugreports that don't actually engage with the content of the 
> > > report.
> >
> > Well, anecdotally you will mostly get feedback from people who don't like 
> > it.
> > Unless something is exceptionally great, few people will take the time to
> > speak out in favor of something that is already happening.
> >
> > > > The bugs that we are interacting with are ones that have not had any
> > > > activity for over 2 years. We are simply trying to reinvigorate
> > > > discussion on those bugs to see if they are still valid. If the user
> > > > does not reply within the standard 30 day period after a bug is set to
> > > > NEEDSINFO, it is automatically closed by the Bug Janitor.
> > > >
> > > > I am not simply closing bugs, so I do take offense that care is not
> > > > applied.
> > >
> > > Properly "triaging" old reports requires at least some level of
> > > understanding of the project, codebase etc. I'm afraid there is no
> > > simple solution to that and rule-based approaches aren't good enough.
> > > Even taking things like CONFIRMED status or wishlist priority into
> > > account assumes that these have actually been consistently applied.
> >
> > As a maintainer on a small project, I'm quite happy to get an occasional 
> > nudge
> > on old reports. Yes, I do occasionally go over old reports to see if they 
> > are
> > still valid, but having somebody else doing this methodically makes sure I
> > don't gloss over some bug that could be closed or fixed.
> >
> > Having this done by someone else without too much internal knowledge is an
> > absolute plus in my opinion. After all, if you want to clean up your attic,
> > you try to find a helper who does not have the same emotional attachment as
> > yourself.
> >
> >
> > > > I will halt it until it is approved by more developers. However if it
> > > > is decided that it isn't wanted then the KDE as a whole will need to
> > > > entice more people in sorting old bugs individually as it is clearly
> > > > not a priority right now for the majority.
> >
> > Speaking for KPhotoAlbum, I really appreciate the bugzilla gardening. Thank
> > you for doing it!
>
> I can second that for the KMyMoney project. An occasional poke and the
> automated cleanup when no response arrives where it is needed helps a lot.
>
>
> --
>
> Regards
>
> Thomas Baumgart
>
> -
> With every day I come closer to the grave and learn something new.
> It all happens because I have wandered around too much and stumbled into
> the Linux world - which is a fantastic place to be! (Algis Kabaila †)
> -

Re: Bringing Cantata under the KDE umbrella?

[Justin Zobel]

"Music player" daemon.

On Tue, 21 Feb 2023, 1:15 am Reindl Harald,  wrote:

>
>
> Am 20.02.23 um 15:18 schrieb Aleix Pol:
> > From a product description perspective it definitely is a music
> > player. MPD is an implementation detail.
>
> that must be why the first page of the settings is "library" with the
> IP-Adress of your mpd server and other then you i am using mpd/canata
> for many years :-)
>
> https://github.com/CDrummond/cantata
> About: Qt5 Graphical MPD Client
>
> don't get me wrong but do you even know what MPD is?
> https://www.musicpd.org/
>
> a music player / server without any interface, the interface is by
> definition a seperate application like canatata or android apps
> connecting to mpd via tcp which can run on localhost but don't need to
>
> >> Am 20.02.23 um 13:18 schrieb Aleix Pol:
> >>> On Mon, Feb 20, 2023 at 12:28 AM Heiko Becker 
> wrote:
> 
>  On Sunday, 19 February 2023 23:36:22 CET, Albert Astals Cid wrote:
> > El diumenge, 19 de febrer de 2023, a les 16:29:24 (CET), Heiko
> Becker va
> > escriure:
> >> Cantata is a Qt based MPD client, which was archived by its
> >> original author
> >> [1]. I started some porting to Qt6 but I wondered (and was asked in
> >> #kde-devel today) if it would make sense to move it to KDE's
> >> infrastructure? Despite being archived, it still works quite
> >> nicely. And ...
> >
> > My only 2 concerns are:
> >
> >* Is anyone going to work on it? I guess you?
> 
>  Yes.
> >>>
> >>> Part of the incubation process is to gather what's the team working on
> it.
> >>> https://community.kde.org/Incubator/Projects/DescriptionTemplate
> >>>
> >>> It feels wrong to incubate a project that is already out of
> >>> development. Especially when we already have a number of music
> >>> players...
> >>
> >> Cantata isn't a "music player"
> >> it's the by far best MPD client
>

Flatpak Manifest Licensing

[Justin Zobel]

Hey Everyone,

As Binary Factory is to be shut down soon we are moving the Flatpak 
manifests to their individual GitLab repositories.


Most of this is fairly simple, however, some GitLab repositories have 
enabled reuse linting (which is great). The Flatpak manifests I have 
come across so far have not had any licensing information included. This 
email is just to start a discussion about what everyone's thoughts are 
about which license to apply for them.


The GitLab CI files are licensed as CC0-1.0 and I'm thinking that this 
might be a suitable license as the Flatpak manifest files are simply 
text files.

# SPDX-FileCopyrightText: None
# SPDX-License-Identifier: CC0-1.0

Let me know your thoughts.

Justin

Re: Bug Safari Project

[Justin Zobel]

I did have something basic written up for this but it's in bash and it 
stopped working and I hadn't got around to fixing it. At least with 
python it's likely a bit more solid. Thanks for you work on automation!


On 22/7/23 21:34, Ben Bonacci wrote:

Hi everyone!

For the past few days I've been working on Bug Safari, which is a 
Python script that gets statistics for Plasma bugs and sends a report 
to the #plasma room on Matrix, which is one of the dot points for 
KDE's Automation goal.


I've now got the script uploaded to Invent at 
https://invent.kde.org/bbonacci/bug-safari for anyone to look over, 
make improvements or implement.


Regards,

Ben

Re: Bug Safari Project

[Justin Zobel]

I'd suggest sending it as one message so it's not interrupted by other 
chats in between. Matrix supports html being sent so you can just place 
 line breaks.


This is the hideous bash I was using to do it before, found it on my 
server: https://pastes.dev/5San77eoCU - I can't remember what broke but 
if you want to use it for ideas go ahead.


On 24/7/23 20:30, Ben Bonacci wrote:


Hi Nate,

I've recorded the script in action which can be accessed with this 
link: https://benbonacci.com/files/shares/1w-bug-safari-demo.mp4 
(Expires in 1 week)


Regards,

Ben

On 23/7/23 23:43, Nate Graham wrote:

Very cool stuff. Can we see it in action anywhere?

Nate


On 7/23/23 01:38, Ben Bonacci wrote:

Hi Ben,

Thanks for the suggestion! Now after each request the script will 
wait 1-5 seconds before making the next request.


Regards,

Ben

On 22/7/23 22:30, Ben Cooksley wrote:
On Sun, Jul 23, 2023 at 12:18 AM Ben Bonacci  
wrote:


    Hi everyone!


Hi Ben,


    For the past few days I've been working on Bug Safari, which is a
    Python
    script that gets statistics for Plasma bugs and sends a report 
to the

    #plasma room on Matrix, which is one of the dot points for KDE's
    Automation goal.

    I've now got the script uploaded to Invent at
https://invent.kde.org/bbonacci/bug-safari for anyone to look
    over, make
    improvements or implement.


Thanks for this, I have just had a quick look over the code and it 
overall looks pretty reasonable, and also follows best practice of 
setting it's own user agent.


One small suggestion would be to add some small sleeps in to ensure 
that the server endpoints don't get hammered by your requests.
While the script by itself is fairly innocent, if similar scripts 
were added for a series of other channels and they all ran at the 
same time, this could result in a rush on the server that could 
make it inaccessible to normal users (or at the very least impact 
responsiveness).


Adding some sleeps (ideally for a random number of seconds as 
people tend to pick the same cron times to run stuff on) will 
ensure this doesn't become an issue.



    Regards,

    Ben


Cheers,
Ben


    --     Ben Bonacci
https://benbonacci.com
    C0A9 E67F 8CDC B1A1 0860 1807 E018 065C C7DF 3976

    Quote of the Day: "What's the good of living if you don't try a
    few things?" - Charles M. Schulz


--
Ben Bonacci
https://benbonacci.com
C0A9 E67F 8CDC B1A1 0860 1807 E018 065C C7DF 3976

Quote of the Day: "If you only read the books that everyone else is 
reading, you can only think what everyone else is thinking." - 
Haruki Murakami



--
Ben Bonacci
https://benbonacci.com
C0A9 E67F 8CDC B1A1 0860 1807 E018 065C C7DF 3976

Quote of the Day: "It does not matter how slowly you go as long as you do not 
stop." - Confucius

Re: Per project repository snapcraft files?

[Justin Zobel]

I think there is a lot of misunderstanding here.

In GitLab CI only test builds are done and artifacts are kept so people 
can test an AppImage or Flatpak without having to compile locally.


Stable releases are done by the Release Team via scripts to tarballs. 
Flatpaks are done via Flathub and are done (usually) automatically via 
the Flatpak External Data Checker.


Hopefully this clarifies the situation.

On 21/8/23 08:48, Scarlett Moore wrote:



On Sun, Aug 20, 2023, 4:14 PM Julius Künzel 
 wrote:


To me it seems this discussion is quite abstract and there are
several misunderstandings because not everybody knows every detail
of snap packaging and/or the KDE infrastructure (me neither).

I understand that from an organizational perspective most people
like the idea of having the files in the repos, but have technical
doubts. Hence, I wonder whether it would be a good idea to take
one KDE app to try and showcase this suggestion?

Cheers,
Julius

Sounds like a great idea to me.
Scarlett




20.08.2023 17:55:24 Laura David Hurka :

> On Sunday, August 20, 2023 12:47:10 PM CEST Ben Cooksley wrote:
>> On Sun, Aug 20, 2023 at 12:43 PM Scarlett Moore <
>>
>> scarlett.gately.mo...@gmail.com> wrote:
>>> Only on release! We will not be building from master! We don't
want
>>> unstable snaps.
>>> Thanks,
>>> Scarlett
>>
>> In that particular case the jobs should be manually triggered only.
>>
>> Gitlab CI is really made for building artifacts for a given
commit rather
>> than for a specified version though, so this is definitely
going to be a
>> case of things not fitting quite right.
>>
>> Cheers,
>> Ben
>> [...]
>
> This confuses me too.
> It seems Scarlett wants to use a “deploy” stage [1] and a job
rule [2]
> to run snap build&release jobs automatically when the release is
done.
>
> If you mean that Gitlab CI should not be used to automate
release jobs,
> you should elaborate more how binary-factory is meant to be
replaced.
>
> Otherwise, do you just note that Gitlab CI is suboptimal,
> or do you recommend to use something else?
> Like: “Release build: automatic is fine. Release publish: please
only manual”?
>
> Cheers, David
>
>
> [1] https://docs.gitlab.com/ee/ci/yaml/#stages
> [2] like this:
> snap-release-job:
>   rules:
>     -if: $CI_COMMIT_TAG =~ /^v[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]$/
>   [...]
> see also:

https://docs.gitlab.com/ee/ci/jobs/job_control.html#use-predefined-cicd-variables-to-run-jobs-only-in-specific-pipeline-types

Re: Frameworks / Plasma/ Gear Release Schedule Plan

[Justin Zobel]

In regards to Flatpak we're looking at building an Sdk to build against 
KF6 in the near future.


On 13/9/23 17:46, christ...@cullmann.io wrote:

On 2023-09-13 09:07, David Redondo wrote:
Am Dienstag, 12. September 2023, 21:42:37 CEST schrieb 
christ...@cullmann.io:

Hi,

i prepared some merge request for the switch in the meta data:

https://invent.kde.org/sysadmin/repo-metadata/-/merge_requests/185

A question about the CMake changes:

Is there some preferred way to switch?

I would just alter the defaults to

set(QT_REQUIRED_VERSION "6.4.0")
set(QT_MAJOR_VERSION "6")
set(KF_MIN_VERSION "5.240.0")
set(KF_MAJOR_VERSION "6")

in the first step and start later to remove the version ifs.


For Gear the minimum versions are changed by the individual projects, 
last
time I looked there was also no consistent naming of these CMake 
variables,

not have a  'KF_MAJOR_VERSION' variable at all. (Actually I never seen a
KF_MAJOR_VERSION variable before, so maybe only Kate?).
For reference Frameworks right now requires at least Qt 6.5.
I think explicitely setting QT_MAJOR_VERSION to 6 is not needed, 
including ECM
with 5.240 will enable using Qt 6 install paths. (Of course it 
doesn't hurt to

be explicit)


Ok, I will just be explicit there atm.

One other question: I assume at the moment the move to KF6 means I 
must disable

the Flatpak CI part?

Greetings
Christoph




Greetings
Christoph


David

Re: Reviving lightdm-kde-greeter upstream

[Justin Zobel]

There's a long running discussion [1] going on about incubation SDDM into
KDE.

* 1 https://invent.kde.org/plasma/plasma-desktop/-/issues/91

On Wed, 22 Nov 2023, 19:19 Anton Golubev,  wrote:

> Hello!
>
> I am involved in the development of the ALT Linux distribution. Some
> time ago we started developing the lightdm-kde-greeter fork and I am
> currently maintaining it[1]. I also push it on gitlab[2]. In addition to
> porting to Qt5, some features have been added, such as choosing a
> keyboard layout and connecting to the network. This greeter is currently
> used by default in our KDE-based builds.
>
> I was given the idea to revive this project in the upstream[3].
> Personally, I like the idea, and might look into it if someone else
> finds it useful, and I will be given appropriate access.
>
> Regards,
>
> [1]: https://git.altlinux.org/gears/l/lightdm-kde-greeter.git
> [2]: https://gitlab.com/golubevan/lightdm-kde-greeter
> [3]: https://invent.kde.org/unmaintained/lightdm
>

Re: KDE Gear projects with failing CI (release/23.08) (22 November 2023)

[Justin Zobel]

Fixed by https://invent.kde.org/utilities/kweather/-/merge_requests/93, thanks.

On Thu, Nov 23, 2023 at 9:59 AM Albert Astals Cid  wrote:
>
> Please work on fixing them, otherwise i will remove the failing CI
> jobs on their 4th failing week, it is very important that CI is passing for
> multiple reasons.
>
> Good news: 1 repository was fixed
>
> Bad news: We have 1 new repository failing
>
>
> == appstream stuff ==
>
> kweather
>  * https://invent.kde.org/utilities/kweather/-/pipelines/538833
>
> Cheers,
>   Albert
>
>

Re: KDE Gear projects with failing CI (master) (9 January 2024)

[Justin Zobel]

On 10/1/24 09:15, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI
jobs on their 4th failing week, it is very important that CI is passing for
multiple reasons.

Good news: 3 repositories got fixed

Bad news: 3 repo still failing (1 with a different failure) and 3 new this week


krdc - 2nd week
  * https://invent.kde.org/network/krdc/-/pipelines/577433
   * Dependency seems missing in flatpak
Fixed by 
https://invent.kde.org/network/krdc/-/merge_requests/72/pipelines just 
pending merge


mimetreeparser - 2nd week
  * https://invent.kde.org/pim/mimetreeparser/-/pipelines/577439
* MessageViewerDialogTest doesn't pass


kdenlive - NEW reason
  * https://invent.kde.org/multimedia/kdenlive/-/pipelines/577432
   * craft_windows_qt6_mingw64 fails because of qtmultimedia


kimagemapeditor - NEW
  * https://invent.kde.org/graphics/kimagemapeditor/-/pipelines/577437
   * Qt6 build missing includes?


krecorder - NEW
  * https://invent.kde.org/utilities/krecorder/-/pipelines/577438
   * All the craft_android builds are broken


filelight - NEW
  * https://invent.kde.org/utilities/filelight/-/pipelines/577430
   * flatpak build fails, seems that 
https://invent.kde.org/sysadmin/ci-utilities/-/merge_requests/210 should have 
fixed it but it didn't. There's more steps involved and Ingo will take care of 
them

Cheers,
   Albert

Re: KDE Gear projects with failing CI (release/24.02) (Branching edition)

[Justin Zobel]

On 12/1/24 20:29, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI
jobs on their 4th failing week, it is very important that CI is passing for
multiple reasons.

Bad news: We have more things failing than we should have, but it's kind of 
expected on a branching

kitinerary:
  * https://invent.kde.org/pim/kitinerary/-/pipelines/580364
   * static-extractor fails to compile

mimetreeparser:
  * https://invent.kde.org/pim/mimetreeparser/-/pipelines/580371
   * MessageViewerDialogTest fails

spectacle:
  * https://invent.kde.org/graphics/spectacle/-/pipelines/580321
   * It's trying to find packages in a wrong branch

okular:
  * https://invent.kde.org/graphics/okular/-/pipelines/580655
   * It's trying to find packages in a wrong branch

kosmindoormap:
  * https://invent.kde.org/libraries/kosmindoormap/-/pipelines/580051
   * It's trying to find packages in a wrong branch

itinerary:
  * https://invent.kde.org/pim/itinerary/-/pipelines/580366
   * Fails because kosmindoormap failed

kate:
  * https://invent.kde.org/utilities/kate/-/pipelines/580318
   * 6.6-kf6preview flatpak SDK needs updating

dolphin:
  * https://invent.kde.org/system/dolphin/-/pipelines/580319
   * 6.6-kf6preview flatpak SDK needs updating

pim-sieve-editor:
  * https://invent.kde.org/pim/pim-sieve-editor/-/pipelines/580352
   * 6.6-kf6preview flatpak SDK needs updating

arianna:
  * https://invent.kde.org/graphics/arianna/-/pipelines/580370
   * 6.6-kf6preview flatpak SDK needs updating

kipi-plugins:
  * https://invent.kde.org/graphics/kipi-plugins/-/pipelines/580365
   * Do we even have libmediawiki still?

krecorder:
  * https://invent.kde.org/utilities/krecorder/-/pipelines/580369
   * Craft builds broken

P.S: I'll be out next week so no reminders!

Cheers,
   Albert
Flatpak SDK update has been submitted, pending approval/merge: 
https://invent.kde.org/packaging/flatpak-kde-runtime/-/merge_requests/188

Re: Help with installing KArchive

[Justin Zobel]

If I may suggest joining the KDE Windows channel on Matrix. You can 
discuss there with KDE developers who are familiar with compiling KDE 
software on Windows. https://go.kde.org/matrix/#/#kde-windows:kde.org


On 19/2/24 13:05, Aaron Rainbolt wrote:


Oof, I didn't realize you were on Windows. I have no clue how Qt and 
KDE development works there since I don't use Windows anymore. If 
you're trying to code an application for Windows specifically, you'll 
probably need help from someone who knows how KDE app development 
works on Windows.


On 2/18/24 20:05, Eric Ribble wrote:

Hi Aaron,

Thanks for the quick response.  Unfortunately, I am not familiar with 
distro or Ubuntu or Debian.  My laptop is running Windows 11.  A few 
weeks ago I download and installed Qt6 and have been able to build a 
few simple Qt Windows applications.  I studied your email, googled 
'how to', etc., but finding it very difficult to simply download the 
KArchive library (KF6Archive (instead of KF5Archive)) and the 
"kzip.h" header file for usage with Qt6.


Any other suggestions?  Or do I need to figure out how to install/use 
Ubuntu on my Windows 11 laptop?


If you can't be of further help, I understand.

Eric

On Sunday, February 18, 2024 at 06:38:43 PM EST, Aaron Rainbolt 
 wrote:



On 2/18/24 13:30, Eric Ribble wrote:
I am a new user of Qt (using version 6.6) and Qt Creator  I would 
like to use KArchive to extract all folders and files from a zip 
file. I found the example "karchive/examples/unzipper/main.cpp" 
source code.  However, I don't know how to download and install KArchive.


What distro are you using?

In order to install a library in such a way that you can use it in 
new programs, you have to install both it and its development header 
files. There are generally two ways to do this:


* The easy way - install the development header package for your 
library of choice through your distro's package manager.
* The hard, dangerous way that you probably don't want yet - build 
the library from source and then either install it directly or figure 
out how to point your build system to it.


Obviously I'd recommend the former if you're just getting started. On 
Ubuntu, the package you want is called "libkf5archive-dev", and can 
be installed with "sudo apt install libkf5archive-dev". This will 
probably work on Debian too. If you're on some other distro, you'll 
need to find and install the right package.



I added the following to my project's "CMakeLists.txt" as described 
on the web page 
https://marketplace.qt.io/pages/karchiveinstructionspage 
 :


find_package(KF5Archive)
target_link_libraries(Example4 KF5::Archive)

Attached is my "CMakeLists.txt" file and "Main.cpp" file.

In my "Main.cpp" the syntax-checker indicates that it can't find 
"kzip.h" (probably because I don't know how to download/install it).


Here is a screenshot after trying to build:

Inline image

Please advise on how to properly download/install KArchive so that 
this simple program will build.  Thanks for your help!


Eric Ribble



--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub:https://github.com/ArrayBolt3  

--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub:https://github.com/ArrayBolt3

Re: Post-MegaRelease projects

[Justin Zobel]

On 23/2/24 08:27, Nate Graham wrote:

Hello everyone,

Congrats to the entire KDE community on the impending launch of the 
KDE 6 MegaRelease! I'm so impressed with how folks came together to 
make it amazing. It's a very impressive release and I think people are 
gonna love it.


I've started pondering post-megarelease projects. We've spent so long 
on porting and bugfixing that I think it might be useful to shift 
gears to feature work, and I'd like to brainstorm potential 
large-scale projects and gauge the level of interest in putting 
resources into them soon.


Here are some ideas of mine to get the creative juices started:

* David's input method playground stuff [1] is amazing and needs to be 
developed and productized
* GNOME's Libadwaita app platform has been a runaway success for them; 
evaluate our offerings in comparison and see what we can do better

* Unified theming infrastructure for KDE apps, GTK apps, and Plasma.
** Relatedly: QML/JS in themes is dangerous; move away from it
Agreed, this will make themes uploaded the KDE Store less likely to 
contain malicious code

* Start adding release notes to our apps' AppStream metadata [2]
Regarding this we could add (or improve any existing) linting job to 
include appdata checks.

* Finish up and ship the new Breeze icons
* HIG is outdated and mostly ignored, and needs an overhaul to make it 
useful

* Telemetry system has not proved to be very useful and needs an overhaul
* store.kde.org is full of low-quality or broken content; make a push 
for KDE people to take ownership of content moderation, QA, etc. Also 
any relevant and needed tech improvements
Please feel free to CC/invite me on anything related to the store as I 
manage the servers and have direct contact with the Web team that 
manages the software. I am always looking for new ways to remove spam, 
keep the platform secure and any ways to make sure the content is well 
curated.

* Our virtual keyboard situation is not great and needs focused work
On this I think it might be worth looking into working with Dobey who 
works on Maliit. It's used by the Plasma Mobile stack and I think Dobey 
is the only major contributor to it. It could either be brought under 
the KDE umbrella or forked to be a KDE specific OSK

* KWallet needs an overhaul
* Have KWin (optionally) remember window positions on Wayland
* Build a "System misconfiguration detection hub" app [3]

Feel free to discuss, and propose your own!

Nate



[1] 
https://blog.davidedmundson.co.uk/blog/new-ideas-using-wayland-input-methods/

[2] https://github.com/ximion/appstream/issues/354
[3] https://invent.kde.org/plasma/plasma-workspace/-/issues/64

Re: KDE Gear projects with failing CI (master) (5 March 2024)

[Justin Zobel]

On 6/3/24 09:41, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI jobs on
their 4th failing week, it is very important that CI is passing for multiple
reasons.

Good news: 6 repositories got fixed

Bad news: 1 repository still failing and 7 new repositories failing this week


kate - 2nd week
  * https://invent.kde.org/utilities/kate/-/pipelines/622410
   * craft fails


filelight - 1st week
  * https://invent.kde.org/utilities/filelight/-/pipelines/622444
   * craft fails. Is this actually a failure? Or did it just run out of "log"?


kwave - 1st week
  * https://invent.kde.org/multimedia/kwave/-/pipelines/622156
   * Linux build fails, complains that neither rsvg nor convert are installed


klickety - 1st week
  * https://invent.kde.org/games/klickety/-/pipelines/622160
   * appstreamtest fails


pim -sieve-editor - 1st week
  * https://invent.kde.org/pim/pim-sieve-editor/-/pipelines/622188
   * appstreamtest fails

Fixed

kbackup - 1st week
  * https://invent.kde.org/utilities/kbackup/-/pipelines/622198
   * appstreamtest fails


kclock - 1st week
  * https://invent.kde.org/utilities/kclock/-/pipelines/622448
   * flatpak fails, needs libplasma

Fixed

kweather - 1st week
  * https://invent.kde.org/utilities/kweather/-/pipelines/622452
   * flatpak fails, needs libplasma

Fixed




Cheers,
   Albert

Re: KDE Gear projects with failing CI (master) (12 March 2024)

[Justin Zobel]

On 13/3/24 09:42, Albert Astals Cid wrote:

kalgebra - NEW
  * https://invent.kde.org/education/kalgebra/-/pipelines/628851
   * flatpak fails, needs libplasma

Fixed with https://invent.kde.org/education/kalgebra/-/merge_requests/43

Re: KDE Gear projects with failing CI (master) (19 March 2024)

[Justin Zobel]

On 20/3/24 08:55, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI jobs on
their 4th failing week, it is very important that CI is passing for multiple
reasons.

Good news: 8 repositories got fixed

Bad news: 1 repository still failing and 4 new repositories failing this week


neochat - 2nd week
  * https://invent.kde.org/network/neochat/-/pipelines/637429
   * craft_appimage_qt6_x86_64 fails


kbruch - NEW
  * https://invent.kde.org/education/kbruch/-/pipelines/637302
   * craft_macos_qt6_* fails


kgeography - NEW
  * https://invent.kde.org/education/kgeography/-/pipelines/637304
   * craft_macos_qt6_* fails


kmplot - NEW
  * https://invent.kde.org/education/kmplot/-/pipelines/637305
   * craft_macos_qt6_* fails


kasts - NEW
  * https://invent.kde.org/multimedia/kasts/-/pipelines/637451
   * flatpak fails
   * craft_windows_qt6_mingw64 fails
Fixed the flatpak job, it just needed to be re-run as there was an issue 
downloading the VLC tar.



Cheers,
   Albert






Justin

Help with the project

[Justin Boss]

In the past I seen somewhere where you could ask for help with your project  
and if people wanted to help they could join the project. Was that on kde  
fourms or on sourceforge?


iLinux Do You?
Sent via DROID on Verizon Wireless

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: KDE Gear projects with failing CI (master) (14 May 2024)

[Justin Zobel]

On 15/5/24 08:36, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI jobs on
their 4th failing week, it is very important that CI is passing for multiple
reasons.

Good news: 3 repositories fixed 


Bad news: 7 new repositories started failing


dolphin - NEW
  * https://invent.kde.org/system/dolphin/-/pipelines/688258
   * craft_windows_qt6_x86_64 needs newer KF6 than provided


flatpak needs newer KF6 than provided
  * https://invent.kde.org/system/dolphin/-/pipelines/688258
  * https://invent.kde.org/accessibility/kontrast/-/pipelines/688311
  * https://invent.kde.org/pim/itinerary/-/pipelines/688316
  * https://invent.kde.org/network/alligator/-/pipelines/688321
  * https://invent.kde.org/utilities/kclock/-/pipelines/688323
  * https://invent.kde.org/utilities/krecorder/-/pipelines/688324
  * https://invent.kde.org/plasma-mobile/qmlkonsole/-/pipelines/688325


New flatpak SDK are building that should fix stuff when ready
   https://buildbot.flathub.org/#/apps/org.kde.Sdk~2F6.7
   https://buildbot.flathub.org/#/apps/org.kde.Sdk~2F6.6
Do we need to do some sync to import them to our systems or will it just work?
It will need a rebuild of the Flatpak CI Image, ping me or someone in 
sysadmin to get this run.



Cheers,
   Albert

Re: Current Konsole Crashes

[Justin Zobel]

I haven't seen konsole crash in a very long time, but I did notice the 
duplicate shortcut registration on my Steam Deck recently for Copy (Ctrl 
+ Shift + C).


On 9/1/24 01:08, Tomaz Canabrava wrote:

Hello all,

konsole started to crash a lot; daily for me.
i tried to find the culprit but it doesnt seem to be in konsole code - 
at least theres no change in the code that it crashes for many years.


i believe there is a change in kxmlgui actionCollection handling - but 
didnt had the time to look for.


i ask for help to identify and fix. there are a few things that made 
me think the problem is the actionCollection():


- splits are registering the same shortcut for actions so when you 
hit, eg, ctrl shift v, a message appears "more than one shortcut 
registered", but if you try again, it might work.

(randomly disabling actions or the actions for a different pane)

- crash when triggering a right click / copy menu item as if the 
action has been deleted (but theres no deletion code on konsole itself)


need help figuring this out :)
tomaz

Re: KDE Gear projects with failing CI (master) (3 September 2024)

[Justin Zobel]

On 4/9/24 06:20, Albert Astals Cid wrote:

neochat - NEW
  * https://invent.kde.org/network/neochat/-/pipelines/767855
   * All the craft and flatpak jobs fail

This appears to be caused by 
https://invent.kde.org/network/neochat/-/commit/05a2f03c18435067d2e60e7ef6a8d025479d1c6c 
which has Neochat requiring KF6.6 which isn't out yet and thus not in 
the KDE Flatpak SDK/Runtime. KF6.6 will be out in a few days (tagging) 
and I'll hopefully remember to update the SDK/Runtime as soon as that's 
done so we can make sure this continues to build cleanly.


Justin

Re: KDE Gear projects with failing CI (release/24.08) (15 October 2024)

[Justin Zobel]

🥳

On 16/10/24 07:18, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI jobs on
their 4th failing week, it is very important that CI is passing for multiple
reasons.

Good news: All repositories pass :)

Cheers,
   Albert

KMPlayer

[Justin Zobel]

Hey Team,

Does anyone use KMPlayer and wants to give it some love? It hasn't been 
released in quite a while and could do with someone to give it some love 
and bring it into the Release Service.


https://invent.kde.org/multimedia/kmplayer

Justin

Re: KDE Gear projects with failing CI (release/24.08) (22 October 2024)

[Justin Zobel]

Skanlite flatpak fixed.

On 23/10/24 08:40, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI jobs on
their 4th failing week, it is very important that CI is passing for multiple
reasons.

Bad news: 6 repositories have started failing


kate - NEW
  * https://invent.kde.org/utilities/kate/-/pipelines/802024
   * kwritetest fails


kio-gdrive - NEW
  * https://invent.kde.org/network/kio-gdrive/-/pipelines/802205
   * fails to compile


itinerary - NEW
  * https://invent.kde.org/pim/itinerary/-/pipelines/802214
   * Android fails to compile
   * Apium tests fail


skanlite - NEW
  * https://invent.kde.org/graphics/skanlite/-/pipelines/802540
   * flatpak fails


falkon - NEW
  * https://invent.kde.org/network/falkon/-/pipelines/802220
   * Missing shiboken files?


telly-skout - NEW
  * https://invent.kde.org/utilities/telly-skout/-/pipelines/802242
   * all compilations fail
* Disable deprecated Werror?

  
Cheers,

   Albert

Re: KDE Gear projects with failing CI (master) (5 November 2024)

[Justin Zobel]

On 6/11/24 08:30, Albert Astals Cid wrote:

calligra - 2nd week
  * https://invent.kde.org/office/calligra/-/pipelines/811658
   * signing stage fails in flatpak

Should be fixed by 
https://invent.kde.org/sysadmin/ci-utilities/-/merge_requests/391

Re: KDE Gear projects with failing CI (release/24.12) (19 November 2024)

[Justin Zobel]

On 20/11/24 07:56, Albert Astals Cid wrote:

kdenlive - NEW
  *https://invent.kde.org/multimedia/kdenlive/-/pipelines/817971
   * flatpak fails
   * craft appimage fails
Flatpak job was just a network issue while pulling dependencies, re-ran 
it and it's fine.

Re: KDE Gear projects with failing CI (release/24.12) (19 November 2024)

[Justin Zobel]

On 20/11/24 07:56, Albert Astals Cid wrote:

kdenlive - NEW
  * https://invent.kde.org/multimedia/kdenlive/-/pipelines/817971
   * flatpak fails
   * craft appimage fails
I assume this was supposed to be this pipeline 
https://invent.kde.org/multimedia/kdenlive/-/pipelines/822977 as the one 
you linked failed during FreeBSD build so AppImage/Flatpak were skipped.

Re: KDE Gear projects with failing CI (master) (19 November 2024)

[Justin Zobel]

On 20/11/24 07:29, Albert Astals Cid wrote:

klettres - NEW
  * https://invent.kde.org/education/klettres/-/pipelines/822811
   * flatpak build fails
Laurent updated it to 6.8 Flatpak Sdk without testing and it didn't 
work. Reverted.


skanpage - NEW
  * https://invent.kde.org/utilities/skanpage/-/pipelines/822834
   * flatpak build fails
Laurent updated it to 6.8 Flatpak Sdk without testing and it didn't 
work. Reverted.

New Application Status

[Justin Zobel]

Hi Everyone,

I'm a bit frustrated by our new application development pipeline.

I see applications appear on apps.kde.org and in official namespaces on 
GitLab before they have passed KDE Review.


I feel this is falsely advertising to the world that the app is ready 
for use.


The button on apps.kde.org that says 'Install on Linux' takes me to 
Discover and then tells me that the app was not found in any software 
repositories.


It also tells me to report this to my distribution which can lead to 
noise on distro bug trackers. It can also lead to noise on the KDE bug 
tracker because a user wants to install the application but can't.


I think keeping applications in user namespaces until it has passed KDE 
Review would solve both of these problems.


Justin

Re: [Introduction] Vlad, new aspiring contributor to KDE Plasma

[Justin Zobel]

Welcome! I'm sure the few people left on NVIDIA on Linux will appreciate 
your work. Many have just abandoned them all together (myself included). 
Their new work is promising but it's got a long way to go to make up for 
years of neglect of Linux. I'm sure the Plasma and KWin teams will love 
to see more people working on making KDE amazing!


Make sure to jump in the relevant Matrix rooms that interest you and say 
hi! https://community.kde.org/Matrix#Rooms


Justin

On 30/12/24 01:40, Vlad Korol wrote:

Howdy everyone!

My name is Vlad Korol, I'm a new developer here tackling KDE Plasma. 
This is my first open-source project, and I will be happy to work 
along with all of you to make Plasma the default in Linux desktop 
experience.


I myself have a mixed background in software engineering and AI/ML as 
well. Skilled in C++, Python, Java and JavaScript. Programming for 
years, so I know my way around best practices, Cmake and idiomatic 
C++, and I'll be glad to learn anything else I will need along the way.


I myself was a year-long KDE user until I bought a new Nvidia GPU. 
Unfortunately, it was a miss for me, and I decided to contribute to 
improve Wayland sessions under Nvidia drivers. I have tested and 
Wayland works on Gnome, so I believe the issue lies in Kwin, composing 
and Nvidia GBM quirks. I believe my recent GPU (Nvidia RTX 4070 Super) 
will be a great asset for testing current generation Nvidia GPUs and 
make KDE Plasma more approachable and deliver "just works" experience. 
I didn't look at the codebase yet, and I face difficulties with 
building Plasma workspace because of newer dependency, but I have 
already opened a bug report, and it will be awesome if you could 
review it:

https://bugs.kde.org/show_bug.cgi?id=498018

Other than that, I am learning about the codebase and the contribution 
workflow and will be soon making changes.


I use Fedora by the way, the latest Fedora Workstation 41. My 
timezone is Eastern European Time (EET). I am happy to meet all of 
you, and feel free to drop a message to get to know each other!

Re: kontact crashing when trying to remove an identity?

[Justin Zobel]

On 5/2/25 21:20, Markus Feilner wrote:

Hi,

I'll ask this on kde-pim in a few, but can anybody confirm this? My Kontact is
crashing reproducable on two machines when I try to delete identities. I have
5-6 identities and cannot delete them anymore.

Running Tumbleweed, kontact 24.12.1-1.1 . I think of downgrading to an older
version, since the new one from January seems to be the cause...

if you have the same problem or a solution, feel free to mail + PM me...


Hi Markus,

The best way to get this confirmed and fixed is to report it on 
https://bugs.kde.org. See 
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports 
for a great guide on how to report a crash report with debug symbols.


Justin

Re: KDE Gear projects with failing CI (master) (10 December 2024)

[Justin Zobel]

On 11/12/24 09:38, Albert Astals Cid wrote:

kontact - NEW
  * https://invent.kde.org/pim/kontact/-/pipelines/838362
   * craft windows job fails
Fixed by Carl in 
https://invent.kde.org/accessibility/kontrast/-/commit/8a62930c235acb39a9ee18a30f0bde5e5b9d2cc4

Re: Moving Spectacle to the Plasma release schedule

[Justin Zobel]

On 6/12/24 02:23, Noah Davis wrote:

Hello everyone, I would like to propose moving Spectacle to the Plasma
development release schedule. It already depends heavily on Plasma for
its core functionality. When a Plasma bug or feature happens on a new
release that affects Spectacle, Spectacle can't push anything to users
until the next KDE Gear release, so it's not in sync.


For when you do it make sure to send an email to distributi...@kde.org 
so that distros know.


1. So they know it's happening

2. So they can get epochs or replaces in place as 24 > 6 when it comes 
to version upgrade/downgrade logistics of packages.


Justin

Re: KDE Gear projects with failing CI (master) (10 December 2024)

[Justin Zobel]

On 14/12/24 02:00, Volker Krause wrote:

On Mittwoch, 11. Dezember 2024 20:31:54 Mitteleuropäische Normalzeit Heiko
Becker wrote:

On Wednesday, 11 December 2024 00:08:48 CET, Albert Astals Cid wrote:

ksudoku - NEW

  * https://invent.kde.org/games/ksudoku/-/pipelines/836274
  
   * craft mac jobs fail

https://invent.kde.org/games/ksudoku/-/merge_requests/30

It was easy enough to fix, but it wouldn't have happened if Laurent would
use Merge Requests...

Merge requests don't run the deploy stage of the pipeline (which is the part
that failed here), so that on its own wouldn't have caught this either, the MR
would have been green and only failed after integration.

This is more about receiving (and acting on) Gitlab's CI failure notifications
I'd say. So if anyone doesn't get those by email please double-check your
Gitlab settings and if necessary work with the sysadmin team to figure out
where things get lost, as we see here it's essential everyone has this
working.

Regards,
Volker
Sadly it's also possible people are filtering these emails and not 
acting on them.

Re: New Application Status

[Justin Zobel]

Hey Everyone,

Thanks for all the input. Sorry I've been out for a few days, my wife 
and I were busy and welcomed into our life our baby girl Isla.


I would like to propose the following based on all of the feedback and 
my own thoughts:


- Main page of apps.kde.org it will by default only show apps that are 
active. This data will come from the lifecycle status in repo metadata.


- A filter on the front page of apps.kde.org with tickboxes: Status: [x] 
Active [ ] Beta [ ] Archived(Unmaintained)


- On each app page it will show the status of the app: Actively 
Developed, Beta or Archived so users know what to expect if they do try it.


- Add appstream metadata file location to the repo metadata. For example 
org.kde.kate: utilities/kate/org.kde.kate.appdata.xml


- Encourage developers to use our mailing lists or KDE Discuss to 
announce the new app they're working on and intending to be part of the 
KDE umbrella.



Specific replies:

> I'll also note that user namespaces are not writable to all developers

Anyone can still fork pubic repositories if they wish to contribute.

> Probably I'm one of the reasons this discussion started.

This did prompt the discussion but it wasn't the trigger, I had been 
thinking about this for a while.


Regards,

Justin

On 9/12/24 01:50, Phu Hung Nguyen wrote:

Date: Sun, 08 Dec 2024 12:36:26 +0100
From: Albert Astals Cid
To: Ben Cooksley
Cc:kde-devel@kde.org
Subject: Re: New Application Status
Message-ID: <9526941.xt29fcdmcD@xps15>
Content-Type: text/plain; charset="utf-8"

El divendres, 6 de desembre del 2024, a les 19:27:32 (Hora estàndard del
Centre d’Europa), Ben Cooksley va escriure:

On Fri, Dec 6, 2024 at 9:37 AM Albert Astals Cid wrote:

El dijous, 5 de desembre del 2024, a les 13:57:26 (Hora estàndard del
Centre

d’Europa), Ingo Klöcker va escriure:

On Donnerstag, 5. Dezember 2024 10:27:13 Mitteleuropäische Normalzeit
Ben

Cooksley wrote:

Trying to coming full circle on this here, but in summary sounds like
there
are a couple of things to change going forward:

* For apps.kde.org, we should flag applications in accordance with

their


Lifecycle status in the metadata (ie. unmaintained and those yet to

pass


KDE Review should be flagged in some form or another)

Yes. For beta apps. I'd say for unmaintained apps there shouldn't be a

page


on apps.kde.org. Given that there won't be build artifacts for

unmaintained


apps (at least not for long) there is anyway no AppStream data for

creating


such a page.

In my opinion once a page exists it needs to exist forever.

Imagine Okular goes unmaintained, I don't want the lots of pages pointing
to
https://apps.kde.org/okular/ to suddenly point to a 404

I want to see a page that says "This is unmaintained" but still has the
old
contents.

Continuing to have pages for unmaintained applications sounds okay, subject
to appstream metadata being available (not a given as we source them from
CI artifacts right now).

We probably wouldn't want to list unmaintained applications on say the
front page of apps.kde.org or the category lists though?

Clearly not on the front page, probably not on category lists though (Maybe
having their own "unmaintained category" in case people want to adopt them?)


We are already having a "Unmaintained" category page, 
https://apps.kde.org/categories/unmaintained/ or 
https://apps.kde.org/unmaintained/. This isn't linked to from the page 
of categories https://apps.kde.org/categories/, it's only linked to 
from pages of unmaintained apps, e.g. https://apps.kde.org/choqok/


For apps that don't have their artifacts and repos available anymore, 
we store their appdata and desktop files inside the repo 
https://invent.kde.org/websites/apps-kde-org/-/tree/master/appdata-extractor/appdata-unmaintained?ref_type=heads 

Merge Review Request kwalletmanager5 (blocking release updates)

[Justin Zobel]

Hey Everyone,

If I can please request some eyeballs on this merge request to review 
it. https://invent.kde.org/utilities/kwalletmanager/-/merge_requests/51. 
It's currently blocking the Flatpak/Flathub team from updating.


Thanks in advance.

Justin

Re: Feedback on KDE Plasma 6 Default Settings: A Call for Reflection

[Justin Zobel]

On 4/12/24 01:52, Lucy wrote:

Dear KDE Team,

As a long-time user and supporter of KDE, I am writing to express my 
concern regarding the recent decision to set double-click as the 
default interaction for opening files and folders in KDE Plasma 6. 
While I understand the intention of aligning KDE with what may be 
perceived as mainstream user expectations, this decision seems at odds 
with the core principles that have always defined KDE: freedom, 
configurability, and serving the unique needs of its loyal community.


Linux users have chosen this platform not because it mimics other 
operating systems, but precisely because it offers an environment that 
prioritizes user choice and individuality. Setting double-click as the 
default behavior may cater to users transitioning from Windows or 
macOS, but it disregards the preferences of KDE’s long-established 
user base, many of whom have embraced single-click as a hallmark of 
KDE’s innovative user experience.


This change, though seemingly minor, sends an unfortunate message: 
that KDE may be prioritizing conformity over its long-standing 
tradition of empowering users to shape their environment as they see 
fit. Instead of adopting defaults that resemble other platforms, KDE 
should continue to showcase its unique strengths—flexibility, 
customization, and a commitment to open innovation.


I urge the KDE team to reconsider this default setting and engage with 
the community on how such changes impact the user experience. By 
preserving the spirit of user-centric design, KDE will not only retain 
its dedicated supporters but also stand as a beacon of choice in the 
increasingly homogenized world of technology.


Thank you for your attention, and I hope this feedback helps guide 
future decisions.


Sincerely,

Lucy. S & Linux Community


Hi Lucy,

As you've mentioned this is only a default settings. KDE users are still 
empowered to make their own choices in the Settings. This settings is 
even considered important enough to be on the Quick Settings page which 
is the first to appear.


Justin

Re: KDE Gear projects with failing CI (master) (7 January 2025)

[Justin Zobel]

kdenlive flatpak is failing on master and release branches due to trying 
to connect to git.sesse.net for the movit repository. However the git 
server is IPv6 only. I've asked Ben to see if we can get the docker 
containers that builds run in given IPv6 to resolve this. If we can't, 
we may need to mirror that repository to KDE's GitLab server and adjust 
the source URL. The other option is using the release version of movit. 
However I'm not sure if kdenlive uses the git version as there are 
unreleased features they use.


On 8/1/25 08:07, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI jobs on
their 4th failing week, it is very important that CI is passing for multiple
reasons.

Bad news: 3 repositories started failing

kdenlive - NEW
  * https://invent.kde.org/multimedia/kdenlive/-/pipelines/859376
   * flatpak build fails


kasts - NEW
  * https://invent.kde.org/multimedia/kasts/-/pipelines/858443
   * craft_android_qt68_x86_64 build fails


tokodon - NEW
  * https://invent.kde.org/network/tokodon/-/pipelines/858698
   * craft_android_qt68_x86_64 build fails


Cheers,
   Albert

Re: KDE Gear projects with failing CI (master) (7 January 2025)

[Justin Zobel]

Both master and release fixed by jlskuz.

On 9/1/25 10:26, Justin Zobel wrote:
kdenlive flatpak is failing on master and release branches due to 
trying to connect to git.sesse.net for the movit repository. However 
the git server is IPv6 only. I've asked Ben to see if we can get the 
docker containers that builds run in given IPv6 to resolve this. If we 
can't, we may need to mirror that repository to KDE's GitLab server 
and adjust the source URL. The other option is using the release 
version of movit. However I'm not sure if kdenlive uses the git 
version as there are unreleased features they use.


On 8/1/25 08:07, Albert Astals Cid wrote:
Please work on fixing them, otherwise i will remove the failing CI 
jobs on
their 4th failing week, it is very important that CI is passing for 
multiple

reasons.

Bad news: 3 repositories started failing

kdenlive - NEW
  * https://invent.kde.org/multimedia/kdenlive/-/pipelines/859376
   * flatpak build fails


kasts - NEW
  * https://invent.kde.org/multimedia/kasts/-/pipelines/858443
   * craft_android_qt68_x86_64 build fails


tokodon - NEW
  * https://invent.kde.org/network/tokodon/-/pipelines/858698
   * craft_android_qt68_x86_64 build fails


Cheers,
   Albert

Re: KDE Gear projects with failing CI (master) (21 January 2025)

[Justin Zobel]

On 23/1/25 07:26, Albert Astals Cid wrote:

El dimecres, 22 de gener del 2025, a les 19:19:23 (Hora estàndard del Centre
d’Europa), Volker Krause va escriure:

On Mittwoch, 22. Januar 2025 18:52:46 Mitteleuropäische Normalzeit Ben

Cooksley wrote:

On Thu, Jan 23, 2025 at 5:49 AM Volker Krause  wrote:

On Dienstag, 21. Januar 2025 23:11:56 Mitteleuropäische Normalzeit
Albert

Astals Cid wrote:

neochat - NEW

  * https://invent.kde.org/network/neochat/-/pipelines/869365
  
   * flatpak build fails

Same as https://invent.kde.org/network/neochat/-/merge_requests/2127 I
guess,
looks like an API change in libQuotient with the corresponding version
change
still pending (ie. a similar problem we occasionally hit with Poppler).

The quick solution for this would probably be (temporarily) switching
Flatpak
to the latest release of libQuotient. The IMHO proper solution would be
to
have version bumps at the beginning of a development cycle that changes
API.

This also raises another question though - should we be strongly
discouraging use of heavily moving targets like upstream dev / master
branches and instead favouring the use of stable branches?
Not really ideal if upstream can essentially break our builds without us
doing anything.

I can't comment on NeoChat, but for Itinerary the builds against the latest
versions of essential (external) dependencies with varying
intentions/success in keeping backward compatibility (ZXing, Poppler,
Quotient) are very much deliberate, to catch breakage/regressions early
(same as we are now doing for KF with Qt pre-releases).

And this is actually working, NeoChat has been fixed to build with the
upcoming Quotient version, same for Itinerary/Poppler.

I'm fine with break-things-early if we have a fix-things-early outcome from it
:)

Cheers,
   Albert
And this is generally the case with NeoChat as several of the main 
contributors also work on libquotient upstream.

The only thing we
are missing for those fixes to take effect is those dependencies bumping
their version numbers.

We could work around that by doing configure-time detection using a compile
test, but that's a lot of extra work, so we'd better try to address this
upstream first.

I'd very much suggest the use of release tarballs (or stable branches) for
apps that aren't continuously monitoring their dependencies this way though,
but I'm not aware we have such a case.

Regards,
Volker

Re: End of life policy

[Justin Zobel]

On 23/1/25 03:06, Albert Astals Cid wrote:

El dimecres, 22 de gener del 2025, a les 4:35:53 (Hora estàndard del Centre
d’Europa), rhkra...@gmail.com va escriure:

On Tuesday, January 21, 2025 05:16:25 PM Albert Astals Cid wrote:

Is it not a consequence from the fact that there's no more releases
planned?

It's weird to say "for things that we don't plan releases there will no be
releases"

What would you write?

 From the peanut gallery: How about:

No more releases planned for this project.

and perhaps, in parenthesis after that, something like (end of project)

But we're not speaking about end of project.

We are speaking about the fact that Okular 24.12.x is not going to be released
anymore because Okular 25.04.x is the next release series, not that we're not
going to release Okular at all anymore.

Cheers,
   Albert


Further to this one, perhaps on the announcement posts when new Plasma, 
Gear or Frameworks is announced we could let people know e.g.


Plasma 6.2 is out!

Please note: Plasma 6.1 and below will no longer receive any bug fix or 
security updates.

Re: End of life policy

[Justin Zobel]

On 23/1/25 03:06, Albert Astals Cid wrote:

El dimecres, 22 de gener del 2025, a les 4:35:53 (Hora estàndard del Centre
d’Europa),rhkra...@gmail.com va escriure:

On Tuesday, January 21, 2025 05:16:25 PM Albert Astals Cid wrote:

Is it not a consequence from the fact that there's no more releases
planned?

It's weird to say "for things that we don't plan releases there will no be
releases"

What would you write?

 From the peanut gallery: How about:

No more releases planned for this project.

and perhaps, in parenthesis after that, something like (end of project)

But we're not speaking about end of project.

We are speaking about the fact that Okular 24.12.x is not going to be released
anymore because Okular 25.04.x is the next release series, not that we're not
going to release Okular at all anymore.

Cheers,
   Albert


I guess I should try to expand on my thoughts before throwing my ideas 
at the mailing list.


I think my original thought was several fold:

1. How long/which version (tied together as our releases are done at 
regular intervals) do we support each release for things KDE produces, 
e.g. Gear, Plasma, Frameworks?


2. Document this information clearly on our Wiki.

3. On the documentation side, have a single Wiki page per release type 
(Gear, Frameworks, Plasma) that details this.


for example:

Gear

Current supported versions: 24.12.*

Version Release Date Supported

==

24.12   Released 19th December 2024 Yes

24.08   Released 5th August 2024 End of Life*

...

All the older releases...


* End of Life text would be a link to a page on the wiki would describe 
that KDE software is regularly released and it is always recommended to 
upgrade to the latest released version. End of Life software does not 
receive important security updates or bug fixes. More text here about 
why that is important, etc.



I think my goal overall is to set expectations for users and developers 
clearly on our wiki. Don't target End of Life software for development 
and let users know that versions like 24.08, 24.05, 24.02 etc on LTS 
type distros are not supported any longer.

CI Flatpak Builds

[Justin Zobel]

On 24/1/25 02:55, Volker Krause wrote:

On Donnerstag, 23. Januar 2025 10:21:08 Mitteleuropäische Normalzeit Ben
Cooksley wrote:

On Thu, Jan 23, 2025 at 7:21 AM Volker Krause  wrote:

On Mittwoch, 22. Januar 2025 18:52:46 Mitteleuropäische Normalzeit Ben

Cooksley wrote:

On Thu, Jan 23, 2025 at 5:49 AM Volker Krause  wrote:

On Dienstag, 21. Januar 2025 23:11:56 Mitteleuropäische Normalzeit

Albert


Astals Cid wrote:

neochat - NEW

  * https://invent.kde.org/network/neochat/-/pipelines/869365
  
   * flatpak build fails

Same as https://invent.kde.org/network/neochat/-/merge_requests/2127 I
guess,
looks like an API change in libQuotient with the corresponding version
change
still pending (ie. a similar problem we occasionally hit with
Poppler).

The quick solution for this would probably be (temporarily) switching
Flatpak
to the latest release of libQuotient. The IMHO proper solution would

be to


have version bumps at the beginning of a development cycle that
changes
API.

This also raises another question though - should we be strongly
discouraging use of heavily moving targets like upstream dev / master
branches and instead favouring the use of stable branches?
Not really ideal if upstream can essentially break our builds without us
doing anything.

I can't comment on NeoChat, but for Itinerary the builds against the
latest
versions of essential (external) dependencies with varying
intentions/success
in keeping backward compatibility (ZXing, Poppler, Quotient) are very much
deliberate, to catch breakage/regressions early (same as we are now doing
for
KF with Qt pre-releases).

And this is actually working, NeoChat has been fixed to build with the
upcoming
Quotient version, same for Itinerary/Poppler. The only thing we are
missing
for those fixes to take effect is those dependencies bumping their version
numbers.

We could work around that by doing configure-time detection using a
compile
test, but that's a lot of extra work, so we'd better try to address this
upstream first.


I'd very much suggest the use of release tarballs (or stable branches) for
apps that aren't continuously monitoring their dependencies this way
though,
but I'm not aware we have such a case.

Doesn't this interfere somewhat with the long term eventual goal of us
pushing Flatpak binaries directly to Flathub though?
(not to mention make stable branch builds impossible to reproduce in the
long run)

For Itinerary at least the release branch is using release tarballs rather
than (latest) Git branches, matching what we have on Flathub. (This does imply
some manual work at branch time, but at least for me that's more than offset by
what this saves in catching issues early).

But you are right of course that this is abusing Flatpak a bit as CI. That's
not ideal but it's just very tempting as it has minimal extra cost (Flatpak
has to build those dependencies anyway, and Flatpak builds run less often than
normal CI builds).

Regards,
Volker


I've moved this to a new email subject as it's no longer just about 
failing CI builds.


My proposal would be have 3 files in the repository that are Flatpak 
related:


- .flatpak-manifest.yml will continue to exist for git master builds and 
be deployed to https://cdn.kde.org/flatpak/


- org.kde.appname.json which will be for Flathub stable builds will only 
run on release branches when a tag is made (I am hoping CI can be 
triggered by a tag).


- Both will reference a file called org.kde.appname.dependencies.json 
which contains the the dependencies that get build for the app and will 
point to tarballs or tags for released versions.


Flatpak supports referencing external files for build dependencies and 
you can use JSON or YAML interchangeably.


I think this will be good for Flatpak builds as we really want them 
targeting the stable released tarballs, not some function in git master 
of a dependency that *MIGHT* be released in time for the next KDE release.

End of life policy

[Justin Zobel]

Hey Everyone,

I've only been a part of KDE for a few years now but I've seen it 
mentioned multiple times and I'm guessing it's been discussed before but 
I think KDE needs clearly defined end-of-life policies for it's 
software. These are common practice and let users and developers know 
what they should be using.


KDE being a mostly volunteer-driven organization would be well within 
expectations to only support the latest version of it's software.


I'm sending this email in a hope of starting a productive discussion 
around this.


Regards,

Justin

Re: End of life policy

[Justin Zobel]

On 21/1/25 10:41, Neal Gompa wrote:

On Mon, Jan 20, 2025 at 7:03 PM Justin Zobel  wrote:

Hey Everyone,

I've only been a part of KDE for a few years now but I've seen it
mentioned multiple times and I'm guessing it's been discussed before but
I think KDE needs clearly defined end-of-life policies for it's
software. These are common practice and let users and developers know
what they should be using.

KDE being a mostly volunteer-driven organization would be well within
expectations to only support the latest version of it's software.

I'm sending this email in a hope of starting a productive discussion
around this.


My understanding is that we currently only support the latest version.
That is, as soon as a new version arrives, the previous version is no
longer supported or maintained.

Is there a different rule in place?
If this is a rule it is not stated on https://community.kde.org from 
what I can see.

Re: End of life policy

[Justin Zobel]

On 21/1/25 10:50, Albert Astals Cid wrote:

El dimarts, 21 de gener del 2025, a les 1:02:42 (Hora estàndard del Centre
d’Europa), Justin Zobel va escriure:

Hey Everyone,

I've only been a part of KDE for a few years now but I've seen it
mentioned multiple times and I'm guessing it's been discussed before but
I think KDE needs clearly defined end-of-life policies for it's
software. These are common practice and let users and developers know
what they should be using.

KDE being a mostly volunteer-driven organization would be well within
expectations to only support the latest version of it's software.

I'm sending this email in a hope of starting a productive discussion
around this.

Which discussion do you want to have?

Each product has it's own "supported releases" scheme.

KDE Frameworks has "no" supported release, fixes will always come in a new
release that will also include new features. (ignoring KDE Frameworks 5) (and
ignoring infrequent very big breaking things that get their own release)

KDE Gear has a stable release, fixes will come in the for of 3 stable
releases.

Plasma works the same as KDE Gear as far as I understand (ignoring Plasma 5)

Independently released apps decide what they want as "supported releases"
scheme (note that translation wise we don't support more than one stable
branch)

Is the discussion you want to have to change this?

Or to codify it?

Codifying it in writing somewhere.


Or something else?

Cheers,
   Albert


Regards,

Justin

Re: kde-builder: sphinx fails with "no module named sphinx.builders.qthelp

[Justin Zobel]

On 29/1/25 09:34, Heiko Becker wrote:


On Tuesday, 28 January 2025 23:45:22 CET, Alexander Neundorf wrote:
I'm trying to build karchive using kde-builder, and it fails with 
sphinx, sphinx.builders.qthelp is missing. Where should this come 
from ? Or how can I disable this ?


Whatever packages https://pypi.org/project/sphinxcontrib-qthelp/ for 
your distro, I'd say, or -DBUILD_QTHELP_DOCS=FALSE for ecm. Or 
-DBUILD_DOC=FALSE for a even more blunt solution.


ecm should probably grow a check for that python module, besides the 
one for Sphinx itself.


Regards,
Heiko

Likely python3-sphinxcontrib.qthelp

Re: KDE Gear projects with failing CI (master) (28 January 2025)

[Justin Zobel]

On 29/1/25 08:55, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI jobs on
their 4th failing week, it is very important that CI is passing for multiple
reasons.

Good news: 2 repositories were fixed

Bad news: 2 repositories started failing


cantor - NEW
  * https://invent.kde.org/education/cantor/-/pipelines/874728
   * testmaxima timeouts



akregator - NEW
  * https://invent.kde.org/pim/akregator/-/pipelines/870987
   * yaml linter fails


Cheers,
   Albert
Laurent please fix all YAML errors if you're adding linters. I know it's 
not fun but breaking builds is not OK.

Re: Review Requests

[Justin Zobel]

On 22/1/25 17:03, Justin Zobel wrote:

Hey everyone,

Where does the template come from e.g. 
https://invent.kde.org/graphics/karp/-/issues/9? I think each 
distribution method e.g. Flatpak, Snap, etc should be a different 
checkbox.


I also think it should more specifically refer to GitLab builds in 
CI/CD. As often these checklists are used for new apps that aren't 
released yet so won't be published to Flathub or the Snap store, etc.


Once the project is approved, then we can look at publishing to stores 
as the author wants.


Justin


Further this I'd like to add:

- Passing JSON, XML and YAML CI checks where files exist in the repository.

Review Requests

[Justin Zobel]

Hey everyone,

Where does the template come from e.g. 
https://invent.kde.org/graphics/karp/-/issues/9? I think each 
distribution method e.g. Flatpak, Snap, etc should be a different checkbox.


I also think it should more specifically refer to GitLab builds in 
CI/CD. As often these checklists are used for new apps that aren't 
released yet so won't be published to Flathub or the Snap store, etc.


Once the project is approved, then we can look at publishing to stores 
as the author wants.


Justin

Re: KDE Gear projects with failing CI (release/25.04) (29 April 2025)

[Justin Zobel]

On 30/04/2025 06:57, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI jobs on
their 4th failing week, it is very important that CI is passing for multiple
reasons.

Bad news: 3 repositories have started failing

ktrip - NEW
  *https://invent.kde.org/utilities/ktrip/-/pipelines/939695
   * flatpak build fails
Should be fixed by 
https://invent.kde.org/utilities/ktrip/-/merge_requests/98 - local build 
successful already.

Re: KDE Gear projects with failing CI (master) (29 April 2025)

[Justin Zobel]

On 30/04/2025 06:22, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI jobs on
their 4th failing week, it is very important that CI is passing for multiple
reasons.

Bad news: 2 repositories have started failing, 2 are still failing

Good news: 3 repositories fixed

kdenlive - NEW
  *https://invent.kde.org/multimedia/kdenlive/-/pipelines/939952
   * flatpak build fails because of dependency server being down


Not much KDE contributors can do about source infrastructure being down 
(likely temporarily).


However, I am looking to see if I can get in contact with the owners and 
see if they are willing to publish their tarballs on a CDN or other 
distributed channels so we can prevent this in the future.

Re: KDE Gear projects with failing CI (release/25.04) (29 April 2025)

[Justin Zobel]

On 01/05/2025 01:49, Volker Krause wrote:

On Mittwoch, 30. April 2025 02:32:48 Mitteleuropäische Sommerzeit Justin Zobel
wrote:

On 30/04/2025 06:57, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI jobs on
their 4th failing week, it is very important that CI is passing for
multiple reasons.

Bad news: 3 repositories have started failing

ktrip - NEW

   *https://invent.kde.org/utilities/ktrip/-/pipelines/939695
   
* flatpak build fails

Should be fixed by
https://invent.kde.org/utilities/ktrip/-/merge_requests/98 - local build
successful already.

That's for a different branch. This should help though:
https://invent.kde.org/utilities/ktrip/-/merge_requests/99
Bugger! I did not read the subject and just assumed it was master, 
thanks for that!

Re: KDE Gear projects with failing CI (master) (29 April 2025)

[Justin Zobel]

On 30/04/2025 20:38, Ben Cooksley wrote:

On Wed, Apr 30, 2025 at 12:34 PM Justin Zobel  wrote:

On 30/04/2025 06:22, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI jobs on
their 4th failing week, it is very important that CI is passing for multiple
reasons.

Bad news: 2 repositories have started failing, 2 are still failing

Good news: 3 repositories fixed

kdenlive - NEW
  *https://invent.kde.org/multimedia/kdenlive/-/pipelines/939952
   * flatpak build fails because of dependency server being down


Not much KDE contributors can do about source infrastructure being
down (likely temporarily).

However, I am looking to see if I can get in contact with the
owners and see if they are willing to publish their tarballs on a
CDN or other distributed channels so we can prevent this in the
future.


We've had this issue in Craft previously - and the solution there was 
for us to mirror the sources ourselves - which is something all the 
distributions do as well.
There has been a patch work of solutions we've worked with in the past 
in this area and is definitely somewhere we need to do better on.


Cheers,
Ben
I've sent the file to Ben to see if we can get it mirrored. I've 
verified it's sha256sum against Solus' build manifest and linked him to 
Fedora and Arch's as well to ensure we have the correct file. The file 
was sourced it from the Web Archive's Wayback Machine (they have an 
archive of their website).

Re: Proposal: archive KMplayer

[Justin Zobel]

On 13/04/2025 23:48, Nate Graham wrote:
https://invent.kde.org/multimedia/kmplayer/-/commits/master?ref_type=heads 



It appears to not have had any meaningful development in 3 years, and 
it's listed as "still in development and isn't released yet" on 
https://apps.kde.org/kmplayer.


It's not ported to Qt 6, the last release appears to have been 8 years 
ago, and the version on Flathub 
(https://flathub.org/apps/org.kde.kmplayer) is that old, with nearly 
every review on ODRS saying it's broken.


Since it looks like this app's development has stagnated and its 
current form is not working for users, I'd propose we archive it until 
someone wants to resume work and make a new working release, and 
remove it from Flathub until that time as well.



Nate

+1 for archiving

Re: KDE Gear projects with failing CI (master) (18 February 2025)

[Justin Zobel]

On 19/2/25 10:37, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI jobs on
their 4th failing week, it is very important that CI is passing for multiple
reasons.

Good news: 2 repositories were fixed

Bad news: 12 repositories started failing

kimap - NEW
  *https://invent.kde.org/pim/kimap/-/pipelines/88
   * testsession failed


kdenlive - NEW
  *https://invent.kde.org/multimedia/kdenlive/-/pipelines/891402
   * craft windows build failed


kontact - NEW
  *https://invent.kde.org/pim/kontact/-/pipelines/891084
   * craft windows build failed


kate - NEW
  *https://invent.kde.org/utilities/kate/-/pipelines/891876
   * flatpak failed


kwordquiz - NEW
  *https://invent.kde.org/education/kwordquiz/-/pipelines/890572
   * flatpak failed


lokalize - NEW
  *https://invent.kde.org/sdk/lokalize/-/pipelines/891879
   * flatpak failed


kteatime - NEW
  *https://invent.kde.org/utilities/kteatime/-/pipelines/886431
   * flatpak failed


audiotube - NEW
  *https://invent.kde.org/multimedia/audiotube/-/pipelines/890981
   * flatpak failed


keysmith - NEW
  *https://invent.kde.org/utilities/keysmith/-/pipelines/891694
   * flatpak failed


koko - NEW
  *https://invent.kde.org/graphics/koko/-/pipelines/891687
   * flatpak failed


telly-skout - NEW
  *https://invent.kde.org/utilities/telly-skout/-/pipelines/891394
   * flatpak failed


francis - NEW
  *https://invent.kde.org/utilities/francis/-/pipelines/891695
   * flatpak failed




Cheers,
   Albert

All fixed:
francis
koko
keysmith
audiotube
lokalize
kate

The other flatpak failures need more investigation.

Re: KDE Gear projects with failing CI (master) (4 March 2025)

[Justin Zobel]

Indeed! I do like getting these emails as I don't watch every repository 
but want to make sure the Flatpak CI/CD jobs keep running!


On 3/5/25 05:48, Nate Graham wrote:

Hooray!

Thanks for being on top of this, Albert, and thanks everyone for 
keeping our apps' CI pipelines green!



Nate



On 3/4/25 11:45 AM, Albert Astals Cid wrote:
Please work on fixing them, otherwise i will remove the failing CI 
jobs on
their 4th failing week, it is very important that CI is passing for 
multiple

reasons.

Good news: 3 repositories were fixed and ALL repositories are passing :)

Cheers,
   Albert

Re: Determining KDE Version for Script Compatibility

[Justin Zobel]

The 'kinfo' command which is part of the 'kinfocenter' package *should* 
be pre-installed on any Plasma install can give you the following info. 
This includes 'KDE Plasma Version: 6.3.80' which you can use to 
determine what version of Plasma they are running. Alternatively, if the 
OS is all the same, look at the package info. For example "dnf list 
--installed | grep ^plasma-desktop.x86_64"


kinfo
Operating System: KDE Linux 202503040256
KDE Plasma Version: 6.3.80
KDE Frameworks Version: 6.12.0
Qt Version: 6.8.2
Kernel Version: 6.13.5-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 16 x AMD Ryzen 7 PRO 4750U with Radeon Graphics
Memory: 32 GiB of RAM (29.1 GiB usable)
Graphics Processor: AMD Radeon Graphics

Justin

On 3/5/25 00:15, Данила Скачедубов wrote:


Dear KDE Community,

I hope this message finds you well. I am writing to seek advice on 
determining the KDE version programmatically in my Python scripts.


In my scripts, I have been using the |kwriteconfig5| command to 
configure KDE settings. However, with the release of KDE 6, the binary 
name has changed to |kwriteconfig6|. Since my scripts run on various 
versions of KDE, I need a reliable way to determine the installed KDE 
version without relying on session environment variables.


I am wondering if there is a method using D-Bus or a configuration 
file that stores this information. Any guidance or suggestions on how 
to achieve this would be greatly appreciated.


Thank you for your time and assistance.

Best regards,

Daniel

Re: Disallow or discourage use of "AI" tools

[Justin Zobel]

I am 100% for this. Most AI tools just scrape (read: steal) code from 
whatever source they can, with no attribution or consideration for legal 
rights/copyright.


Accepting any AI generated code is a legal risk unless the source of the 
code can be verified.


I would wager 99.999% of people using AI tools wouldn't know what the 
source of the code is, or how it is licensed.


On 12/05/2025 22:23, Akseli wrote:

Hi

There's been a lot of "AI" slop spam to various KDE projects, bug reports, 
forums, etc..

We should take a more public stance on disallowing all this slop. Lengthy 
gitlab issues that are just full of nonsense generated by a bot just take time 
out of everyones schedules, trying to decipher if its serious or not.

Other projects have already done something similar, see for 
example:https://discourse.gnome.org/t/loupe-no-longer-allows-generative-ai-contributions/27327

I don't care if someone uses those tools in their personal projects, but 
bringing this slop in to our shared space just frustrates people and eats 
resources to go through.

Can we have somekind of official "please don't AI slop in our places" sign 
somewhere?

Thanks,
- Akseli

Re: KDE Gear projects with failing CI (release/25.04) (6 May 2025)

[Justin Zobel]

On 07/05/2025 07:26, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI jobs on
their 4th failing week, it is very important that CI is passing for multiple
reasons.

Bad news: 1 repositories is still failing, 4 have started failing

Good news: 2 repositories have been fixed

kdeconnect-kde - NEW
  *https://invent.kde.org/network/kdeconnect-kde/-/pipelines/942351
   * macos builds fail
Cherry-picked the fixing commit from master: 
https://invent.kde.org/libraries/kosmindoormap/-/commit/b5906789cfba8ec57620733d7be032ece3ca3143

Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)

[Justin Zobel]

On 16/05/2025 19:42, Konstantin Kharlamov wrote:

On Fri, 2025-05-16 at 09:52 +0930, Justin Zobel wrote:

  On 16/05/2025 00:48, Konstantin Kharlamov wrote:

On Fri, 2025-05-16 at 00:29 +0930, Justin Zobel wrote:

  Ethical issues aside, AI has other impacts as well, most notably
environmental via the huge amounts of energy required to first
train
AI and then even using it.
  

Maybe it's just me, but I never understood the reasoning behind "AI
consumes too much power". I mean, I am all for ecology, but this
implies improving technologies, not the opposite. Maybe I'm missing
the
point, but such reason to me seems equal to "stop using phones and
computers, because they consume energy".
  

Using a mobile phone cannot be compared to the power used by data
centres to train AI in the slightest.
  
Just straight off the top of my head, your phone and computer

automatically go to sleep by default. Servers do not.
  
It's also a matter of how these data centres are powered.

Corporations will often go for the cheapest source which is often
dirty non-renewable sources of energy.

Thank you for clarification, I see. I think best course of action here
would be creating some penalties for companies using too much energy,
which may lead to companies investing into research for more efficient
energy production. (this is very simplistic way to describe it, because
going that way would require thinking of a lot of nuances, like company
size, energy amount, etc, etc).

Penalizing plain people I don't think would move anything forward,
because a lone person wouldn't have the equipment to experiment with
energy sources, it has to be someone working fulltime for a university
or a company.
"I think best course of action here would be creating some penalties for 
companies using too much energy" <- Capitalism doesn't work that way.

Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)

[Justin Zobel]

On 17/05/2025 01:40, Christoph Cullmann wrote:

Hi,

just as a concrete example: what to do with

https://invent.kde.org/frameworks/syntax-highlighting/-/merge_requests/698

That is no AI spam but something that doesn't look broken and the submitter did
do manual work.

Can I now accept that just as MIT?

Greetings
Christoph


If the contributor cannot tell you the license(s) of the code that was 
used to generate the code, then it's literally gambling that this code 
wasn't taken from another project by Gemini and used without their 
permission or used in a way that violates the license and opens up the 
KDE e.V. to litigation.


This is an absolutely possible scenario if the author happens to look 
around for their code being re-used. KDE e.V. CAN NOT accept AI 
contributions because the source of the code isn't known.


It really scares me that we would even consider accepting this. I fully 
understand that it is impossible to tell if a user is lying about 
generating code with an AI, but we have to at least remove the KDE e.V. 
from possible harm by rejecting code unless it is sourced from a license 
and privacy respecting model. Which I'm sure there are very few of and 
the ones that exist would have very little code as every single piece of 
code would have to be audited by the owner of the model to ensure that 
it can be distributed and used in their software, and that the owners 
accepts this.


Of course, this still all boils down to trusting contributors. They can 
get code from anywhere and claim at as their own. AI just makes it much 
easier for them to do it.


Justin

Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)

[Justin Zobel]

On 17/05/2025 02:20, Nate Graham wrote:
you skillfully adapted or re-wrote its output using your human brain 
to fit the context, then the result was fine and no policy could 
prevent this, so that part is sort of moot IMO.


It still possibly contains code that is against KDE's licenses. And if 
they rewrite the whole thing from scratch then it's their code, but it 
is highly unlikely that the contributors using AI would do that, they 
want to take the easy road. I agree though that no policy can prevent a 
user using AI and claiming the code as their own, but we have to attempt 
to reduce the liability as much as possible.


I would even be for adding a checkbox in the Merge Request template 
requiring users to declare that no AI was used in this contribution. The 
same can go in the Bugzilla tickets.


Justin

Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)

[Justin Zobel]

On 18/05/2025 16:41, Albert Vaca Cintora wrote:

On Sun, 18 May 2025, 08:59 Justin Zobel,  wrote:

If the contributor cannot tell you the license(s) of the code that
was used to generate the code, then it's literally gambling that
this code wasn't taken from another project by Gemini and used
without their permission or used in a way that violates the
license and opens up the KDE e.V. to litigation.


I'm no lawyer but I would expect that training AI will fall under fair 
use of copyrighted code. If that's not the case already, it will 
probably be soon. The benefits of AI to society are too large to 
autoimpose such a roadblock.


Albert


From my understanding (what others have told me), AI generally does not 
produce good quality code though. So how is that a benefit to society?

Re: Coding assistants for KDE

[Justin Zobel]

On 19/05/2025 06:05, Ingo Klöcker wrote:

On Sonntag, 18. Mai 2025 21:32:20 Mitteleuropäische Sommerzeit Ingo Klöcker
wrote:

Yes, there is the theoretical threat that an AI learned code that's under a
less liberal license like the GPL or even under one of the "new" not-OSI-
approved licenses used by certain companies to prevent Amazon from selling
services based on their code (or even proprietary code; for all we know, Co-
Pilot was trained with the entire source code written by Microsoft), but
that's only a problem if the AI cites this code literally so that we could
be sued for plagiarizing. How realistic is this threat?

To turn this discussion into something positive: Maybe we should train our own
coding assistant AI(s) for Kate/KDevelop with code relevant for C++ and QML
which respects the licenses. We'd have an AI model for writing LGPL code that
was trained with KF and Qt source code (and other KDE code that's LGPL-
compatible) and we'd have a second AI model for writing GPL code that was
trained additionally with all of our GPL code.

Kate would automatically use the correct model based on the SPDX license of
the current file.

Regards,
Ingo
A nice thought, but we would need to invest quite a bit of money into 
this to get it to work correctly, from my understanding.

Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)

[Justin Zobel]

On 19/05/2025 05:02, Ingo Klöcker wrote:

On Sonntag, 18. Mai 2025 16:52:00 Mitteleuropäische Sommerzeit Christoph
Cullmann wrote:

On Sunday, May 18th, 2025 at 09:12, Albert Vaca Cintora

 wrote:

On Sun, 18 May 2025, 08:59 Justin Zobel, wrote:

If the contributor cannot tell you the license(s) of the code that was
used to generate the code, then it's literally gambling that this code
wasn't taken from another project by Gemini and used without their
permission or used in a way that violates the license and opens up the
KDE e.V. to litigation.>

I'm no lawyer but I would expect that training AI will fall under fair use
of copyrighted code. If that's not the case already, it will probably be
soon. The benefits of AI to society are too large to autoimpose such a
roadblock.

if that would happen, then there is just no copyright protection anymore and
all is fair game, I highly doubt that, but yes, that is what companies that
want to get rich with deep learning want to have.

Have I been violating copyright or licenses for decades because I applied the 
patterns I
saw in other Free Software code to my code?


No, because you didn't copy/paste the code, you studied it, learned how 
it worked, and then wrote your own code.



And what about stuff I look(ed) up on stackoverflow?

https://stackoverflow.com/help/licensing

I have applied some of the concepts I learned from writing proprietary code to 
my Free Software code.

IANAL, but I believe concepts cannot be copyrighted.

for all we know, Co-Pilot was trained with the entire source code written by 
Microsoft


Copilot is trained on every piece of code on GitHub, hence why a lot of 
projects started migrating away from it.


Regards,

Justin

Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)

[Justin Zobel]

On 19/05/2025 14:35, Konstantin Kharlamov wrote:

On Mon, 2025-05-19 at 10:03 +0930, Justin Zobel wrote:

On 18/05/2025 16:41, Albert Vaca Cintora wrote:


On Sun, 18 May 2025, 08:59 Justin Zobel,  wrote:

If the contributor cannot tell you the license(s) of the code that 
was used to generate the code, then it's literally gambling that 
this code wasn't taken from another project by Gemini and used 
without their permission or used in a way that violates the license 
and opens up the KDE e.V. to litigation.





I'm no lawyer but I would expect that training AI will fall under 
fair use of copyrighted code. If that's not the case already, it 
will probably be soon. The benefits of AI to society are too large 
to autoimpose such a roadblock.


Albert


From my understanding (what others have told me), AI generally does 
not produce good quality code though. So how is that a benefit to 
society?


I wrote some lengthy answer here, but then I scratched that because I 
realized your question can really generate tons of lengthy replies 
that no one will read 😅 I will say you that: AI is useful for simple 
and tedious tasks. In general, you don't expect that AI will complete 
correctly whatever you asked it to do. Instead you expect it to give 
you some useful base, which you can change/correct/modify to fit 
whatever you actually need.


Like, I dunno, do you have a friend in a foreign country who you want 
to write a recent story, but the story is in english? You ask AI to 
translate it, which will be don "almost good", so what you do then is 
you go over the text and correct everything to match your style. This 
is faster than translating everything manually. In fact, it well 
matches what people-translators were doing for decades: they typically 
translate texts in two phases, one is sort of writing a scratch, and 
the other one is polishing, like adding suitable idioms, etc.


The problem is we're not talking about text here, we're talking about 
code and code has licenses, on which language models don't care about. 
I'm all for AI that helps humanity, but stealing code or using code that 
is incompatible with KDE's license set is not it.


I want AI to solve world hunger, prevent disease and help me do the 
housework :)

Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)

[Justin Zobel]

On 19/05/2025 15:01, Konstantin Kharlamov wrote:

On Mon, 2025-05-19 at 14:53 +0930, Justin Zobel wrote:

On 19/05/2025 14:35, Konstantin Kharlamov wrote:


On Mon, 2025-05-19 at 10:03 +0930, Justin Zobel wrote:


On 18/05/2025 16:41, Albert Vaca Cintora wrote:



On Sun, 18 May 2025, 08:59 Justin Zobel,  wrote:


If the contributor cannot tell you the license(s) of the code 
that was used to generate the code, then it's literally gambling 
that this code wasn't taken from another project by Gemini and 
used without their permission or used in a way that violates the 
license and opens up the KDE e.V. to litigation.





I'm no lawyer but I would expect that training AI will fall under 
fair use of copyrighted code. If that's not the case already, it 
will probably be soon. The benefits of AI to society are too large 
to autoimpose such a roadblock.


Albert


From my understanding (what others have told me), AI generally does 
not produce good quality code though. So how is that a benefit to 
society?


I wrote some lengthy answer here, but then I scratched that because 
I realized your question can really generate tons of lengthy replies 
that no one will read 😅 I will say you that: AI is useful for 
simple and tedious tasks. In general, you don't expect that AI will 
complete correctly whatever you asked it to do. Instead you expect 
it to give you some useful base, which you can change/correct/modify 
to fit whatever you actually need.


Like, I dunno, do you have a friend in a foreign country who you 
want to write a recent story, but the story is in english? You ask 
AI to translate it, which will be don "almost good", so what you do 
then is you go over the text and correct everything to match your 
style. This is faster than translating everything manually. In fact, 
it well matches what people-translators were doing for decades: they 
typically translate texts in two phases, one is sort of writing a 
scratch, and the other one is polishing, like adding suitable 
idioms, etc.


The problem is we're not talking about text here, we're talking about 
code and code has licenses, on which language models don't care 
about. I'm all for AI that helps humanity, but stealing code or using 
code that is incompatible with KDE's license set is not it.


I want AI to solve world hunger, prevent disease and help me do the 
housework :)




Well, you asked how "low quality AI code" benefits society. I have 
many different examples, I came up with one related to translation 
because it was the simplest one to describe (all others resulted in 
too much text) and its morally equivalent, because you similarly get 
poor low-quality base and you improve upon it.


If you want code examples specifically: another simple one that comes 
to my mind is I have in my Emacs config a code that allows to quit 
emacsclient with vim-command `xb` and upon doing so it converts 
Markdown code to bbcode. And there's also similar one for textile. The 
"conversion code" is a terrible O(n²) algorithm written by AI, which 
didn't even work when AI wrote it. But I fixed it (as in, made it 
work), and use it just fine at work to write Markdown text and then 
insert into to either Redmine or Bitrix at their native markup. Don't 
care much for O(n²), because for amounts of texts I write it is 
instantaneous.


Another example is I had to rewrite some project from one language to 
another at work. This is tedious task, so I similarly used AI to 
create a scratch, and then I went over that code refactoring it and 
fixing.


Translations are not code.

Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)

[Justin Zobel]

On 19/05/2025 15:10, Jin Liu wrote:

Justin Zobel 于2025年5月19日周一 08:34写道：

 From my understanding (what others have told me), AI generally does not 
produce good quality code though. So how is that a benefit to society?

 From my personal experience (what I, not others, have personally used
Github Copilot for months), AI makes coding a lot more enjoyable. When
I type an if branch, it completes the else branch. When I type the
first half of a lengthy function call, it completes the rest. My brain
spends a lot less time waiting for my fingers.

So I'm pretty sure it's a benefit to me personally. Is that a benefit
to society? I dunno.

And if KDE implements a ban on AI that excludes my usage, then it
would make contributing to KDE a lot less enjoyable for me, and I'm
pretty sure I'd no longer contribute to KDE and divert my time to
other projects without the ban. Is that a benefit to society? I dunno.

-Jin Liu


I understand that it makes everything easier. That doesn't matter in the 
slightest when you cannot verify the original license of the code allows 
you to use said code or that the license is compatible with KDE.


What this all boils down to, is KDE's liability regarding code from 
unknown origins.


It's clear a lot of people don't care about theft or the environment and 
are happy to use AI without thinking about the true impact.

Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)

[Justin Zobel]

On 19/05/2025 15:28, Jin Liu wrote:

Justin Zobel 于2025年5月19日周一 13:52写道：

I understand that it makes everything easier. That doesn't matter in the 
slightest when you cannot verify the original license of the code allows you to 
use said code or that the license is compatible with KDE.

I don't think a few (<10) lines of code are licensable.


It's clear a lot of people don't care about theft or the environment and are 
happy to use AI without thinking about the true impact.

Insult taken. Is that KDE's official stance that because I use AI in
coding, so "I don't care about theft or the environment", or just your
personal attack on fellow KDE developers?

-Jin Liu

I said people, I was not referring specifically to you or KDE contributors.

Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)

[Justin Zobel]

On 19/05/2025 19:15, Ilya Bizyaev wrote:



On Monday, May 19th, 2025 at 02:34, Justin Zobel  wrote:

On 18/05/2025 16:41, Albert Vaca Cintora wrote:

On Sun, 18 May 2025, 08:59 Justin Zobel,  wrote:

If the contributor cannot tell you the license(s) of the code
that was used to generate the code, then it's literally gambling
that this code wasn't taken from another project by Gemini and
used without their permission or used in a way that violates the
license and opens up the KDE e.V. to litigation.


I'm no lawyer but I would expect that training AI will fall under 
fair use of copyrighted code. If that's not the case already, it 
will probably be soon. The benefits of AI to society are too large 
to autoimpose such a roadblock.


Albert


From my understanding (what others have told me), AI generally does 
not produce good quality code though. So how is that a benefit to 
society?


Well, in that case, those “others” are using them wrong or are just 
spreading second-hand misinformation.


If you really care about the licensing aspect, focus on it instead of 
diverting this thread into other topics with statements like this one.


As a data point, we've recently used AI models for our modernization 
work on https://invent.kde.org/websites/kde-ru, with careful manual 
review of course, and it has helped us perform the amount of work we 
physically would not have had the time to do ourselves. I cannot 
imagine any legal risks from reasonable use of LLMs for web 
development in KDE. If a ban is imposed on it, I'm unlikely to spend 
an order of magniute more time on this tedious work.
As long as that work hasn't violated any copyrights or licensing, I'm 
happy for people to use it. The point is, we do not know where LLMs get 
their content. It is a legal issue. If you don't have the time to do 
something, that is also fine. Most of us are volunteers to KDE, we give 
what time we can.

Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)

[Justin Zobel]

On 15/05/2025 23:57, Konstantin Kharlamov wrote:

On Thu, 2025-05-15 at 16:09 +0200, Felix Ernst wrote:



Late reply, but I also wanted to mention that I am 100% in support of
any anit-AI messaging and policies we might choose.

The wording as linked by Akseli in their first post seems like a good
starting point in that regard:


Other projects have already done something similar, see for
example:
https://discourse.gnome.org/t/loupe-no-longer-allows-generative-ai-contributions/27327

The only use of AI I support needs all its training data to be
licenced in a way that allows use for the AI training e.g. CC0 or
WTFPL licence. This way I don't see ethical issues because the
copyright holders have then given some sort of consenst for this use.

I wouldn't even mind if we went one step further and actively
promoted e.g. Plasma as "free of AI". This does not need to be fully
true, but this would be more of an activism and marketing angle I
would like to see. There is a good chance though that this would not
be a good use of our time but it would align with KDE Eco IMO. (I
know that there are also great uses of AI, but public messaging needs
to be clear and easy to understand, and there is still enough pro-AI
marketing out there to the point that taking the opposite stance
seems sensible to me.)

I'm not sure taking fully opposite stance would be beneficial for
anyone. Pro-AI has a point. And most anti-AI people from my experience
are actually anti-unlicensed-AI, i.e. not anti-AI in general. That's
because full "anti-AI" has no benefits, so there's not much people, who
actually are fully anti-AI. Hence, making public stance "we're all
anti-AI" would be harmful, not only in marketing sense, but also
technologically, because it would require all KDE apps maintainers to
remove support for AI tools (think of Kate completion plugins for
example), which sounds like a nice way to introduce conflict in the
community.
Ethical issues aside, AI has other impacts as well, most notably 
environmental via the huge amounts of energy required to first train AI 
and then even using it.

Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)

[Justin Zobel]

On 16/05/2025 00:48, Konstantin Kharlamov wrote:

On Fri, 2025-05-16 at 00:29 +0930, Justin Zobel wrote:
  
On 15/05/2025 23:57, Konstantin Kharlamov wrote:
  
  
  
On Thu, 2025-05-15 at 16:09 +0200, Felix Ernst wrote:
  
  



Late reply, but I also wanted to mention that I am 100% in
support of
any anit-AI messaging and policies we might choose.

The wording as linked by Akseli in their first post seems like a
good
starting point in that regard:

  
  
Other projects have already done something similar, see for

example:
https://discourse.gnome.org/t/loupe-no-longer-allows-generative-ai-contributions/27327
  
  
The only use of AI I support needs all its training data to be

licenced in a way that allows use for the AI training e.g. CC0 or
WTFPL licence. This way I don't see ethical issues because the
copyright holders have then given some sort of consenst for this
use.

I wouldn't even mind if we went one step further and actively
promoted e.g. Plasma as "free of AI". This does not need to be
fully
true, but this would be more of an activism and marketing angle I
would like to see. There is a good chance though that this would
not
be a good use of our time but it would align with KDE Eco IMO. (I
know that there are also great uses of AI, but public messaging
needs
to be clear and easy to understand, and there is still enough
pro-AI
marketing out there to the point that taking the opposite stance
seems sensible to me.)
  
  
I'm not sure taking fully opposite stance would be beneficial for

anyone. Pro-AI has a point. And most anti-AI people from my
experience
are actually anti-unlicensed-AI, i.e. not anti-AI in general.
That's
because full "anti-AI" has no benefits, so there's not much people,
who
actually are fully anti-AI. Hence, making public stance "we're all
anti-AI" would be harmful, not only in marketing sense, but also
technologically, because it would require all KDE apps maintainers
to
remove support for AI tools (think of Kate completion plugins for
example), which sounds like a nice way to introduce conflict in the
community.
  

  Ethical issues aside, AI has other impacts as well, most notably
environmental via the huge amounts of energy required to first train
AI and then even using it.

Maybe it's just me, but I never understood the reasoning behind "AI
consumes too much power". I mean, I am all for ecology, but this
implies improving technologies, not the opposite. Maybe I'm missing the
point, but such reason to me seems equal to "stop using phones and
computers, because they consume energy".


Using a mobile phone cannot be compared to the power used by data 
centres to train AI in the slightest.


Just straight off the top of my head, your phone and computer 
automatically go to sleep by default. Servers do not.


It's also a matter of how these data centres are powered. Corporations 
will often go for the cheapest source which is often dirty non-renewable 
sources of energy.


The way I see it, AI has three main problems, legal, ethical and 
environmental.


Justin

Re: KDE Gear projects with failing CI (master) (17 June 2025)

[Justin Zobel]

On 18/06/2025 07:31, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI jobs on
their 4th failing week, it is very important that CI is passing for multiple
reasons.

Good news: 1 repo fixed

Bad news: 1 repo still failing, 1 new repo failing

cantor - 3rd week
  *https://invent.kde.org/education/cantor/-/pipelines/97
   * testmaxima fails


gwenview - NEW
  *https://invent.kde.org/graphics/gwenview/-/pipelines/974445
   * nasa does not let us download stuff and flatpak fails


Cheers,
   Albert


Ben, can we please mirror 
http://heasarc.gsfc.nasa.gov/FTP/software/fitsio/c/cfitsio-4.5.0.tar.gz 
- NASA's webserver is often slow, I've experienced this myself.


Thanks,

Justin

Re: KDE Gear projects with failing CI (master) (17 June 2025)

[Justin Zobel]

On 18/06/2025 18:13, Ben Cooksley wrote:

On Wed, Jun 18, 2025 at 7:01 PM Justin Zobel  wrote:

On 18/06/2025 07:31, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI jobs on
their 4th failing week, it is very important that CI is passing for multiple
reasons.

Good news: 1 repo fixed

Bad news: 1 repo still failing, 1 new repo failing

cantor - 3rd week
  *https://invent.kde.org/education/cantor/-/pipelines/97
   * testmaxima fails


gwenview - NEW
  *https://invent.kde.org/graphics/gwenview/-/pipelines/974445
   * nasa does not let us download stuff and flatpak fails


Cheers,
   Albert


Ben, can we please mirror
http://heasarc.gsfc.nasa.gov/FTP/software/fitsio/c/cfitsio-4.5.0.tar.gz
- NASA's webserver is often slow, I've experienced this myself.


I've added it at 
https://files.kde.org/craft/sources/libs/cfitsio/cfitsio-4.6.2.tar.gz 
(well a slightly newer version)


Long term we need a plan around mirroring sources for all the 
dependencies we drag in for all our CD builds as this is not the first 
time we've had issues with upstream infrastructure, source archives 
disappearing or changing out from underneath us, etc.
Ideas on how to do this welcome - appreciate it will make updating 
deps harder for CD builds but the reliability and license compliance 
issues it solves are worth it.
Long term we could implement a small caching proxy for all the builders. 
That way, all subsequent builds come from our local source.

Re: Code of Conduct incidence

[Justin Zobel]

On 04/07/2025 01:57, Łukasz Wojniłowicz wrote:

Hi all,

recently I got an answer like at 
https://bugs.kde.org/show_bug.cgi?id=506334#c12 and was shocked.
Being accused of being insulting, while trying to find the root cause 
of the issue and then commanded for this bug not rolling out perfectly 
from the beginning.

All with the mix of all caps words.
Anybody subscribes to this way of expression?

I'm not sure, if that's the right place. The Code of Conduct site at 
https://kde.org/code-of-conduct/ doesn't contain any address for 
reporting incidents.


Hi Lukasz,

Please send your email to community...@kde.org so that it can be dealt 
with by our Community Working Group.


Regards,

Justin

Re: KDE Gear projects with failing CI (master) (15 July 2025)

[Justin Zobel]

On 16/07/2025 06:21, Albert Astals Cid wrote:

Please work on fixing them, otherwise i will remove the failing CI jobs on
their 4th failing week, it is very important that CI is passing for multiple
reasons.

Good news: 2 repo fixed

Good news #2: All repos are passing :)

Cheers,
   Albert


Yay!

Re: KDE Review Request: Keep Secret

[Justin Zobel]

On 17/07/2025 21:09, Marco Martin wrote:

Should it already be moved to another more public-facing repo to start
to setup CI ?

On Tue, Jul 15, 2025 at 3:22 PM Marco Martin wrote:

Hi all,

I have been working over the last months on an application called Keep Secret.
It is intended to be a password manager gui which uses the Secret
Service DBus api
as backend, therefore it works with KWallet, gnome-keyring, oo7 etc..

The current home is:

https://invent.kde.org/mart/keepsecret

It can be tested by having any secret service set up (or just secret
service enabled in the KWallet config.

I've added a kdereview issue here:
https://invent.kde.org/mart/keepsecret/-/issues/1

The final place for this should be i think in gear, under kdeutils?

did i miss something?

--
Marco Martin
CI can be run in user namespace just fine, so setting up before moving 
is OK.