Re: KDE Builder: request for review

[Harald Sitter]

On Tue, Apr 9, 2024 at 11:26 AM Kevin Kofler  wrote:
>
> ash...@linuxcomp.ru wrote:
> > I've been working on KDE Builder project. This is a reimplementation of
> > kdesrc-build in Python.
>
> What is the point of rewriting a tool originally written in a stable
> language that guarantees long-term backwards compatibility (since the
> originally planned incompatible "Perl 6" was renamed, as it should) and with
> a syntax close to C/C++ (i.e., what KDE software is mostly written in),
> rewriting it in a programming language that releases completely backwards-
> incompatible major versions every few years and whose syntax depends on
> whitespace (!)? Do we not have enough pointless porting busywork for the
> incompatible Qt major releases yet, so now we need the same for KDE Builder?

Yes.

Re: KDE Builder: request for review

[Harald Sitter]

On Mon, Apr 8, 2024 at 10:05 AM  wrote:
>
> Hi all!
>
> I've been working on KDE Builder project. This is a reimplementation of 
> kdesrc-build in Python. At this point, the tool is rather mature, but some 
> minor bugs may probably be unnoticed. I'd like to officially request a review 
> of KDE Builder for declaring it official tool, and deprecating the 
> kdesrc-build. That way we can move forward with new tool.
>
> You can reach me on Matrix at @ashark:kde.org for more instant communications.

^ quoting so it becomes readable hopefully

relevant issue https://invent.kde.org/sdk/kde-builder/-/issues/84

Re: Should we stop distributing source tarballs?

[Harald Sitter]

On Thu, Apr 4, 2024 at 3:38 PM Tobias Leupold  wrote:
>
> Am 04.04.24 um 13:25 schrieb Harald Sitter:
> > On Thu, Apr 4, 2024 at 12:57 PM Tobias Leupold  wrote:
> >> Just what comes into my mind at once. A release is not always only a git 
> >> tag.
> >
> > Doesn't that make your source tarball a derived work from the source
> > in your git tag?
>
> Yes, of course! this was the point of what I wrote ...

But then it's no longer **the** source. The source was your tag.

Re: Should we stop distributing source tarballs?

[Harald Sitter]

On Thu, Apr 4, 2024 at 12:57 PM Tobias Leupold  wrote:
> Just what comes into my mind at once. A release is not always only a git tag.

Doesn't that make your source tarball a derived work from the source
in your git tag?

Re: Retirement of Binary Factory

[Harald Sitter]

On Sun, Feb 18, 2024 at 10:23 AM Ben Cooksley  wrote:
>
> On Sun, Feb 18, 2024 at 2:58 PM Loren Burkholder 
>  wrote:
>>
>> On Saturday, February 17, 2024 8:35:48 PM EST Ben Cooksley wrote:
>> > On Sun, Feb 4, 2024 at 10:26 AM Ben Cooksley  wrote:
>> >
>> > The Binary Factory, alongside it's two build servers, and the Flatpak
>> > repository it provided at https://distribute.kde.org/ has now been
>> > decommissioned.
>>
>> Hi all,
>>
>> Just last evening, I was downloading Filelight on a Windows machine. Due to 
>> the machine being rather ancient and slow, I ended up going for the direct 
>> binary download instead of the Microsoft Store download. The apps.kde.org 
>> page had me download from a Binary Factory link. As of right now, that link 
>> is still on https://apps.kde.org/filelight/, but it obviously doesn't work. 
>> I haven't checked the apps.kde.org source, but it seems that perhaps those 
>> URLs are automatically generated for each app, so it should be trivial to 
>> change or remove them.
>
>
> It would appear that Filelight has not yet enabled themselves for any form of 
> continuous delivery builds aside from Flatpak.
> See 
> https://invent.kde.org/utilities/filelight/-/blob/master/.gitlab-ci.yml?ref_type=heads
>
> If Filelight contributors are still interested in supporting other platforms 
> those builds will need to be added.

I'm curious, why didn't you enable stuff for the things that were
previously building on binary factory?

On Sun, Feb 18, 2024 at 10:23 AM Ben Cooksley  wrote:
>
> On Sun, Feb 18, 2024 at 2:58 PM Loren Burkholder 
>  wrote:
>>
>> On Saturday, February 17, 2024 8:35:48 PM EST Ben Cooksley wrote:
>> > On Sun, Feb 4, 2024 at 10:26 AM Ben Cooksley  wrote:
>> >
>> > The Binary Factory, alongside it's two build servers, and the Flatpak
>> > repository it provided at https://distribute.kde.org/ has now been
>> > decommissioned.
>>
>> Hi all,
>>
>> Just last evening, I was downloading Filelight on a Windows machine. Due to 
>> the machine being rather ancient and slow, I ended up going for the direct 
>> binary download instead of the Microsoft Store download. The apps.kde.org 
>> page had me download from a Binary Factory link. As of right now, that link 
>> is still on https://apps.kde.org/filelight/, but it obviously doesn't work. 
>> I haven't checked the apps.kde.org source, but it seems that perhaps those 
>> URLs are automatically generated for each app, so it should be trivial to 
>> change or remove them.
>
>
> It would appear that Filelight has not yet enabled themselves for any form of 
> continuous delivery builds aside from Flatpak.
> See 
> https://invent.kde.org/utilities/filelight/-/blob/master/.gitlab-ci.yml?ref_type=heads
>
> If Filelight contributors are still interested in supporting other platforms 
> those builds will need to be added.
>
>>
>>
>> Are there other places that need this URL replaced as well? 
>> https://lxr.kde.org/search?%21v=kf6-qt6&_filestring=&_string=binary-factory.kde.org
>>  shows that there are a number of READMEs that still link to Binary Factory, 
>> and Krita has some CI stuff that still references binary-factory.kde.org, 
>> but I have a sneaking suspicion that there are binary-factory.kde.org links 
>> in KDE webpages and other repositories that aren't indexed by lxr.kde.org.
>
>
> I have a checkout of most website repositories on my local system and did a 
> quick grep which showed a variety of hits. Most of them were on README files 
> that were intended to show build status of the website itself.
> Those links would have been broken for some time as websites were converted 
> over a while ago.
>
> Affected sites content wise includes:
> - develop.kde.org
> - digikam.org
> - haruna.kde.org
> - kaidan.im
> - kate-editor.org
> - kdeconnect.kde.org
> - kde.ru
> - kdevelop.org
> - kirogi.org
> - kmymoney.org
> - konversation.kde.org
> - krita.org
> - okular.kde.org
> - plasma-mobile.org
> - rkward.kde.org
> - umbrello.kde.org
>
>
>>
>>
>> - Loren
>
>
> Cheers,
> Ben

Re: revisiting the sycoca

[Harald Sitter]

On Tue, Feb 13, 2024 at 1:13 PM Sune Vuorela  wrote:
>
> On 2024-02-08, Harald Sitter  wrote:
> > It occurs to me that we should ponder sycoca a bit.
> >
> > Currently the sycoca contains 3 types of caches:
>
> At some point I remember David Faure, iirc as part of his QMimeType
> work, removed part of sycoca, but left the remaining bits as a per
> user cache *because* we allow the user to modify things.
>
> I don't know how much of it is still relevant, but I do think we should
> be testing it, both on modern ssd systems, but given our occasional
> marketing drive about keeping older systems running, especially also
> on older systems with a spinning metal disk, rather than a bit handwavy
> "This is probably going to be fine"

Do you have a testing plan in mind?

HS

revisiting the sycoca

[Harald Sitter]

It occurs to me that we should ponder sycoca a bit.

Currently the sycoca contains 3 types of caches:

- the mime cache: should in fact be unnecessary because there is
already a mime.cache in /usr/share/mime?

- the menu structure cache: for the most part only loaded once by
plasmashell so the caching seems a bit questionable (caveat: kopenwith
also uses the menu structure)

- the applications desktop file cache: with most metadata having moved
to json, the desktop file caching sycoca offers seems not particularly
useful any longer as it is basically just caching
/usr/share/applications and variants thereof. In practice we have very
few apps that actually start other apps (notably plasmashell) so they
could just always hold the desktop files in memory and refresh on
inotifies. There is also a new-ish mimeinfo.cache which we can hold on
to.

All in all I am not convinced we still need the sycoca. Indeed one
huge question is why we are holding on to a bespoke cache. If files
need caching then shouldn't we cache them on an xdg level? There is of
course also the point that nobody else seems to need them cached,
calling the sycoca yet more into question.

With all that in mind... how about we deprecated the sycoca? It'd
shave some 5k lines off of kservice in the long run.

HS

Re: Proposal for using gitlab for kdereview process

[Harald Sitter]

https://community.kde.org/Goals/All_about_the_Apps

On Wed, Feb 7, 2024 at 11:16 PM Friedrich W. H. Kossebau
 wrote:
>
> Long time ago, but perhaps there are still memories...
>
> Am Dienstag, 4. Juli 2023, 14:32:59 CET schrieb Jonathan Riddell:
> > I've gone ahead an updated the Sanity checklist
>
> Having come across the checklist items
>
> * Passing KDE neon build
> * App packages in Flatpak, Snap, AppImages and Windows etc as appropriate
>
> I tried to understand the background & motivation, but only found this "I've
> gone ahead an updated" here and the diff from your edit on 4 July 2023:
> https://community.kde.org/index.php?
> title=ReleasingSoftware=next=97120
>
> I assume this was the result of some community discussion. If so I failed to
> witness and now fail to find it. Could you help me to get more insight into
> the previous discussion here?
>
> Cheers
> Friedrich
>
>

Re: FileCopyrightText...

[Harald Sitter]

On Mon, Jan 29, 2024 at 10:49 AM Carl Schwan  wrote:
>
> On Monday, January 29, 2024 10:43:04 AM CET Harald Sitter wrote:
> > do we really need it?
> >
> > systemd for example only has a spdx license header, resulting in much
> > tidier file headers.
> >
> > I entirely fail to understand why we need to slap a FileCopyrightText
> > on files. The copyright surely applies whether or not I put the
> > FileCopyrightText there. The list is also just about always
> > incomplete, further calling its use into question. Not to mention that
> > it is annoying book keeping of information that is already available
> > in git.
> >
> > Can someone shed some light on this?
>
> The reuse FAQ has an entry about why only keeping the copyright information in
> git is a bad idea: https://reuse.software/faq/#vcs-copyright

Yes, that makes no sense to me. Whether I put my copyright stamp on a
file or not has no impact on whether I actually have copyright. That
is to say when someone doesn't add their stamp they would still be a
copyright holder. Which means that unless everyone who ever touched a
file puts their stamp on it, which is something we didn't and don't
enforce, the list is inherently incomplete and by extension useless
... So, authorship data is in fact more relevant here because you get
all would-be copyright holders, not just the ones that bothered to put
their stamp on the file. No? ... Obviously the authors list may still
be incomplete but I'm willing to put money on the fact that 9/10 it is
more complete than whatever the license headers proclaim to be the
case.

> Also when copying file between repo, the git history for that file is often
> lost.

That is a fair point.

TBH I am more arguing against our current policy of requiring this
field. If someone wants to put their stamp on a file I have no
interest in stopping them. But, I for one would be content with just
putting the license there, hence my ponderings.

HS

FileCopyrightText...

[Harald Sitter]

do we really need it?

systemd for example only has a spdx license header, resulting in much
tidier file headers.

I entirely fail to understand why we need to slap a FileCopyrightText
on files. The copyright surely applies whether or not I put the
FileCopyrightText there. The list is also just about always
incomplete, further calling its use into question. Not to mention that
it is annoying book keeping of information that is already available
in git.

Can someone shed some light on this?

HS

Re: Kandalf: request for review

[Harald Sitter]

This isn't going to be very useful, but I'm sure I'm not the only one
who has heard of the story that the Tolkien Estate wasn't too happy
with our original kandalf. Consequently I'm not sure we should
actually name this thing kandalf. But then I wasn't around back then
so I don't know if there is any truth to it or if it's just an urban
legend. Regardless it's confusing to recycle the name for something
entirely different and I'd reconsider the name here. Food for thought.

On Thu, Dec 7, 2023 at 7:10 PM Loren Burkholder
 wrote:
>
> Hi all!
>
> I've been working towards getting Kandalf ready for integration into KDE (and 
> I'd like to thank everyone who has pitched in to help me, mainly Laurent and 
> redstrate). At this point, while the app is not necessarily feature-complete 
> or fully polished, it's getting close to that point. Therefore, I'd like to 
> officially request a review of Kandalf for inclusion in the KDE apps.
>
> You can reach me on Matrix at @lorendb:nheko.im for more instant 
> communications.
>
> Thanks,
> Loren Burkholder

Re: per-issue notifications from sentry

[Harald Sitter]

I've removed all of the default alert rules. Everyone should be able
to setup rules as they see fit though, don't spam other people though
:)

HS

On Sun, Nov 26, 2023 at 3:38 PM Harald Sitter  wrote:
>
> does anyone else find the emails from sentry when a new issue appears
> to be rather useless? they are very noisy and often times not
> interesting since a single crash often doesn't have enough context to
> act on anyway.
>
> should I look into disabling them?
>
> HS

per-issue notifications from sentry

[Harald Sitter]

does anyone else find the emails from sentry when a new issue appears
to be rather useless? they are very noisy and often times not
interesting since a single crash often doesn't have enough context to
act on anyway.

should I look into disabling them?

HS

Re: plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now

[Harald Sitter]

On Mon, Nov 13, 2023 at 4:45 PM  wrote:
> Baloo is under-maintained and it was never in any good state as the
> initial author left it in an state of limbo and vanished.

A bit off topic but maybe it'd be a good idea to talk to the tracker
developers about pooling resources and join their efforts. Having two
desktop indexers on Linux seems a bit of a waste. Like even if baloo
was perfect it'd still be building a completely moot second database
when you use Elisa under GNOME.

HS

CI log verbosity

[Harald Sitter]

What are your thoughts on having the CI be less verbose by default and
instead have an env var or some other toggle to switch into verbose
mode?

Specifically I'm talking about the qtlogging rules that are currently
enabling everything and the kitchen sink. To my mind we should just
use the default rules by default.
I find that 99% of the time the output is entirely useless in finding
what is wrong, if anything it gets in the way because I first have to
find where the test failure is and then instead of reading walls of qt
plugin info I will just proceed to reproduce the problem locally
anyway.

Thoughts?

HS

Re: Breeze and ECM are incompatible for installing icons

[Harald Sitter]

https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html

> Each directory contains icons designed for a certain nominal icon size and 
> scale, as described by the index.theme file
...
> list of subdirectories for this theme. For every subdirectory there must be a 
> section in the index.theme file describing that directory.

Just my 2 cents, but since the specification specifically allows theme
authors to do whatever, if ECM doesn't support that then ECM appears
not spec compliant.

On Thu, Nov 2, 2023 at 2:36 PM David Jarvie  wrote:
>
> Breeze installs its icons in a different directory structure from other icon 
> themes, with the result that the ECM cmake command ecm_install_icons doesn't 
> work for Breeze icons. The only way to install an application specific Breeze 
> icon is to hard code its location, for example 
> "${KDE_INSTALL_ICONDIR}/breeze/actions/22/". I raised a bug against ECM about 
> this, but not unexpectedly it has been rejected as a Breeze issue (see 
> https://bugs.kde.org/show_bug.cgi?id=476208).
>
> Fixing this in Breeze would obviously be a significant change for Breeze, but 
> having a non-working ecm_install_icons function isn't really acceptable. This 
> should ideally be fixed one way or the other in time for the KF6 release.
> --
> David Jarvie
> KAlarm author, KDE developer

Re: drkonqi's many debuggers

[Harald Sitter]

On Tue, Aug 29, 2023 at 5:23 AM Thiago Macieira  wrote:
>
> On Monday, 28 August 2023 12:59:01 PDT Adriaan de Groot wrote:
> > (puts on FreeBSD hat) On the non-GNU side of the world, lldb is the thing
> > that is "installed anyway" and gdb takes extra effort. Though I don't know
> > if the lldb integration works -- I have both installed, and I don't know if
> > I ever bother to interact with DrKonqi (sorry).
>
> True, but the majority of our user base is still Linux, so if we had to choose
> only one, it would have to be gdb.

I am not quite following. We can depend on any debugger we want,
surely? I mean, there are practical implications to consider for sure,
but gdb being the dominant debugger on Linux doesn't prevent us from
depending on lldb instead.

HS

drkonqi's many debuggers

[Harald Sitter]

I am wondering: does anyone actually use anything besides the default
gdb debugger? We have a lot of code just for supporting multiple
debuggers and I am wondering if we couldn't just focus on one debugger
and get less code with a better experience (both in writing and
reading it).

On a related note: does anyone have opinions on using lldb instead of
gdb? It seems much faster to me and should be just as scriptable as
gdb from a quick glance. The trace format would change though, so
that's a challenge. OTOH texty traces are a thing of the past with
sentry anyway.

HS

Re: Do you use votes on Bugzilla tickets to help you make decisions?

[Harald Sitter]

Never looked at them. Never seen the benefit.

On Fri, Aug 4, 2023 at 3:53 PM Nate Graham  wrote:
>
> Hello folks!
>
> I often find myself explaining to users that votes on Bugzilla tickets
> are generally meaningless and not used by most developers to help
> prioritize work. After I explain this, they generally express surprise,
> as it's not obvious.
>
> I find myself wondering whether it would make sense to disable the
> voting feature by default to avoid giving our users this false impression.
>
> So if you *do* take user votes into consideration when determining what
> tickets to prioritize, I'd like to hear from you!
>
>
> Nate

Re: Bug Safari Project

[Harald Sitter]

Amazing stuff!

You should look into making your project reuse compliant
https://apachelog.wordpress.com/2021/04/06/reuse-licensing-helper/
and add ci for it
https://invent.kde.org/plasma/plasma-disks/-/blob/master/.gitlab-ci.yml#L5

On Sat, Jul 22, 2023 at 2:18 PM 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
>
> --
> 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
>

Re: sentry evaluation

[Harald Sitter]

The problem you are describing is because of the evaluative nature of
the current setup, where I was asked to force the entire system to
have limited exposure. In full rollout every report that the user
manually writes in drkonqi will also end up on sentry. Every
additional crash also, so long as the user enabled auto-submission
(that's the current plan anyway). i.e. Sentry would be the superset of
all crashes. We can look into tighter linking between bugzilla and
sentry but, again, that hasn't happened because of the evaluative
nature of things.

HS

On Thu, Jun 1, 2023 at 10:44 PM Nate Graham  wrote:
>
> To be honest, I haven't found Sentry to be that useful in its current
> implementation. The primary issue is that it represents a second source
> of truth for where crash reports live. As a result, developers who
> already struggle to notice Bugzilla-based crash reports have to look in
> a second place, further diving their scarce attention. I haven't seen
> evidence of people regularly interacting with it or looking at its
> crashes beyond the excitement of the initial rollout, so now it's
> largely just a new graveyard of issues being ignored due to insufficient
> developer time.
>
> I think Sentry could make sense to keep if it was implemented for us
> more as a kind of automatic symbolication service that can take a bad
> backtrace, add debug symbols, retrace it, and then pass *that* off to
> DrKonqi so that the resulting Bugzilla ticket is guaranteed to have a
> *good* backtrace in it. That's a real problem we currently have that
> could benefit from being solved in a targeted way.
>
> If we can't or don't want to do that, then Sentry might make sense if it
> were possible for us to bypass the "multiple sources of crash truth"
> issue by completely disabling Bugzilla for crash reports and migrating
> old Bugzilla crashes into sentry. But Then we'd run into the new issue
> that Sentry doesn't permit discussion with the person experiencing the
> crash to ask for more details if needed. This isn't always needed, but
> it sometimes is. Sentry also isn't integrated into our issue priority
> tracking system in Bugzilla, but that's a more minor issue.
>
> Nate
>
>
>
> On 6/1/23 04:35, Harald Sitter wrote:
> > Hey,
> >
> > We've had almost a year, albeit in a super limited capacity for git
> > builds, with sentry (https://errors-eval.kde.org) and we should
> > probably render a final verdict on the evaluation.
> >
> > Did you like it?
> > What could be improved?
> > Should we move ahead with a more permanent setup?
> >
> > The overall game plan would be to have drkonqi ask the user to opt
> > into automatic crash submission when they open drkonqi so we get close
> > to all crashes (the ones caught by kcrash) automatically filed into
> > sentry from then on out. To increase exposure of this feature I'd also
> > like to glue it into the feedback KCM but I'm not yet sure if it
> > should be a separate setting or linked to the regular feedback
> > categories, the former sounds more accessible. The current bugzilla
> > based workflow would still be available for when the user actually
> > wants to write a description.
> >
> > (previous discussion: https://markmail.org/thread/6y5paczdposz3aoj)
> >
> > HS

Re: KSvg in kdereview

[Harald Sitter]

LGTM now +2

On Wed, Jun 21, 2023 at 10:04 AM Marco Martin  wrote:
>
> I fixed CI, passes now
>
> On Tue, Jun 20, 2023 at 8:44 PM Ben Cooksley  wrote:
> >
> > Hi all,
> >
> > Sysadmin has just received a request to move this repository to Frameworks, 
> > however after seeing some of the comments raised here regarding the 
> > repository I took a look myself to see if they had been corrected.
> >
> > At this time CI is still broken in KSvg, for both platforms - something 
> > that was mentioned in an earlier email here.
> > This does not inspire confidence that the code is up to scratch.
> >
> > I've therefore declined to move it to Frameworks at this time.
> >
> > Would be appreciated, given this is looking to be promoted to Frameworks, 
> > if people could please have a further look at this repository and comment 
> > as appropriate.
> >
> > Thanks,
> > Ben
> >
> > On Wed, Jun 14, 2023 at 9:12 PM Marco Martin  wrote:
> >>
> >> Hi all,
> >> Some time has passes, and changes have been done in the repo to
> >> address some of the points.
> >> Now there are review requests in plasma-framework which depends on
> >> this repo (and accompanying plasma-workspace, plasma-desktop etc)
> >> It would probably be better to have this in frameworks to have the
> >> rest depending from it?
> >>
> >> On Thu, Apr 20, 2023 at 10:25 AM Marco Martin  wrote:
> >> >
> >> > Hi all,
> >> > A part of plasma-framewrok, which is the one to do SVG-based themes,
> >> > has now been splitted in a standalone library which is intended to be
> >> > a new framework in KF6 (all usages of the plasma-framework version
> >> > will be ported once this officially lands, and then those classes will
> >> > be removed)
> >> > The repo for now lives in
> >> > https://invent.kde.org/libraries/plasmasvg
> >> >
> >> > In the end it will be renamed in ksvg
> >> >
> >> > Comments? reviews?
> >> >
> >> >
> >> > --
> >> > Marco Martin
> >>
> >> --
> >> Marco Martin

Re: kio-extras and the KF5/KF6 period

[Harald Sitter]

On Tue, Jun 20, 2023 at 11:23 PM Sune Vuorela  wrote:
>
> On 2023-06-20, David Redondo  wrote:
> > Harald and I prototyped another solution to build a Qt
> >  5 and Qt 6 version out of the same repo and employed it on
> > plasma-integration: https://invent.kde.org/plasma/plasma-integration/-/
> > merge_requests/91
>
> Did I miss something or is this just branching but without having git to
> help us move stuff between versions?

Yes but no. If we have two branches we also need two tars and everyone
needs to do two things. If we have everything in the same branch then
everything is as usual. Also, the sources are so divergent that
picking is bound to be annoying.

HS

Re: kio-extras and the KF5/KF6 period

[Harald Sitter]

On Tue, Jun 20, 2023 at 3:46 PM Luigi Toscano  wrote:
>
> Harald Sitter ha scritto:
> > On Tue, Jun 20, 2023 at 2:58 PM Luigi Toscano  
> > wrote:
> >>
> >> David Redondo ha scritto:
> >>> Am Mittwoch, 17. Mai 2023, 00:02:18 CEST schrieb Albert Astals Cid:
> >>>> kio-extras provides plugins for kio.
> >>>>
> >>>> So KF5 applications want a KF5 kio-extras and KF6 applications want a KF6
> >>>> kio- extras.
> >>>>
> >>>> If we're going to support a period on which we ship both Kf5 and KF6 
> >>>> based
> >>>> applications we need to:
> >>>>
> >>>> Make sure kf5 and kf6 are coinstallable.
> >>>>
> >>>> a) release two tarballs, one for each KF
> >>>> b) release one tarball that compiles both for kf5 and kf6
> >>>> c) just release the kf6 tarball, stop releasing the kf5 tarball but ask
> >>>> distributions to still install it
> >>>>
> >>>>
> >>>
> >>> Harald and I prototyped another solution to build a Qt
> >>>  5 and Qt 6 version out of the same repo and employed it on
> >>> plasma-integration: https://invent.kde.org/plasma/plasma-integration/-/
> >>> merge_requests/91
> >>> This has the advantage of having the code for both versions in
> >>> the same place and the Qt5 version being not stuck on some old
> >>>  version. Also the translations can be shared automatically since
> >>> they use the same catalog.
> >>> There is one case  where Qt uses unversioned targets and one
> >>> unversioned ecm variable but cadavidn be easily worked around.
> >>
> >>
> >> This is good for example for phonon, and in the future and in retrospective
> >> for stuff like qtcurve, but not much for kio-extras, where the codebases
> >> started to diverge.
> >
> > I don't quite follow, as you can see it uses two different source
> > directories cause the goal was to split qt5 and 6 implementations due
> > to impl divergence. So in point of fact divergence is intended and
> > possible. We basically have two source directories in the same branch
> > and build. We believe a similar technique can be used with repos with
> > little divergence just as well as for ones with huge divergence.
>
> The situation of kio-extras is a bit different, as the translations are not
> fully shared between the two branches and I'd prefer to keep them separate.

Hm. They need to have a different catalog name anyway so they don't
overlap between kio-extras6 and 5 builds. We could still do that in
one branch, couldn't we? e.g.

- /qt6/smb/ (produces kio6_smb.pot)
- /qt5/smb/ (produces kio5_smb.pot)

HS

Re: kio-extras and the KF5/KF6 period

[Harald Sitter]

On Tue, Jun 20, 2023 at 2:58 PM Luigi Toscano  wrote:
>
> David Redondo ha scritto:
> > Am Mittwoch, 17. Mai 2023, 00:02:18 CEST schrieb Albert Astals Cid:
> >> kio-extras provides plugins for kio.
> >>
> >> So KF5 applications want a KF5 kio-extras and KF6 applications want a KF6
> >> kio- extras.
> >>
> >> If we're going to support a period on which we ship both Kf5 and KF6 based
> >> applications we need to:
> >>
> >> Make sure kf5 and kf6 are coinstallable.
> >>
> >> a) release two tarballs, one for each KF
> >> b) release one tarball that compiles both for kf5 and kf6
> >> c) just release the kf6 tarball, stop releasing the kf5 tarball but ask
> >> distributions to still install it
> >>
> >>
> >
> > Harald and I prototyped another solution to build a Qt
> >  5 and Qt 6 version out of the same repo and employed it on
> > plasma-integration: https://invent.kde.org/plasma/plasma-integration/-/
> > merge_requests/91
> > This has the advantage of having the code for both versions in
> > the same place and the Qt5 version being not stuck on some old
> >  version. Also the translations can be shared automatically since
> > they use the same catalog.
> > There is one case  where Qt uses unversioned targets and one
> > unversioned ecm variable but cadavidn be easily worked around.
>
>
> This is good for example for phonon, and in the future and in retrospective
> for stuff like qtcurve, but not much for kio-extras, where the codebases
> started to diverge.

I don't quite follow, as you can see it uses two different source
directories cause the goal was to split qt5 and 6 implementations due
to impl divergence. So in point of fact divergence is intended and
possible. We basically have two source directories in the same branch
and build. We believe a similar technique can be used with repos with
little divergence just as well as for ones with huge divergence.

HS

Re: sentry evaluation

[Harald Sitter]

On Mon, Jun 12, 2023 at 11:39 PM David Edmundson
 wrote:
> I'm not sure the teams and groups really work out right now. Do we
> need to request access to groups and have that approved?

That is how it used to be, yes. I've just sprinkled some code at the
instance that should allow us to forgo the approval system though,
only KDE developers can now log in (which is what the approval was
based on anyway).

The way this works in general is that "issues" get sent to a "project"
and that project can be part of multiple teams but to get access to
the data the developer has to opt into a team with access to a given
project first. Alas, I don't think we'll get around the opt-in.
Someone who's only interested in e.g. kwin would get annoyed by/ignore
the noise caused by e.g. ktuberling. That said, projects can be part
of multiple teams and we can have as many teams as we feel like.

> There was also a minor issue that a plasma bug might have a frameworks
> or Qt fix, but I couldn't reliably say "fixed in next version", it's
> not a case which sentry had a good infra for. (bugzilla also isn't
> amazing at that)

Indeed. It's a complicated problem in particular because we are not
the binary distributor for regular linuxy builds. I don't really have
a good answer here unfortunately.

> >Should we move ahead with a more permanent setup?
>
> 100% has my vote. Can we do things on a per-project basis? We can
> surface things in the Plasma UI right now, and there's still a while
> before release to pivot if needed.

I suppose we could do things per-project. What advantage do you think
we gain from this? Everything routes through drkonqi anyway and at
that point it makes no difference if we are inspecting kate or
kinfocenter.

HS

Re: sentry evaluation

[Harald Sitter]

On Sun, Jun 11, 2023 at 7:13 PM Albert Vaca Cintora
 wrote:
>
> I didn't know we had Sentry! How can we get crash reports from KDE
> Connect through it?

Because this isn't widely rolled out yet, due to evaluation period,
there's only limited data for kdeconnect. Here's one:
https://errors-eval.kde.org/organizations/kde/issues/119/

(currently kdeconnect goes into the fallthrough project, which is
because of insufficient configuration on my part)

HS

Re: sentry evaluation

[Harald Sitter]

On Mon, Jun 5, 2023 at 12:20 AM Albert Astals Cid  wrote:
>
> El dijous, 1 de juny de 2023, a les 12:35:41 (CEST), Harald Sitter va
> escriure:
> > Hey,
> >
> > We've had almost a year, albeit in a super limited capacity for git
> > builds, with sentry (https://errors-eval.kde.org) and we should
> > probably render a final verdict on the evaluation.
> >
> > Did you like it?
>
> Did I miss the email announcing this?

There may have been no email. I've announced it at akademy and blogged about it
https://apachelog.wordpress.com/2022/10/13/kde-crash-tracking-system-%f0%9f%92%a3/

> By clicking on https://errors-eval.kde.org i can't really seem to see anything
> to evaluate either, all it deos is it asks me to join a team.

Yep. To get access to projects you need to be member of a team with
access to that project. E.g. if you join the #plasma team you get
access to the plasma projects. #community has access to everything.

HS

sentry evaluation

[Harald Sitter]

Hey,

We've had almost a year, albeit in a super limited capacity for git
builds, with sentry (https://errors-eval.kde.org) and we should
probably render a final verdict on the evaluation.

Did you like it?
What could be improved?
Should we move ahead with a more permanent setup?

The overall game plan would be to have drkonqi ask the user to opt
into automatic crash submission when they open drkonqi so we get close
to all crashes (the ones caught by kcrash) automatically filed into
sentry from then on out. To increase exposure of this feature I'd also
like to glue it into the feedback KCM but I'm not yet sure if it
should be a separate setting or linked to the regular feedback
categories, the former sounds more accessible. The current bugzilla
based workflow would still be available for when the user actually
wants to write a description.

(previous discussion: https://markmail.org/thread/6y5paczdposz3aoj)

HS

Re: Moving FutureSQL to KDE review

[Harald Sitter]

On Fri, Mar 24, 2023 at 12:23 PM Kevin Kofler  wrote:
>
> Jonah Brüchert wrote:
> > I would like to maintain it as an independent library for now, to be
> > able to use C++20 features […]
>
> What is the point of allowing to build KDE Frameworks with an older C++
> standard (what is the minimum these days?) if "many KDE projects" are going
> to depend on a library that requires C++20 to build? Either we can use C++20
> or we cannot.

KDE frameworks is used by people other than us.

Re: kf6 vs. kf5 conflict report

[Harald Sitter]

On Mon, Mar 20, 2023 at 6:21 PM Luigi Toscano  wrote:
>
> Harald Sitter ha scritto:
> > Salut,
> >
> > Conflict reports are now available form neon ci and can be triggered
> > by yourself. They are usually lagging a day behind as automatic binary
> > builds only occur once a day.
> >
> > Notable changes from last time are that ECM is skipped as a whole and
> > locale conflicts have been resolved. Much smaller file now :)
> >
> > https://build.neon.kde.org/view/testy/job/test_kf6_deconflictor/
>
> That's useful, thanks.
>
> Now, not all translation conflicts have been solved yet, but I don't see any
> in the report. Is that wanted?

Good catch, a bug snuck in when I moved this to the CI. It should be
correctly tracking l10n again now.

HS

Re: kf6 vs. kf5 conflict report

[Harald Sitter]

Salut,

Conflict reports are now available form neon ci and can be triggered
by yourself. They are usually lagging a day behind as automatic binary
builds only occur once a day.

Notable changes from last time are that ECM is skipped as a whole and
locale conflicts have been resolved. Much smaller file now :)

https://build.neon.kde.org/view/testy/job/test_kf6_deconflictor/

HS

what to do with phonon & why aren't you using it?

[Harald Sitter]

Hola!

Why don't you use phonon?

What would it make it useful?

What do you reckon we should do with it?

A bit of background perhaps: wy back when phonon was conceived as
multimedia abstraction library to serve as multimedia pillar. While it
is certainly abstract and a library I'm not so sure about the pillar
aspect ;) In fact, phonon is barely even an abstraction since I only
maintain the vlc backend and nobody else maintains any other backend.
So, one has to wonder if it'd not make more sense to put the bit of
energy that flows into phonon to instead go into qtvlc and not have to
deal with the abstraction element at all. Indeed all these
abstractions seem a bit silly because the multimedia libraries
gstreamer and vlc are already abstractions... it's nesting dolls all
the way down.
With all that in mind I was prototyping a revisit of the API many
years ago. Away from complicated mediagraph pipeline building
abstraction to simple player abstraction (you have a player, you give
it a url, it plays the url, that's it), as indeed that seems to be
what most remaining users want to do these days - hassle free
playback. Perhaps that is a path to take? But then the question
remains, do we need the abstraction at all?

Any and all thoughts welcome.

HS

kf6 vs. kf5 conflict report

[Harald Sitter]

with kf6 progressing nicely here's a first conflict report of files
that appear in both kf6 and kf5 under the same name. this largely
affects translations and docs it seems. this list may not be entirely
comprehensive, I've only thrown together a script in a couple minutes.

one question is whether ECM should be co-installable, not sure if that
has been discussed

report for /usr:
https://collaborate.kde.org/s/3gz2KfoGLsS4TF5

furthermore the following files outside /usr clash between kf6 and 5:
'/etc/xdg/accept-languages.codes'
'/etc/xdg/kshorturifilterrc'
'/etc/xdg/autostart/baloo_file.desktop'
'/lib/udev/rules.d/61-kde-bluetooth-rfkill.rules'

HS

Re: flag icon replacement

[Harald Sitter]

I've started https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/95

On Tue, Feb 21, 2023 at 4:38 PM Volker Krause  wrote:
>
> On Dienstag, 21. Februar 2023 14:08:27 CET Harald Sitter wrote:
> > Our keyboard indicator thingy in plasma is implicitly depending on
> > flag icons from kdelibs4support. We kinda need a replacement. I've
> > done some prototyping on using emojis instead. Should we pursue that
> > approach? and if so where should we put the engine
> > https://phabricator.kde.org/T13722#286177
>
> We are already pretty much set on that approach in many other places (via
> KCountry::emojiFlag). Having an icon engine in addition probably makes sense,
> the lowest possible location would be KGuiAddons I guess?
>
> Regards,
> Volker

flag icon replacement

[Harald Sitter]

Yo

Our keyboard indicator thingy in plasma is implicitly depending on
flag icons from kdelibs4support. We kinda need a replacement. I've
done some prototyping on using emojis instead. Should we pursue that
approach? and if so where should we put the engine
https://phabricator.kde.org/T13722#286177

HS

Re: Bringing Cantata under the KDE umbrella?

[Harald Sitter]

you are making my case for me

On Tue, Feb 21, 2023 at 9:39 AM Reindl Harald  wrote:
>
>
>
> Am 21.02.23 um 07:04 schrieb Harald Sitter:
> >> Part of the incubation process is to gather what's the team working on it.
> >> https://community.kde.org/Incubator/Projects/DescriptionTemplate
> >
> > +1. That said, what we could do is incubate into playground and see if
> > we can assemble the required "Healthy team (healthy proportion of
> > volunteers, inclusive towards new contributors, ideally more than one
> > developer)" if not the incubation would simply fail.
> >
> >> It feels wrong to incubate a project that is already out of
> >> development. Especially when we already have a number of music
> >> players...
> >
> > I feel like there is a bit of nuance here. AFAIK neither libvlc nor
> > gstreamer have support for mpd so this does occupy a niche of its own.
> > Now, whether that justifies having yet another UI instead of investing
> > into backend abstraction of one of our existing UIs is another
> > question entirely. A question I would expect to get an answer TBH. Why
> > incubate cantata when we could make elisa or juk grow mpd support?
> > There is a substantial amount of code in the UI
>
> it's not only the mpd support
>
> features like cached lyrics, lastfm, wikipedia, serverside playlists
> software written to export lyrics so that they are present when you
> switch to info-mode
>
> [harry@srv-rhsoft:~/.cache/cantata]$ disk-usage.sh
> /home/harry/.cache/cantata
>  8136 Files17836 KB   17 MB : albums/
>  7142 Files21459 KB   20 MB : artists/
>  9800 Files  1267415 KB 1237 MB : covers/
>  4798 Files11289 KB   11 MB : covers-scaled/
>100738 Files   108256 KB  105 MB : lyrics/
> 0 Files0 KB0 MB : scrobbling/
> 1 Files7 KB0 MB : wikipedia/

Re: Bringing Cantata under the KDE umbrella?

[Harald Sitter]

On Mon, Feb 20, 2023 at 1:18 PM Aleix Pol  wrote:
>
> 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

+1. That said, what we could do is incubate into playground and see if
we can assemble the required "Healthy team (healthy proportion of
volunteers, inclusive towards new contributors, ideally more than one
developer)" if not the incubation would simply fail.

> It feels wrong to incubate a project that is already out of
> development. Especially when we already have a number of music
> players...

I feel like there is a bit of nuance here. AFAIK neither libvlc nor
gstreamer have support for mpd so this does occupy a niche of its own.
Now, whether that justifies having yet another UI instead of investing
into backend abstraction of one of our existing UIs is another
question entirely. A question I would expect to get an answer TBH. Why
incubate cantata when we could make elisa or juk grow mpd support?
There is a substantial amount of code in the UI.

HS

Re: "Gardening" old bugreports

[Harald Sitter]

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

kde-inotify-survey in kdereview

[Harald Sitter]

https://invent.kde.org/system/kde-inotify-survey

simple kded that watches inotify resources and informs the user when
limits are getting hit (along with a way to bump them slightly)

thanks for your time!

HS

Re: kio-admin in kdereview

[Harald Sitter]

On Sat, Oct 15, 2022 at 9:29 PM Albert Astals Cid  wrote:
>
> El divendres, 14 d’octubre de 2022, a les 10:34:04 (CEST), Harald Sitter va
> escriure:
> > On Thu, Oct 13, 2022 at 10:32 PM Albert Astals Cid  wrote:
> > > El dijous, 13 d’octubre de 2022, a les 1:03:53 (CEST), Harald Sitter va
> > >
> > > escriure:
> > > > On Thu, Oct 13, 2022 at 12:46 AM Albert Astals Cid 
> wrote:
> > > > > Did I misunderstood the code? It looks like this run all of kio with
> > > > > root
> > > > > powers?
> > > >
> > > > That is correct
> > >
> > > That feels like a reasonably big no no with my security hat.
> > >
> > > I'm relatively sure we have not audited all of KIO and it's dependencies
> > > to be "running as root"-safe.
> >
> > It is scary to be sure, but then the user has to opt into shooting in the
> > foot.
>
> How much of that opt in message mentions potential security issues?

None. Just like with kdesu and kdesudo it's merely by virtue of the
authentication dialog that the user opts into any security concerns.

HS

Re: kio-admin in kdereview

[Harald Sitter]

On Thu, Oct 13, 2022 at 10:32 PM Albert Astals Cid  wrote:
>
> El dijous, 13 d’octubre de 2022, a les 1:03:53 (CEST), Harald Sitter va
> escriure:
> > On Thu, Oct 13, 2022 at 12:46 AM Albert Astals Cid  wrote:
> > > Did I misunderstood the code? It looks like this run all of kio with root
> > > powers?
> >
> > That is correct
>
> That feels like a reasonably big no no with my security hat.
>
> I'm relatively sure we have not audited all of KIO and it's dependencies to be
> "running as root"-safe.

It is scary to be sure, but then the user has to opt into shooting in the foot.

> What's the use case of this against the kauth support in file_unix.cpp ?

The latter doesn't exist :(

HS

Re: kio-admin in kdereview

[Harald Sitter]

On Thu, Oct 13, 2022 at 12:46 AM Albert Astals Cid  wrote:
> Did I misunderstood the code? It looks like this run all of kio with root
> powers?

That is correct

kio-admin in kdereview

[Harald Sitter]

Hola

kio-admin implements an admin worker that gives root level access to
the file system

https://invent.kde.org/system/kio-admin

HS

Re: KJournald in KDE-Review

[Harald Sitter]

Neat!

- clazy has some hints
- you could probably use
https://api.kde.org/ecm/module/ECMQtDeclareLoggingCategory.html for
loggincategory.cpp/h?
- for qml you should probably use Kirigami.Units.gridUnit*N instead of
hardcoding sizes
- the hardcoded colors also seem a bit of an odd choice
- they are done already but for future reference you might want to
prefer i18nc over i18n, in particular for single word string such as
`i18n("Url:")` (which btw is also incorrectly capitalized)
- talking about... TopMenuBar doesn't consistently use Title Capitalization
- may be of interest to shove the raw journal pointer into a
unique_ptr asap:
https://invent.kde.org/plasma/drkonqi/-/blob/master/src/coredump/memory.h

On Sun, Oct 9, 2022 at 7:18 PM Andreas Cord-Landwehr
 wrote:
>
> Hi, after a few releases over the past year, I would like to get KJournald
> included in KDE application releases. This project is about providing both an
> QItemModel abstraction library for the C-style journald API and providing an
> efficient graphical browser for journald logs.
>
> Sysadmins moved the repository to KDE Review today, you can find the source
> code here:
>
> https://invent.kde.org/libraries/kjournald
>
> (flatpack packaging is also available for easy trying it out)
>
> Even though KJournald is currently contained in the "libraries" playground
> module, I would like to get it included in the "utilities" module after
> passing KDE Review. The reason is that at the moment I more focus on the
> application part and that is the most user-facing part. Having it in
> "utilities" thus will avoid confusion.
>
> Looking forward for your review comments!
>
> Best regards,
> Andreas
>
>

Re: l10n data move from svn to git

[Harald Sitter]

On Mon, Oct 3, 2022 at 6:37 PM Albert Astals Cid  wrote:
> I'll let Harald answer if any modification needs to be done to the releaseme
> process or not.

There is no pressing need, it works as-is. But we are certainly at a
point where we can rethink the workflow a bit and center it around
gitlab more. Thoughts welcome.

HS

Re: Plasma Welcome Center on KDEReview

[Harald Sitter]

plasma-disks is a fairly exhaustive example code base

On Tue, Sep 20, 2022 at 2:19 AM Nate Graham  wrote:
>
> On 9/18/22 11:03, Harald Sitter wrote:
> > Not all code is licensing policy compliant (e.g. appdata is missing
> > spdx tags). I'd suggest enabling the reuse linter pipeline.
>
> How do I do this? Is there an example I can copy from elsewhere (which
> in case people haven't noticed, is basically how I do everything)?
>
> Nate

Re: Plasma Welcome Center on KDEReview

[Harald Sitter]

Not all code is licensing policy compliant (e.g. appdata is missing
spdx tags). I'd suggest enabling the reuse linter pipeline.

On Fri, Sep 16, 2022 at 6:00 PM Nate Graham  wrote:
>
> Hello folks!
>
> I've been working with Aleix on an onboarding wizard for Plasma, based
> on work originally started by Felipe Kinoshita last year.
>
> You can see some screenshots at
> https://invent.kde.org/websites/product-screenshots/-/commit/e300be66e62263c63d8a85ba391bbcc1de691148.
>
> I'd like to target Plasma 5.27 for release and am submitting it for
> KDEReview. The repo is at https://invent.kde.org/plasma/welcome-app.
>
>
> Nate

incubating kdsoap-ws-discovery-client

[Harald Sitter]

Hola,

I'm going to incubate kdsoap-ws-discovery-client [1] as a KDE project.
It's a critical piece of our smb infrastructure. Nate kindly agreed to
be my sponsor (:

[1] https://gitlab.com/caspermeijn/kdsoap-ws-discovery-client

HS

Re: Putting Flatpak KCM through kdereview

[Harald Sitter]

Amazing!

For future reference: there is a sanity check list linked at
https://community.kde.org/Policies/Application_Lifecycle#kdereview
that you can follow to do a pre-review yourself and find most common
issues.

- Messages.sh missing (I see there is an MR pending)
- you should enable CI and in particular also enable the reuse
template to ensure reuse compliance moving forward
- the KCM name has a "Settings" suffix, that seems rather uncoming,
I'd remove it
- clazy is not happy with some stuff, I suggest you do a compile run
with it and fix its complaints
- missing a bugzilla product (request one via sysadmin ticket)
- missing an appstream file
- I have a rather large margin on the right hand side of the permissions view :O
- please always use i18nc() rather than i18n() for new strings and
provide suitable context. in particular for one-word strings... to a
translator it won't at all be obvious in what context "features"
appears or what "pcsc" refers to

All in all really good stuff.

HS

Re: New releases for bugfixes

[Harald Sitter]

On Thu, Sep 8, 2022 at 8:30 AM Sven Brauch  wrote:
>
> Hi,
>
> On 9/7/22 17:28, Harald Sitter wrote:
> > On Wed, Sep 7, 2022 at 5:20 PM  wrote:
> >> In most projects the maintainers who'd make a release decision are the
> >> same people who triage bugs
> >
> > You quite clearly have no idea how this community works. I'll thank
> > you not to misdirect discussions.
>
> in kate it also works very much like this, so while "most projects" is a
> bit of a stretch, there are certainly relevant projects where this is
> the case, so Francis' point is well worth discussing.

You'll really have to enlighten me what it looks like when kate makes
a release decision. I suspect we are talking about different things.

> In fact I share Francis' concern, and I think re-using the
> severity/priority fields to make this decision will add more confusion
> than it provides value.

Why?

> Also consider that a lot of people will set
> these fields in the tracker which are not aware of this policy.

I am sure Nate was envisioning some sort of auditing :) A random user
setting their bug vhi most certainly wouldn't warrant an emergency
release.

> I'd
> instead leave the decision to the project maintainers and they can voice
> it by writing an email to some list.

The way I understand the maintainer would do this?

- user creates bug report: foo crashes on startup
- you identify this as a serious problem because it crashes on first start
- you set the priority vhi
- you fix the bug
- you ask the release team to spin an emergency release on account of
having fixed a vhi bug
- release team makes release

Just to be clear, I'm not sure we need the paperwork of having a bug
and setting it vhi, but we probably do need some workflow to hold on
to. The release team won't be happy if everyone starts asking for
releases because they fixed some random bug. There certainly needs to
be some explanation of why this bug requires immediate fixing. So,
long story short the release team would have to ultimately decide if
this fix is really worth the hassle based on "something".

HS

Re: New releases for bugfixes

[Harald Sitter]

I'm sorry, I neither wanted to upset nor insult.

frameworks has 83 projects, plasma has 65 projects, release service
has 297 = 445 projects to which your blanket statement does not apply.
Their releases run on rails, that's why Nate suggests a way to
introduce additional stops, as it were.

On Thu, Sep 8, 2022 at 3:44 AM  wrote:
>
> On 2022-09-07 16:28, Harald Sitter wrote:
> > On Wed, Sep 7, 2022 at 5:20 PM  wrote:
> >> In most projects the maintainers who'd make a release decision are the
> >> same people who triage bugs
> >
> > You quite clearly have no idea how this community works. I'll thank
> > you not to misdirect discussions.
> >
> > Ta
>
> I find that quite insulting.
>
> I've *been* the guy who had to ask for a new KDevelop release because a
> trivial patch turned out to crash the parser with a specific distro's
> Python setup.
>
> When I had time to work on kdev-python I spent quite a bit of effort
> triaging our bugs and deciding which to work on, and then wbich fixes
> were reasonable to backport.
> I was in the room at Akademy with the whole team doing much the same.
> We never had any separation between the people regularly doing bug
> triaging and the maintainers, and until KDevelop joined the release
> service quite recently the same people did all the releases too.
>
> If you think my perspective from one corner of KDE is skewed, or
> outdated because I've not been active much in the last couple of years,
> I'd be happy to hear it and you'd probably be right.
>
> But a one-line brush-off as if I've never been part of the
> community...that does upset me.
>
> -Francis H

Re: New releases for bugfixes

[Harald Sitter]

On Wed, Sep 7, 2022 at 5:20 PM  wrote:
> In most projects the maintainers who'd make a release decision are the
> same people who triage bugs

You quite clearly have no idea how this community works. I'll thank
you not to misdirect discussions.

Ta

Re: Help with tarme.rb

[Harald Sitter]

On Mon, Sep 5, 2022 at 6:55 AM Tobias Leupold  wrote:
>
> Am Montag, 5. September 2022, 00:19:24 CEST schrieb Tobias Leupold:
> > Hi all,
> >
> > I have a small problem with creating release tarballs. I must have missed
> > something?!
> >
> > Yesterday, I created a release tarball for both KPhotoAlbum and KGeoTag. I
> > first tried to do this as I always did it:
> >
> > ./tarme.rb --origin trunk --version 5.9.0 kphotoalbum
> >
> > that gave me
> >
> > Traceback (most recent call last):
> > 8: from ./tarme.rb:74:in `'
> > 7: from ./tarme.rb:74:in `collect'
> > 6: from ./tarme.rb:81:in `block in '
> > 5: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/
> > release.rb:66:in `get'
> > 4: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/
> > release.rb:154:in `check_ci!'
> > 3: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/
> > jenkins.rb:60:in `from_name_and_branch'
> > 2: from /hd/home/tobias/tmp/git/releaseme/lib/releaseme/
> > jenkins.rb:23:in `get'
> > 1: from /usr/lib64/ruby/2.7.0/net/http/response.rb:133:in
> > `value' /usr/lib64/ruby/2.7.0/net/http/response.rb:124:in `error!': 302
> > "Found" (Net::HTTPRetriableError)
> >
> > Then, I had a look at the wiki and found "--origin stable". I used this, and
> > the tarball was created.
> >
> > Too late, I noticed (thanks Heiko Becker for mailing me!!!) that no
> > translations are included in neither tarball.
> >
> > As said, I must have missed something -- what's wrong?!
> >
> > Thanks for all help for a (after all those years still) junior dev not doing
> > releases too often ... ;-)
> >
> > Cheers, Tobias
>
> I have not much clue about Ruby, but I just noticed that the problem seems to
> originate from "jenkins.rb", where a connection to build.kde.org is
> established. This URL is since recently redirected to metrics.kde.org/login
> (due to the retirement of Jenkins I think).

A fix for this is waiting for its pipeline to succeed.

> Also, invent.kde.org/sysadmin/repo-metadata lists "trunk", "stable",
> "stable_kf5" and "trunk_kf5" in i18n.json, whereas tarme.rb acceps (according
> to "./tarme.rb --help") "trunk", "stable", "lts", "trunk_kde4" and
> "stable_kde4".
>
> So ... is this a tarme.rb issue?!

Nah, trunk and stable in the metadata are simply the legacy (kde4) names

Re: Plasma Remote Controllers in KDE Review

[Harald Sitter]

- src dir is missing i18n setup (messages.sh and define in cmakelists)
- not reuse covered
- metainfo.xml missing (appstream)
- doesn't have gitlab ci builds apparently?
- doesn't have bugzilla product
- clazy is not happy

On Fri, Aug 26, 2022 at 12:21 PM Aditya Mehra  wrote:
>
> Hi,
>
> Plasma remote controllers is in KDE Review and would like to release it along 
> with Plasma Bigscreen
>
> Plasma remote controllers allows translating various input device events into 
> keyboard and pointer events send from remote control type devices like CEC 
> and Gamepads to provide key navigation support in applications. It also 
> allows re mapping of keys to specific events.
>
> You can find the repository here: 
> https://invent.kde.org/plasma-bigscreen/plasma-remotecontrollers
>
> Request to please review Plasma remote controllers.
>
> Regards,
> Aditya

Re: Loosening the commit limit for work branches

[Harald Sitter]

On Thu, Aug 25, 2022 at 11:44 AM Ben Cooksley  wrote:
>
> On Thu, Aug 25, 2022 at 9:27 PM Harald Sitter  wrote:
>>
>> On Wed, Aug 24, 2022 at 8:11 PM Ben Cooksley  wrote:
>> >
>> > On Thu, Aug 25, 2022 at 2:16 AM Harald Sitter  wrote:
>> >>
>> >> On Wed, Aug 24, 2022 at 3:31 PM Noah Davis  wrote:
>> >> >
>> >> > A week ago, I ran into an unexpected issue while working on a QML port
>> >> > of Spectacle. There is an undocumented pre-receive hook that sets a
>> >> > 100 commit limit for all branches of official repos, including work
>> >> > branches. The error message it gave me told me to file a sysadmin
>> >> > ticket, so I did that.
>> >> >
>> >> > The sysadmin ticket link: https://phabricator.kde.org/T15683
>> >> >
>> >> > I don't think I can make the ticket public, so here's the conversation:
>> >> >
>> >> > --- Start of conversation
>> >> >
>> >> > ndavis (me):
>> >> > For normal branches, I would understand this since there were issues
>> >> > with spamming #kde-devel in the past. This isn't necessary for work
>> >> > branches, right? I thought the point of the work/ naming convention
>> >> > was to prevent this issue.
>> >> >
>> >> > bcooksley:
>> >> > Work branches weren't meant to be used for large feature developments
>> >> > with 100+ commits in them, which is why this is being blocked.
>> >> > In it's current state - even if rebased - the branch will not be able
>> >> > to be merged without Sysadmin intervention.
>> >> > Will this be squashed prior to being merged?
>> >> >
>> >> > ndavis:
>> >> > > Will this be squashed prior to being merged?
>> >> >
>> >> > Yes
>> >> >
>> >> > > Work branches weren't meant to be used for large feature developments 
>> >> > > with 100+ commits in them, which is why this is being blocked.
>> >> >
>> >> > Is this documented anywhere? I don't understand why work branches
>> >> > would block this. The git message says notifications are the reason
>> >> > why the push was blocked, but I thought work branches didn't send
>> >> > notifications?
>> >> >
>> >> > bcooksley:
>> >> > The message is a little misleading, but that is mostly because this
>> >> > situation isn't supposed to really occur. You are correct that work
>> >> > branches don't send notifications.
>> >> > As such it is not documented anywhere.
>> >> > From a policy perspective the reason why we don't allow work branches
>> >> > to grow beyond 100 commits is because if we did then you would never
>> >> > be able to merge them in - not without squashing anyway.
>> >> > This therefore makes you "squash as you go".
>> >> > I would generally recommend that major features be developed in an
>> >> > ordinary branch to allow those that monitor kde-commits and other
>> >> > commit feeds to chime in with real-time reviews, and then merged using
>> >> > a traditional Git merge (vs. our more typical rebase)
>> >> >
>> >> > ndavis:
>> >> > > The message is a little misleading, but that is mostly because this 
>> >> > > situation isn't supposed to really occur. You are correct that work 
>> >> > > branches don't send notifications. As such it is not documented 
>> >> > > anywhere.
>> >> >
>> >> > If we are going to keep this limitation, we should document it so that
>> >> > nobody else makes the same mistake as me. We can't assume that
>> >> > something that isn't supposed to happen won't happen because there's
>> >> > no reason to assume this limitation would exist.
>> >> >
>> >> > > From a policy perspective the reason why we don't allow work branches 
>> >> > > to grow beyond 100 commits is because if we did then you would never 
>> >> > > be able to merge them in - not without squashing anyway.
>> >> > This therefore makes you "squash as you go".
>> >> >
>> >> > I don't understand why we have this policy. If we can't merge an MR
>> >> > with over 100 commits,

Re: New releases for bugfixes

[Harald Sitter]

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: Loosening the commit limit for work branches

[Harald Sitter]

On Wed, Aug 24, 2022 at 8:11 PM Ben Cooksley  wrote:
>
> On Thu, Aug 25, 2022 at 2:16 AM Harald Sitter  wrote:
>>
>> On Wed, Aug 24, 2022 at 3:31 PM Noah Davis  wrote:
>> >
>> > A week ago, I ran into an unexpected issue while working on a QML port
>> > of Spectacle. There is an undocumented pre-receive hook that sets a
>> > 100 commit limit for all branches of official repos, including work
>> > branches. The error message it gave me told me to file a sysadmin
>> > ticket, so I did that.
>> >
>> > The sysadmin ticket link: https://phabricator.kde.org/T15683
>> >
>> > I don't think I can make the ticket public, so here's the conversation:
>> >
>> > --- Start of conversation
>> >
>> > ndavis (me):
>> > For normal branches, I would understand this since there were issues
>> > with spamming #kde-devel in the past. This isn't necessary for work
>> > branches, right? I thought the point of the work/ naming convention
>> > was to prevent this issue.
>> >
>> > bcooksley:
>> > Work branches weren't meant to be used for large feature developments
>> > with 100+ commits in them, which is why this is being blocked.
>> > In it's current state - even if rebased - the branch will not be able
>> > to be merged without Sysadmin intervention.
>> > Will this be squashed prior to being merged?
>> >
>> > ndavis:
>> > > Will this be squashed prior to being merged?
>> >
>> > Yes
>> >
>> > > Work branches weren't meant to be used for large feature developments 
>> > > with 100+ commits in them, which is why this is being blocked.
>> >
>> > Is this documented anywhere? I don't understand why work branches
>> > would block this. The git message says notifications are the reason
>> > why the push was blocked, but I thought work branches didn't send
>> > notifications?
>> >
>> > bcooksley:
>> > The message is a little misleading, but that is mostly because this
>> > situation isn't supposed to really occur. You are correct that work
>> > branches don't send notifications.
>> > As such it is not documented anywhere.
>> > From a policy perspective the reason why we don't allow work branches
>> > to grow beyond 100 commits is because if we did then you would never
>> > be able to merge them in - not without squashing anyway.
>> > This therefore makes you "squash as you go".
>> > I would generally recommend that major features be developed in an
>> > ordinary branch to allow those that monitor kde-commits and other
>> > commit feeds to chime in with real-time reviews, and then merged using
>> > a traditional Git merge (vs. our more typical rebase)
>> >
>> > ndavis:
>> > > The message is a little misleading, but that is mostly because this 
>> > > situation isn't supposed to really occur. You are correct that work 
>> > > branches don't send notifications. As such it is not documented anywhere.
>> >
>> > If we are going to keep this limitation, we should document it so that
>> > nobody else makes the same mistake as me. We can't assume that
>> > something that isn't supposed to happen won't happen because there's
>> > no reason to assume this limitation would exist.
>> >
>> > > From a policy perspective the reason why we don't allow work branches to 
>> > > grow beyond 100 commits is because if we did then you would never be 
>> > > able to merge them in - not without squashing anyway.
>> > This therefore makes you "squash as you go".
>> >
>> > I don't understand why we have this policy. If we can't merge an MR
>> > with over 100 commits, why can't we just tell the person making an MR
>> > when they post the MR to squash it? I think it would make more sense
>> > for this policy to apply only when pushing to master or version
>> > branches.
>> >
>> > > I would generally recommend that major features be developed in an 
>> > > ordinary branch to allow those that monitor kde-commits and other commit 
>> > > feeds to chime in with real-time reviews,
>> >
>> > In my experience, nobody does that. Nobody has time to review unless
>> > you explicitly request help or you post an MR.
>> > I don't know the protocol for discussing these kinds of things, so let
>> > me know if this discussion should be moved elsewhere.
>> >
>> &

Re: Loosening the commit limit for work branches

[Harald Sitter]

On Wed, Aug 24, 2022 at 3:31 PM Noah Davis  wrote:
>
> A week ago, I ran into an unexpected issue while working on a QML port
> of Spectacle. There is an undocumented pre-receive hook that sets a
> 100 commit limit for all branches of official repos, including work
> branches. The error message it gave me told me to file a sysadmin
> ticket, so I did that.
>
> The sysadmin ticket link: https://phabricator.kde.org/T15683
>
> I don't think I can make the ticket public, so here's the conversation:
>
> --- Start of conversation
>
> ndavis (me):
> For normal branches, I would understand this since there were issues
> with spamming #kde-devel in the past. This isn't necessary for work
> branches, right? I thought the point of the work/ naming convention
> was to prevent this issue.
>
> bcooksley:
> Work branches weren't meant to be used for large feature developments
> with 100+ commits in them, which is why this is being blocked.
> In it's current state - even if rebased - the branch will not be able
> to be merged without Sysadmin intervention.
> Will this be squashed prior to being merged?
>
> ndavis:
> > Will this be squashed prior to being merged?
>
> Yes
>
> > Work branches weren't meant to be used for large feature developments with 
> > 100+ commits in them, which is why this is being blocked.
>
> Is this documented anywhere? I don't understand why work branches
> would block this. The git message says notifications are the reason
> why the push was blocked, but I thought work branches didn't send
> notifications?
>
> bcooksley:
> The message is a little misleading, but that is mostly because this
> situation isn't supposed to really occur. You are correct that work
> branches don't send notifications.
> As such it is not documented anywhere.
> From a policy perspective the reason why we don't allow work branches
> to grow beyond 100 commits is because if we did then you would never
> be able to merge them in - not without squashing anyway.
> This therefore makes you "squash as you go".
> I would generally recommend that major features be developed in an
> ordinary branch to allow those that monitor kde-commits and other
> commit feeds to chime in with real-time reviews, and then merged using
> a traditional Git merge (vs. our more typical rebase)
>
> ndavis:
> > The message is a little misleading, but that is mostly because this 
> > situation isn't supposed to really occur. You are correct that work 
> > branches don't send notifications. As such it is not documented anywhere.
>
> If we are going to keep this limitation, we should document it so that
> nobody else makes the same mistake as me. We can't assume that
> something that isn't supposed to happen won't happen because there's
> no reason to assume this limitation would exist.
>
> > From a policy perspective the reason why we don't allow work branches to 
> > grow beyond 100 commits is because if we did then you would never be able 
> > to merge them in - not without squashing anyway.
> This therefore makes you "squash as you go".
>
> I don't understand why we have this policy. If we can't merge an MR
> with over 100 commits, why can't we just tell the person making an MR
> when they post the MR to squash it? I think it would make more sense
> for this policy to apply only when pushing to master or version
> branches.
>
> > I would generally recommend that major features be developed in an ordinary 
> > branch to allow those that monitor kde-commits and other commit feeds to 
> > chime in with real-time reviews,
>
> In my experience, nobody does that. Nobody has time to review unless
> you explicitly request help or you post an MR.
> I don't know the protocol for discussing these kinds of things, so let
> me know if this discussion should be moved elsewhere.
>
> --- End of conversation
>
> After this, I decided it would be better to discuss this with the
> broader KDE community and I closed the ticket.
>
> I did try to switch to a normal branch as Ben Cooksley suggested, but
> that had the same limitation. I have not tested using a fork, but some
> of the people I've talked to casually (I can't remember who) seemed to
> be saying that fork branches don't have this limitation, which I think
> would make the limit on work branches kind of pointless if it's true.
>
> I understand the concern about making unmergeable merge requests, but
> I don't think a hard 100 commit limit pre-recieve hook is the right
> way to deal with that. That's something that should be handled by
> reviewers, not automated systems, because sometimes info needs to be
> kept until it is time to merge. Instead of having lots of small
> commits to keep track of each change as much as possible until it's
> time to review the MR, I've had to squash them into mega commits with
> lines in the commit message for each commit that got squashed.
> Normally, I would squash at the end of the review process to ensure
> that all relevant info is kept and irrelevant info is discarded.
>
> 

Re: Incubating app (Git Klient)

[Harald Sitter]

Heya,

You'll need a sponsor https://community.kde.org/Incubator ... not me.
I'm lazy :)

On Sun, Aug 21, 2022 at 11:01 AM Hamed Masafi  wrote:
>
>
> Hello
> As a longtime kde fan(since 3.4), I would love to contribute to this group.
> I am developing a graphical client application for git. I think it is a good 
> option to enter the world of kde.
>
> Features of this program:
>   - The icon displays the files in the Gate folder according to their status 
> in Dolphin.
>   - For easier access to the right-click menu of files and folders, options 
> such as pull, push, delete, ignore, etc. have been added.
>   - Graph display of commits.
>   - General Git operations such as pull, push, fetch.
>   - Show branches and distance of commits from the reference branch.
>   - View files and file contents in each branch or commit.
>   - Compare files, folders, branches and commits in a graphical environment.
>   - Merge conflicting files in git.
>   - Management of remotes, tags.
>   - Auto-completion when writing a commit message.
>   - Markdown editor (written but not yet added to the main program)
>   - And some extra features.
>
> The source is available here:
> https://github.com/HamedMasafi/GitKlient
>
> Currently, only I (Hamid Masafi) am working on the project.
> This project is currently on GitHub, but it can be moved to any other 
> repository if approved by you.
>
> Please take a look at this repository and let me know what you think. I look 
> forward to hearing from you.
>
> Best regards
> Hamed Masafi

Re: Challenge: adding new method overloads when existing consumers use {} with args

[Harald Sitter]

On Mon, Jul 25, 2022 at 2:23 PM Friedrich W. H. Kossebau
 wrote:
>
> Am Montag, 25. Juli 2022, 10:19:39 CEST schrieb David Redondo:
> > Am Samstag, 23. Juli 2022, 17:20:08 CEST schrieb Friedrich W. H. Kossebau:
> > Adding such an overload as in your example is source incompatible
> > regardless. See also our guidelines.
> > https://community.kde.org/Policies/
> > Binary_Compatibility_Issues_With_C%2B%2B#Note_about_ABI
> >
> > You cannot...
> >   For existing functions of any type:
> > Add an overload (binary compatible, but not source compatible: it makes
> >  ambiguous). Adding overloads to already overloaded functions is ok
> > (since any use of  already needed a cast).
>
> Indeed, this also was not on the radar of all those adding the overloads to
> KMessageBox recently, will discuss elsewhere.
>
> But let's try to improve the example then, as the new challenge by {} still
> exists:
>
> Given a class C with methods fpo() and foo(A a):
> --- 8< ---
> class C
> {
> public:
> void foo();
> void foo(A a);
> };
> --- 8< ---
>
> Now you want to add an overload, to serve further use-cases as requested by
> API consumers:
> --- 8< ---
> void foo(B b);
> --- 8< ---
>
>
> But there is existing consumer code, making use of C++17, which calls
> --- 8< ---
> C c;
> c.foo({});
> --- 8< ---
>
> So the new overload will not be source-compatible and break existing code.
>
> What to do about {} being a API addition roadblocker here in C++17 worlds?

We cannot do anything about it. Either we consider it SIC and cannot
add overloads, or we don't and consider it a consumer problem. Seeing
as it breaks existing code I'm sure the way to go is to amend the rule
David mentioned to just outright discourage overloads. A bit
impractical, but then all of source compatibility is a bit impractical
^^

HS

Re: Plasma Bigscreen is in kdereview again

[Harald Sitter]

- not fully reuse compliant. much sad but probably can't be helped
this far into the project :((
- kdeconnect.h has include guards for wifi.h
- kcm_mediacenter_bigscreen_settings may be missing a -DTRANSLATION_DOMAIN
- I would suggest you build with clazy. there are numerous possible
container detachments you could prevent. also many other reasonable
warnings
- you appear to not have an appstream file for the product. is that intentional?

I've only glanced over the code but it all seems fairly reasonable.
HS


On Fri, Jun 24, 2022 at 2:00 PM Aditya Mehra  wrote:
>
> Bump!
>
> Plasma Bigscreen has been in review for a while, can it please be reviewed or 
> released assuming no problems have been detected ? Request to please take 
> this forward as we would like to get proper stable packaging for it with 
> distributions with the next plasma release.
>
> Regards,
> Aditya
> 
> From: Aditya Mehra
> Sent: Friday, May 6, 2022 1:53 AM
> To: kde-core-devel 
> Subject: Plasma Bigscreen is in kdereview again
>
> Hello,
>
> Plasma Bigscreen is in KDE Review again, it was in review the last time and 
> as development went on, we did not leave playground and the review was 
> dropped on our part, sorry. I would like to request you to please review 
> Plasma Bigscreen again as we would like to make a release for it. The 
> repository url is https://invent.kde.org/plasma/plasma-bigscreen
>
> Plasma Bigscreen project consist of a containment for Plasma aimed at a Smart 
> TV interface, it is host to a grid based tile launcher for applications and 
> some specific kcms like wifi, audio devices, launcher settings, and kde 
> connect which can all be navigated with just a usb based remote, hdmi cec 
> connected tv remote, kde connect bigscreen plugin or arrow key navigation on 
> a keyboard.
>
> The project is also integrated with the Mycroft voice assistant open source 
> project, to supports voice commands and Mycroft skills QML interface for 
> providing graphical voice applications.
>
> Regards,
> Aditya

Re: Eloquens now on KDEREVIEW)

[Harald Sitter]

On Wed, Jun 22, 2022 at 12:07 AM Felipe Kinoshita  wrote:
>
> > Could you elaborate why your config.kcfg uses Ints for everything when
> > you clearly want booleans (e.g. `Config.code == 1 ? true : false`)
>
> The API expects ones and zeros for its params, I chose to convert them to
> booleans to make the API call easier to write and change.

Ah! I would suggest moving the conversion into the Controller then. As
far as kcfg, your Config object and your Settings.qml are concerned
they can be proper bools, it's only in the Controller that you have
the presentation requirement that bools must be 0/1. This saves you
the two-way conversion, in the Controller you only need to convert
bool=>int and the rest of the app can treat them as proper bools.

HS

Re: Eloquens now on KDEREVIEW

[Harald Sitter]

On Mon, Jun 20, 2022 at 10:30 PM Felipe Kinoshita  wrote:
>
> For those who don't know, Eloquens is a simple application targeted at 
> developers/designers, it generates the lorem ipsum text and allows you to 
> customize it a little bit like adding heading, bullet lists, etc...
>
> I would also like to ask if it would be possible for it to be released along 
> with KDE Gear.

Neat!

Link for would be reviewers https://invent.kde.org/sdk/eloquens

I mostly have some nit picks:

Your saveWindowGeometryTimer  seems like a huge hack. Why not simply
disable the Connections object when the window is not visible (or only
turn it enabled when the window is fully initialized). There is
absolutely no guarantee that the window will be in a good state after
1 second. It may be 5 it may be 10 it may be 30.

In main.qml you really shouldn't hardcode font.family: "Liberation
Serif";. If you want a serif font then simply use `serif`.

Could you elaborate why your config.kcfg uses Ints for everything when
you clearly want booleans (e.g. `Config.code == 1 ? true : false`)

In Controller::fetch() you can declare and initialize `reply` in the
same line. For the connect in there should pass `this` as third
argument (not passing a context object is usually bad practice cause
the lambda may get called past the captured variable's life)

In App your destructor is unnecessary. You can remove it entirely - it
violates the rule of five. There's also a dangling private: in the
header.

You might want to consider using the reuse-lint template to assert
that reuse compliance doesn't regress
https://invent.kde.org/plasma/plasma-disks/-/blob/master/.gitlab-ci.yml

some desktop file validation: (the last point is because
SingleMainWindow isn't actually a valid key, you should remove it I
guess)

org.kde.eloquens.desktop: hint: value "Qt;KDE;Development;Utility;"
for key "Categories" in group "Desktop Entry" contains more than one
ma
in category; application might appear more than once in the application menu
org.kde.eloquens.desktop: error: file contains key "SingleMainWindow"
in group "Desktop Entry", but keys extending the format should start
with "X-"

Re: Telepathy Contact Runner

[Harald Sitter]

+1 in absence of a fix

On Sun, Jun 19, 2022 at 10:30 PM  wrote:
>
> Hello,
>
> regarding the „Telepathy Contact Runner“ plugin in 
> https://invent.kde.org/network/ktp-contact-runner, I wanted to ask if we 
> could move it to unmaintained.
> There has been very little development in the ktp* repos and even less in 
> this one. Also, it causes https://bugs.kde.org/show_bug.cgi?id=452011.
> A less radical solution is to ask the distributors to no longer ship this 
> plugin as part of a default Plasma installation.
>
> What do you think?
>
> Regards
> Alexander

Re: Git merge workflow: reverse it?

[Harald Sitter]

I'm sure we can, it's one of the technical pillars of the manifesto :)

https://manifesto.kde.org/commitments/

On Tue, May 10, 2022 at 10:59 AM Ingo Klöcker  wrote:
>
> On Dienstag, 10. Mai 2022 09:36:17 CEST Kai Uwe Broulik wrote:
> > can we get an update on this?
> >
> > Plasma is full on cherry-pick now but in KDE Gear it's inconsistent and
> > frustrating when some projects use cherry-pick (e.g. Kate) and some
> > don't (e.g. Dolphin).
> >
> > I don't really mind what the outcome is but I need it to be consistent
> > and predictable where to target my MRs, at least for every domain
> > (Plasma, Gear, ..).
>
> I can imagine a consistent rule for Frameworks (if that's what you mean by
> "domain"). Apart from that I can only imagine a consistent rule per
> development team, e.g. Plasma team or PIM team, but not for Gear as a whole
> which is just a random mix of the products of different teams with different
> workflows. Of course, this doesn't stop the different development teams from
> adopting the same merge workflow. But this cannot be forced on all development
> teams.
>
> Regards,
> Ingo

Re: portal drag and drop helpers and where to put them

[Harald Sitter]

On Tue, Apr 12, 2022 at 10:09 PM Volker Krause  wrote:
>
> On Mittwoch, 6. April 2022 13:28:50 CEST Harald Sitter wrote:
> > https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/212
> >
> > To get sandboxed apps to work with drag and drop we need to have drags
> > take a roundtrip through xdg-desktop-portal and unfortunately enough
> > that needs to happen by passing an open fd into the relevant API,
> > presumably to demonstrate that the sender actually can open the file
> > they want to send. To that end the sender  would call a helper
> > function to extend qmimedata with the relevant transfer context and
> > the receiver needs to reverse that to get to (potentially in-sandbox)
> > paths again.
> >
> > On top of that there's also the fact that we can drag and drop remote
> > sources so we kind of also need to first mount remote urls into the
> > file system using kio-fuse :(
> >
> > All in all it's very broad in scope and requires a dependency on
> > qtdbus so I'm not sure kcoreaddons is necessarily the place for this
> > to live, at the same time we have related API here already so in the
> > interest of keeping related things together kcoreaddons kind of makes
> > the most sense. In particular since the existing helper function for
> > the receiver already existed meaning we get a lot of applciations to
> > support this without further changes.
> >
> > Thoughts would be much appreciated
>
> Is this potentially something for the QPA level? That would seem conceptually
> like the right place and it isn't affected by dependency considerations.
>
> (This might be an entirely stupid suggestion of course, my understanding of
> both the portal interface and the low-level drag/drop handling is extremely
> minimal).

It's a good thought.

The way the Portal works is that we need to pass in file descriptors,
so we need to explicitly open the paths and then pass the fds over
dbus to the portal. That has two implications:

a) to my mind it seems a bit fishy to implicitly open files behind the
developers back
b) because of the open() our applications first need to fuse potential
remote files into the filesystem (e.g. if you drag smb://foo/bar
dolphin would first need to kio-fuse mount that url, then open() the
mount point, then pass that open fd to the portal) - this seems a bit
questionable to have in a QPA

HS

Re: The KIPI fate

[Harald Sitter]

On Sun, Apr 17, 2022 at 12:46 PM Albert Astals Cid  wrote:
>
> El divendres, 15 d’abril de 2022, a les 13:42:43 (CEST), Harald Sitter va 
> escriure:
> > On Fri, Apr 15, 2022 at 12:22 PM Albert Astals Cid  wrote:
> > >  * "severly lacks UI polish" *SO WHAT*
> >
> > I like to think the quality of our products matter.
>
> Of course quality matters, and one very important part of quality is "can 
> this software do what i need it to do?"
>
> > If something looks
> > unpolished it reflects badly on us and the product. That in particular
> > also applies when we have 300 exporters but the one the user wanted to
> > use isn't working. One bad apple spoils the bunch, as it were.
>
> What about the exporter you have been using for decades being removed just 
> because another totally unrelated exporter didn't work?
>
> Software removing features that work and you use without any replacement 
> given would be really a deal-breaker for me.

We can probably agree that removing features is never very cool. At
the same time I would argue that there must be space for this. If we
had a myspace exporter and nobody was willing to port it to purpose
for the 3 remaining myspace users, then that's just something the
myspace users have to deal with (obvious strawman example - I don't
know what exporters kipi had that purpose does not :)). Realistically
there ought to be a cut off point where a feature is not interesting
for us because it has too few users, having both kipi and purpose just
to not lose the myspace exporter seems impractical cause you'd either
force someone to port code for 3 users or to hold on to complexity
that is only there for 3 users. A bad deal one way or the other.

KWin had some effect or other removed a while ago because nobody
maintained it - it's since been redone because people cared enough
IIRC. That is why I think exploring ways to garner metrics before
removals would be super handy.

HS

Re: The KIPI fate

[Harald Sitter]

On Fri, Apr 15, 2022 at 12:22 PM Albert Astals Cid  wrote:
>
> In December KIPI support was removed from gwenview and spectacle with this 
> commit message
>
>
> 
> Drop KIPI support
>
> KIPI offers export functionality for various external services
>
> However it has been abandoned from its original authors and receives no 
> real development any more
>
> A lot, if not all of its providers are defunct and it severly lacks UI 
> polish
>
> Gwenview already has integration with Purpose which offers a similar 
> (albeit theoretically reduced) functionality with a much more polished 
> experience
> 
>
> I disagreed loudly on IRC, because we:
>
>  * If we had to remove things that "receives no real development" we would 
> remove more than half of KDE Gear, remember again, no new features doesn't 
> mean that the software is not maintained.
>
>  * "A lot, if not all of its providers are defunct" that's just simply not 
> true since upon removal i went and tested various of the providers.

I don't know the background but to me it sounds like there's
functionality overlap between kipi and purpose and to that end if one
receives development and the other is only getting kept alive as part
of Gear maintenance then I see why the argument for removal was made.
Specifically having two things cover the same use case seems a bit
silly. I mean, competing is all good and fine, but maybe not in the
same application ;) Whether or not some or even most of the providers
still work only plays a minor role there, if they work the code could
just be salvaged and moved into purpose given interest from someone.
Seeing as this has not happened I'm somewhat leaning to read it as
nobody cares enough, proofing the original point about
non-development. My 2 cents anyway.

>  * "severly lacks UI polish" *SO WHAT*

I like to think the quality of our products matter. If something looks
unpolished it reflects badly on us and the product. That in particular
also applies when we have 300 exporters but the one the user wanted to
use isn't working. One bad apple spoils the bunch, as it were.

>  * "integration with Purpose" useless unless Purpose starts supporting all 
> the providers that KIPI used to support. Unsurprisingly, Purpose has not 
> gained any new plugin support since December
>
> This means that for the KDE Gear 22.04 release both gwenview and spectacle 
> will have less features for our users for no real reason, it's not even that 
> the code removed has hard to maintain in those two applications, it was not 
> more than 500 lines of code in isolated classes.
>
> Personally I would really like to revert those changes, but if not, I would 
> like a wider confirmation that we have decided we don't care about our users 
> that were potentially using those features (we have no way of knowning if 3 
> or 3 million) and if that's the case just archive libkipi and kipi-plugins on 
> invent.kde.org so we can stop releasing and translating them.

After all is said and done, this close to release I would leave things
as they are TBH. If lots of users complain we can still pull a revert
in a patch release, and then expand Purpose's feature set so we can
drop kipi in 22.08. If not enough people complain, I'm +1 on archival
for 22.08. (all with my limited understanding of kipi and purpose mind
you)

Going off on a tangent:
I think you are hitting on a very important point. No matter what
happens with kipi here, we should add userfeedback support for
features that we'd like to remove and get a sense of the users the
removal impacts. Right now we have no metrics, so all we are left with
is removing stuff and see how many people complain and possibly
backpedaling after the fact. That is not ideal.

HS

Re: portal drag and drop helpers and where to put them

[Harald Sitter]

On Tue, Apr 12, 2022 at 2:12 AM Aleix Pol  wrote:
>
> Maybe the alternative would be to use the kdbusaddons for this? It
> seems to me like there's no kcoreaddons things being done.

I've thought about that but ultimately concluded kdbusaddons actually
doesn't work for us. The way the technology works is that the sender
and the receiver need to call a helper function to deal with the
portal logic, if we had those helpers in kdbusaddons we'd need to have
optional kdbusaddons dependencies on every drag and drop enabled
application - it'd be super messy.

HS

portal drag and drop helpers and where to put them

[Harald Sitter]

https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/212

To get sandboxed apps to work with drag and drop we need to have drags
take a roundtrip through xdg-desktop-portal and unfortunately enough
that needs to happen by passing an open fd into the relevant API,
presumably to demonstrate that the sender actually can open the file
they want to send. To that end the sender  would call a helper
function to extend qmimedata with the relevant transfer context and
the receiver needs to reverse that to get to (potentially in-sandbox)
paths again.

On top of that there's also the fact that we can drag and drop remote
sources so we kind of also need to first mount remote urls into the
file system using kio-fuse :(

All in all it's very broad in scope and requires a dependency on
qtdbus so I'm not sure kcoreaddons is necessarily the place for this
to live, at the same time we have related API here already so in the
interest of keeping related things together kcoreaddons kind of makes
the most sense. In particular since the existing helper function for
the receiver already existed meaning we get a lot of applciations to
support this without further changes.

Thoughts would be much appreciated

HS

Re: KSANECore in KDE review

[Harald Sitter]

On Sun, Mar 27, 2022 at 6:29 PM Alexander Stippich  wrote:
>
> Hello everyone,
>
> KSANECore is now in KDE review. Kåre and I mentioned it in previous emails
> before, but as a short summary:
> KSANECore is a Qt interface to the SANE scanner library. It is stripped out of
> the KSaneWidget of libksane without any QWidget dependency. It is currently
> located inside the libksane repository as KSaneCore and basically just copied
> into the new repository.
>
> Due to breaking API anyway, the code was cleaned up, better named as well as
> smaller API fixes made on top. Also, KSANECore is fully REUSE compliant.
> KSaneWidget of libksane will remain ABI compatible.
>
> I don't know if it is strictly required to move the new repo with already
> existing code through KDE review, but I guessed it is better to be on the safe
> side :)
>
> The plan is to switch libksane and Skanpage over to the new library during the
> KDE Gear 22.08 release cycle. The adaptions are located at
> https://invent.kde.org/astippich/skanpage/-/commits/ksanecore
> and
> https://invent.kde.org/astippich/libksane/-/commits/ksanecoreSplit

amazing!

for everyone's convenience here's the url to the lib ;)
https://invent.kde.org/libraries/ksanecore


some comments from scrolling through the code:

you may want to reconsider how stringEnumTranslation works
https://github.com/KDE/clazy/blob/master/docs/checks/README-non-pod-global-static.md
either use q_global_static, or - IMHO neater - move it into the
function loadDeviceOptions as function local static since we don't
need it outside that function anyway.

CoreInterface, CoreInterfacePrivate, InternalOption, ScanThread and
CoreOption should have their constructors marked explicit

the typedefs in coreoption.h are super old school maybe modernize them? ;)

some of the API documentation still refers to libksane, should that be changed?

on a similar note, you still use the KSane namespace and include
guards. It may make sense to rename them KSaneCore and KSANECORE
respectively? for consistency if nothing else

if you havent considered this: you might want to use the clang-format
rules from ECM to join the common formatting we have (and apply that
via commit hooks)

I would argue that reloadDevicesList and getOption(const OptionName
optionEnum); should have their const dropped. the const there doesn't
impact the signature and as such is confusing from an API POV

on a matter of less code noise I would use std::make_unique when
creating new unique ptrs instead of manually passing a raw pointer to
the ctor.

in CoreInterfacePrivate m_batchMode + Delay are uninitialized in the
ctor. please initialize them nullptr

since you have Qt6 ifdefs you may want to enable qt6 CI as well

the shebang line in your Messages.sh appears to have lost its position
and is no longer at the top of the file

you appear to have an autotests dir and cmakelists but no actual tests? :O

Re: Critical Denial of Service bugs in Discover

[Harald Sitter]

On Mon, Feb 21, 2022 at 11:05 AM Ben Cooksley  wrote:
>
> On Mon, Feb 21, 2022 at 10:01 PM Harald Sitter  wrote:
>>
>> On Thu, Feb 10, 2022 at 1:11 PM Aleix Pol  wrote:
>> >
>> > On Thu, Feb 10, 2022 at 11:05 AM Ben Cooksley  wrote:
>> > >
>> > >
>> > >
>> > > On Thu, Feb 10, 2022 at 8:20 AM Aleix Pol  wrote:
>> > >>
>> > >> [Snip]
>> > >>
>> > >> We still haven't discussed here is how to prevent this problem from
>> > >> happening again.
>> > >>
>> > >> If we don't have information about what is happening, we cannot fix 
>> > >> problems.
>> > >
>> > >
>> > > Part of the issue here is that the problem only came to Sysadmin 
>> > > attention very recently, when the system ran out of disk space as a 
>> > > result of growing log files.
>> > > It was at that point we realised we had a serious problem.
>> > >
>> > > Prior to that the system load hadn't climbed to dangerous levels (> 
>> > > number of CPU cores) and Apache was keeping up with the traffic, so none 
>> > > of our other monitoring was tripped.
>> > >
>> > > If you have any thoughts on what sort of information you are thinking of 
>> > > that would be helpful.
>> >
>> > We could have plots of the amount of queries we get with a KNewStuff/*
>> > user-agent over time and their distribution.
>> >
>> > > It would definitely be helpful though to know when new software is going 
>> > > to be released that will be interacting with the servers as we will then 
>> > > be able to monitor for abnormalities.
>> >
>> > We make big announcements of every Plasma release... (?)
>> >
>> > >> Is there anything that could be done in this front? The issue here
>> > >> could have been addressed months ago, we just never knew it was
>> > >> happening.
>> > >
>> > >
>> > > One possibility that did occur to me today would be for us to integrate 
>> > > some kind of killswitch that our applications would check on first 
>> > > initialisation of functionality that talks to KDE.org servers.
>> > > This would allow us to disable the functionality in question on user 
>> > > systems.
>> > >
>> > > The check would only be done on first initialization to keep load low, 
>> > > while still ensuring all users eventually are affected by the killswitch 
>> > > (as they will eventually need to logout/reboot for some reason or 
>> > > another).
>> > >
>> > > The killswitch would probably work best if it had some kind of version 
>> > > check in it so we could specify which versions are disabled.
>> > > That would allow for subsequent updates - once delivered by 
>> > > distributions - to restore the functionality (while leaving it disabled 
>> > > for those who haven't updated).
>> >
>> > The file we are serving here effectively is the kill switch to all of 
>> > KNewStuff.
>>
>> I'm a bit late to the party but for future reference I think this
>> was/is an architectural scaling problem on the server side as much as
>> a bug on the client. If just https load is the problem then the
>> "hotfix" is to use a HTTP load balancer until fixes make it into the
>> clients, killing the clients is like the last resort ever. I'm sure we
>> have the money to afford a bunch of cloud nodes serving as selective
>> proxy caches for a month to balance out the KNS load on the canonical
>> server.
>
>
> This was a multi-fold bug:
>
> 1) Sysadmin allowing a compatibility endpoint to remain alive for years after 
> we told people to stop using it and to use the new one (which is on a CDN and 
> which would have handled this whole issue much better)
> 2) Developers writing code to talk to KDE.org infrastructure without 
> consulting Sysadmin, especially where it deviated from previously established 
> patterns.
>
> In terms of scalability I disagree - the system is not being used here in a 
> manner for which it was not designed.
>
> This system is intended to serve downloads of KDE software and associated 
> data files to distributors and end users. These are actions that are expected 
> to:
> a) Be undertaken on an infrequent basis; and
> b) Be undertaken as a result of user initiated action (such as clicking a 
> download link)
>
> It wa

Re: Critical Denial of Service bugs in Discover

[Harald Sitter]

On Thu, Feb 10, 2022 at 1:11 PM Aleix Pol  wrote:
>
> On Thu, Feb 10, 2022 at 11:05 AM Ben Cooksley  wrote:
> >
> >
> >
> > On Thu, Feb 10, 2022 at 8:20 AM Aleix Pol  wrote:
> >>
> >> [Snip]
> >>
> >> We still haven't discussed here is how to prevent this problem from
> >> happening again.
> >>
> >> If we don't have information about what is happening, we cannot fix 
> >> problems.
> >
> >
> > Part of the issue here is that the problem only came to Sysadmin attention 
> > very recently, when the system ran out of disk space as a result of growing 
> > log files.
> > It was at that point we realised we had a serious problem.
> >
> > Prior to that the system load hadn't climbed to dangerous levels (> number 
> > of CPU cores) and Apache was keeping up with the traffic, so none of our 
> > other monitoring was tripped.
> >
> > If you have any thoughts on what sort of information you are thinking of 
> > that would be helpful.
>
> We could have plots of the amount of queries we get with a KNewStuff/*
> user-agent over time and their distribution.
>
> > It would definitely be helpful though to know when new software is going to 
> > be released that will be interacting with the servers as we will then be 
> > able to monitor for abnormalities.
>
> We make big announcements of every Plasma release... (?)
>
> >> Is there anything that could be done in this front? The issue here
> >> could have been addressed months ago, we just never knew it was
> >> happening.
> >
> >
> > One possibility that did occur to me today would be for us to integrate 
> > some kind of killswitch that our applications would check on first 
> > initialisation of functionality that talks to KDE.org servers.
> > This would allow us to disable the functionality in question on user 
> > systems.
> >
> > The check would only be done on first initialization to keep load low, 
> > while still ensuring all users eventually are affected by the killswitch 
> > (as they will eventually need to logout/reboot for some reason or another).
> >
> > The killswitch would probably work best if it had some kind of version 
> > check in it so we could specify which versions are disabled.
> > That would allow for subsequent updates - once delivered by distributions - 
> > to restore the functionality (while leaving it disabled for those who 
> > haven't updated).
>
> The file we are serving here effectively is the kill switch to all of 
> KNewStuff.

I'm a bit late to the party but for future reference I think this
was/is an architectural scaling problem on the server side as much as
a bug on the client. If just https load is the problem then the
"hotfix" is to use a HTTP load balancer until fixes make it into the
clients, killing the clients is like the last resort ever. I'm sure we
have the money to afford a bunch of cloud nodes serving as selective
proxy caches for a month to balance out the KNS load on the canonical
server.

HS

Re: Genderidentity

[Harald Sitter]

On Fri, Jan 7, 2022 at 12:36 AM Johnny Jazeix  wrote:
> ps : please, don't assume by this answer that I am for or against the third 
> gender and not telling explicitely what is my opinion about it makes me by 
> default against it. I think it is just not the place in GCompris.

I'm not sure why you bother writing so much text for strawman
arguments then. Maybe I'm being daft but this looks like a no-brainer
issue.

What we have right now, right here, is a person that rightly points
out that there are people, that includes children, that do not
identify as boy or girl and we alienate them and make them feel
"other" by using these stand-ins. We can literally change the counting
example to anything else - and if someone complains in the future
about us using a werewolf as depiction for a dog then we change it
again. That being said I think having cute dogs and cute kitties is a
splendid idea, maybe not go with werewolfs ;)

HS

Re: SPDX and docbook documentation, how to do properly?

[Harald Sitter]

On Wed, Jan 5, 2022 at 1:45 PM Friedrich W. H. Kossebau
 wrote:
>
> Hi,
>
> the section "License Statements in Non-Source-Code Files" at
> https://community.kde.org/Guidelines_and_HOWTOs/
> Licensing#License_Statements_in_Non-Source-Code_Files
> currently does not hold an example how to add SPDX tags. And by a quick look
> it seems not many docbook files in KDE repos currently have any such info, so
> no pattern could be derived from the real world samples.
>
> Also unclear to me how to best integrate with the predefined docbook tags, or
> if duplication is needed?
>
> Could we have some example given by those with insights?

I know next to nothing about docbook, but generally speaking this
should simply follow the XML approach I expect


<...docbook entity stuff>


As for the duplication: It is my understanding that we route all our
docbooks through meinproc5, so presumably that could be a place where
we find the SPDX tags and auto-inject them into the docbook DOM - i.e.
my thinking is we turn SPDX into the canonical author information and
then have meinproc inject the DOM nodes accordingly, on the fly. Not
sure how feasible that is though.

HS

FYI neon unstable's kio is now building polkit branch

[Harald Sitter]

ahoy

to enable easier testing of
https://invent.kde.org/frameworks/kio/-/merge_requests/143 KIO in the
neon **unstable** edition is now building work/privilegeexecution
instead of master.

this is particularly of note for bug reports!

HS

Re: Merge stable to master vs cherry-picking

[Harald Sitter]

I'm all for cherry picking. It's both easier and makes sure fixes are
actually available in master.

HS

On Fri, Dec 3, 2021 at 6:55 PM Kai Uwe Broulik  wrote:
>
> Hi everyone,
>
> as part of the GitLab transition in Plasma we changed our commit
> strategy from committing to stable and merging to master to committing
> to master and cherry-picking to stable. Reason being that it's a lot
> more convenient to do from GitLab's UI. I can merge and cherry-pick all
> from the web UI.
>
> However, other projects, such as most of KDE Gear, continues using
> merging, which makes the experience inconsistent and tedious. Fully
> retargeting a branch doesn't seem possible from the UI and not sure if
> you can merge up there either.
>
> What's keeping us from changing the strategy for the rest of KDE, too?
>
> Cheers
> Kai Uwe

Re: Should we consider project basenames unique?

[Harald Sitter]

On Wed, Nov 24, 2021 at 10:02 AM Ben Cooksley  wrote:
> Which means you either provide the path (plasma-mobile/plasma-dialer) or you 
> need to go look in the metadata anyway.

If names are unique (not persistent, just unique) and plasma-dialer is
what I want to release then I know plasma-dialer is called
plasma-dialer because I'm a plasma-dialer dev. I can then call
releasme with the argument  'plasma-dialer' and releaseme can work out
the path from that because the name is global unique so there is only
one plasma-dialer and that will be what I want to release.

HS

Re: Should we consider project basenames unique?

[Harald Sitter]

On Wed, Nov 24, 2021 at 6:00 AM Ben Cooksley  wrote:
>
> On Wed, Nov 24, 2021 at 2:29 PM Aleix Pol  wrote:
>>
>> On Wed, Nov 24, 2021 at 2:10 AM ash...@linuxcomp.ru  
>> wrote:
>> >
>> > Hello.
>> > There is currently a problem that projects are identified by path in 
>> > invent.kde.org. But in pkgbuilds in Arch Linux the makepkg clones repo 
>> > twice, first time to the dir with pkgbuild, and second time to the srcdir 
>> > for build package. And that second repo has first repo as origin, i.e. its 
>> > origin is path to the first repo. And this leads to breakage of 
>> > determining project identifier in cmake module. To workaround, I either 
>> > need to clone to the path that matches the regexp, such as 
>> > crutch.kde.org:pim/zanshin.git or fixing the origin of the problem.
>> >
>> > I wanted to fix it by identifying the project by its name. See 
>> > https://invent.kde.org/sdk/releaseme/-/merge_requests/13.
>> >
>> > Now, the question is, could we consider project names unique? In that 
>> > case, we can merge my mr, and path crutch will not be needed anymore.
>>
>> I agree it would be a problem to have different repositories with the
>> same name. I'm not sure how we can enforce it though.
>
>
> This is something that Sysadmin already encountered and resolved.
>
> Please see the 'identifier' key in the repository metadata (located at 
> https://invent.kde.org/sysadmin/repo-metadata/ in the projects/ subfolder) 
> which we guarantee to be unique.
> This is already used and relied upon by scripty as well as our internal 
> systems (such as commits.kde.org) when referencing repositories.

That is the problem. We, the humans, do not know the identifier nor
should we care. When I want to make a release of plasma-dialer I
should be able to pass plasma-dialer as argument because I know the
repo/project is called plasma-dialer.

> The repository name itself (stripped of any folders) is not guaranteed to be 
> unique.

That is what is proposed to get changed.

HS

Re: Extending the license policy to include ODbL-1.0

[Harald Sitter]

+1

On Wed, Sep 15, 2021 at 5:27 PM Volker Krause  wrote:
>
> Hi,
>
> there's a MR [1] for ki18n containing data tables generated from OSM data,
> which implies the ODbL-1.0 license [2]. We also already have other places
> ([3], [4]) actually doing this.
>
> However that's a license not yet covered by our license policy, so I suggest
> we add it.
>
> ODbL is essentially LGPL-y but for data rather than code, so conceptually
> compatible with our existing licensing.
>
> It's also not like there's any viable alternative to OSM data, so not doing
> this would imply not being able to implement features integrating OSM-derived
> data.
>
> The proposed addition to the policy section of https://community.kde.org/
> Policies/Licensing_Policy would be:
>
>
> # ''Geographic data'', in particular data based on or derived from
> OpenStreetMap may be licensed under the '''[https://spdx.org/licenses/
> ODbL-1.0.html Open Data Commons Open Database License v1.0]'''.
>
>
> What do you think?
>
> Regards,
> Volker
>
> [1] https://invent.kde.org/frameworks/ki18n/-/merge_requests/19
> [2] https://spdx.org/licenses/ODbL-1.0.html
> [3] https://invent.kde.org/pim/kitinerary/-/blob/master/src/lib/knowledgedb/
> timezonedb_data.cpp
> [4] https://invent.kde.org/libraries/kpublictransport/-/blob/master/src/lib/
> knowledgedb/linemetadata_data.cpp

Towards Excellent Defect Management

[Harald Sitter]

For many years now I've been unhappy with both the quality and volume
of crash reports we get for our software. The barrier for crash report
submissions is incredibly high because we've never really had tech to
help elevate "insufficient" reports to become sufficient, outside the
client on which the crash occurred. Out of the very few people that
might want to report a crash even fewer will get beyond the first set
of questions from drkonqi, once they've managed they still have to
fight with their distro for debug symbols and quite possibly lose, and
even if they win there is a good chance the report will either get a
"this isn't very useful. install more symbols" comment or get marked
as dupe. Meanwhile we are spending our days looking at duplicated
crashes, or finding the right blurb to copy paste to ask for a better
trace, or try to find out why software crashes that hasn't actually
crashed for a year because the bug had already been fixed in the
meantime.

We are wasting our users' time. We are wasting our time. This waste
needs to stop.

The good news is that we have all the technical building blocks to fix
it today. In fact, it's even getting better in the future still. All
it takes is a bit of code and a bit of flexibility on our part.

A while ago I started looking into improving the drkonqi experience.
Specifically: submitting crash reports into a purpose built crash
tracking system rather than a bug tracking system. The advantages are
kind of obvious and ranging from server-side de-duplication to
server-side retracing. I've spent many afternoons reading up on and
poking demo instances of every somewhat suitable software I could
find, and Sentry looks like the best option for what we need. It is
practically free software as far as we are concerned, scales
tremendously, has systems for server-side deduplication, server-side
cross-distro/platform retracing (which might also help with some of
the open questions of richer tracing for windows and android), data
scrubbing (what with privacy concerns), client and server-side tags,
can try to figure out when a crash first appeared if supplied with
commit data, can track the quality of specific releases, when a given
crash was fixed, health reports, performance tracking, warning rules,
health report emails, ... I've been playing with it for a month and
still find amazing new things!

One of the best things about Sentry is that it has native support for
debuginfod, enabling us to get debug symbols directly from
distributions, solving the entire cross-distro aspect of crash tracing
in just about the neatest way possible. We get the (incomplete) trace
with lots of metadata, and Senty then uses the metadata to resolve the
symbols through the distros' debuginfod instances to give us a
complete trace.

Even better: with relatively minor adjustments to drkonqi we could use
it right now and get immediate advantage of server-side retracing! I
already have a blob of prototype code for drkonqi that piggybacks
Sentry submission onto the existing code such that we can have both
bugzilla and Sentry.

I am proposing that we roll out a Sentry instance for testing so we
can see if we want to fully embrace it.

You can get a general sense of the features at Sentry's demo instance
https://sentry.io/demo/sandbox/
Here's a code dump for drkonqi
https://invent.kde.org/sitter/drkonqi/-/commits/work/sentry

HS

Re: Skanpage moved to kdereview

[Harald Sitter]

On Wed, Aug 11, 2021 at 9:46 PM Alexander Stippich  wrote:
> > - getUnitString -> can that maybe use
> > https://api.kde.org/frameworks/kcoreaddons/html/classKFormat.html
>
> What do you have in mind here? getUnitString just matches the enum of libksane
> to a unit suffix string, it does not format the values in any way.

I was rather thinking that you can get the localized suffix out of
kformat. but I suppose there is actually no API for that. So...
nevermind.

> > - something is wonky with the "Scan area size" label in the options
> > window. it appears to be constructed from the string "Scan area size"
> > and the string ":". they should be one string though. indeed the other
> > options are one string :shrug:
>
> Hmm, how does this look? I don't see a difference.
> There actually is a subtle difference between how this string and the others
> are obtained: Scan area size is a custom option of libksane and is translated
> there, whereas the others are coming from SANE directly. However, they are all
> appended the same way with "%1:" in Skanpage.

You can only see that sort of thing with the x-test language. If the
label is already translated in libksane I guess that explains it and
is fine.

> > - not really a fan of the comboboxes and long options label in the
> > toolbar. it feels very crowded and with long scanner names the window
> > easily takes up more than half my screen width at minimum size
>
> There has been a discussion already to move the scanner name to the window
> title like it is done in Skanlite. This would save some space. Also, the
> comboboxes are currently not scaled to their content width. Then there would
> also be some possible savings.
> Personally I find the quick access that the comboboxes provide for the most
> important options very useful.

I totally agree that having stuff at the fingertips is ever so handy.
Perhaps also ask the VDG for input?
Dolphin for example has some view properties in the (smaller) bottom
bar rather than the regular toolbar. Perhaps that is something that
could work here.
In any event this isn't anything that holds up the review, just my 2 cents.

HS

Re: Skanpage moved to kdereview

[Harald Sitter]

it works amazingly well. good job! I mostly only have some nitpicky stuff

- since the code base is really close to
complete reuse coverage, it might be nice to push it over the finishing
line and then `reuse lint` it to not have it fall behind again
- your cmake code is GPL but policy-wise it should be BSD-ish. any
chance this can be relicensed?
- for stylistic consistency with other repos you should probably use
https://cmake.org/cmake/help/v3.16/module/FeatureSummary.html
- testconfig.h.in -> I think you want
https://doc.qt.io/qt-5/qtest.html#QFINDTESTDATA ;)
- getUnitString -> can that maybe use
https://api.kde.org/frameworks/kcoreaddons/html/classKFormat.html
- the scanner options window is not high enough by default on my
system (with Noto Sans 10pt as font)
- the options really ought to use an apply/cancel pattern. applying
changes on the fly feels very strange for a KDE app
- something is wonky with the "Scan area size" label in the options
window. it appears to be constructed from the string "Scan area size"
and the string ":". they should be one string though. indeed the other
options are one string :shrug:
- not really a fan of the comboboxes and long options label in the
toolbar. it feels very crowded and with long scanner names the window
easily takes up more than half my screen width at minimum size
- I'm not sure if that is the code's fault (it certainly looks
correct) but in french the documentlist.qml bottom label reads `1
page` when there are no pages

HS

Re: Haruna in kdereview

[Harald Sitter]

On Wed, Jul 21, 2021 at 4:38 PM George Florea Banus
 wrote:
>
> On 21.07.2021 13:53, Harald Sitter wrote:
> > - the color-schemes dir seems to do nothing. it installs files that
> > don't actually exist in the source. fix it or rm -rf?
>
> It had the Breeze color schemes, but I removed them because I don't know
> their licenses
>
> https://bugs.kde.org/show_bug.cgi?id=434465

Good call. Maybe add a comment to the commented out option in the
cmakelists? There is also the question whether it is a good idea to
copy the schemes to begin with though. What's the use case behind
this?

> > - for the screenshots.md and the metainfo.xml you should consider
> > using our screenshot CDN instead
> > https://invent.kde.org/websites/product-screenshots
> Already submitted a merge request
> > - not sure how big of a concern that will be in practice, but you
> > should be careful with calling mimeTypeForFile, it is potentially
> > costly and a local path may still be backed by a network'd mount. when
> > in doubt it's probably better to check KFileItem::isSlow() first and
> > use mimeTypeForUrl when isSlow is true (or resolve the mimetype in a
> > qfuture/thread)
>
> mimeTypeForUrl says it will use mimeTypeForFile for local files. Is
> checking with KFileItem::isSlow() still necessary?

You are right, I am misremember. What you want to do is match on
extension only when the file is slow
https://doc.qt.io/qt-5/qmimedatabase.html#MatchMode-enum

Mind you, putting the mimetype resolution into a QFuture (and not
change the matchmode) still might be better choice over all since you
eventually create previews that will read form the file anyway. So, if
you first resolve a mimetype no harm is done, so long as you don't do
it on the qApp thread.

> Or is it still needed because "a local path may still be backed by a
> network'd mount"?

Yep, that is what KFileItem::isSlow() is telling us. If you always
resolve in a QFuture (even for local files) you don't really need to
check isSlow.

> > - the way static singletons are managed looks a bit old school.
> > function local statics might be neater
> > https://en.cppreference.com/w/cpp/language/storage_duration#Static_local_variables
> >
> > Single *instance() { static Single s; return  }
> >
> > HS
>
> I searched a little about this and people also recommend disabling the
> copying and moving for singletons.
>
> Any opinions on that?

Sounds like a good idea ->
https://doc.qt.io/qt-5/qobject.html#Q_DISABLE_COPY_MOVE in private
section of class should get that sorted

On Wed, Jul 21, 2021 at 4:38 PM George Florea Banus
 wrote:
>
> On 21.07.2021 13:53, Harald Sitter wrote:
> > It's an amazing app! Really awesome.
>
> Thank you.
>
> > - you might want to consider using a newer version in your
> > find_package call for ECM. ECM does enable more modern/useful features
> > but only when used with a suitably high version. so, I'd put this at
> > the actual minimal version you want to support
>
> Done.
>
> > - the color-schemes dir seems to do nothing. it installs files that
> > don't actually exist in the source. fix it or rm -rf?
>
> It had the Breeze color schemes, but I removed them because I don't know
> their licenses
>
> https://bugs.kde.org/show_bug.cgi?id=434465
>
> > - for the screenshots.md and the metainfo.xml you should consider
> > using our screenshot CDN instead
> > https://invent.kde.org/websites/product-screenshots
> Already submitted a merge request
> > - not sure how big of a concern that will be in practice, but you
> > should be careful with calling mimeTypeForFile, it is potentially
> > costly and a local path may still be backed by a network'd mount. when
> > in doubt it's probably better to check KFileItem::isSlow() first and
> > use mimeTypeForUrl when isSlow is true (or resolve the mimetype in a
> > qfuture/thread)
>
> mimeTypeForUrl says it will use mimeTypeForFile for local files. Is
> checking with KFileItem::isSlow() still necessary?
>
> Or is it still needed because "a local path may still be backed by a
> network'd mount"?
>
> > - Application::aboutApplication: we do have an AboutPage in klirigami
> > these days, maybe check that out so you can get rid of the qwidget
> > dialog
>
> Done.
>
> > - you should codify the runtime dep on youtube-dl via cmake. make a
> > dummy finder and set_package_properties it as type RUNTIME e.g.
> > https://invent.kde.org/plasma/plasma-disks/-/blob/master/cmake/Findsmartctl.cmake
> Done.
> > some further nitpicks:
> > - _debug.h should actually be superfluous as qdebug can inject context
> > on its own https://doc.

Re: Haruna in kdereview

[Harald Sitter]

It's an amazing app! Really awesome.

- you might want to consider using a newer version in your
find_package call for ECM. ECM does enable more modern/useful features
but only when used with a suitably high version. so, I'd put this at
the actual minimal version you want to support
- the color-schemes dir seems to do nothing. it installs files that
don't actually exist in the source. fix it or rm -rf?
- for the screenshots.md and the metainfo.xml you should consider
using our screenshot CDN instead
https://invent.kde.org/websites/product-screenshots
- not sure how big of a concern that will be in practice, but you
should be careful with calling mimeTypeForFile, it is potentially
costly and a local path may still be backed by a network'd mount. when
in doubt it's probably better to check KFileItem::isSlow() first and
use mimeTypeForUrl when isSlow is true (or resolve the mimetype in a
qfuture/thread)
- Application::aboutApplication: we do have an AboutPage in klirigami
these days, maybe check that out so you can get rid of the qwidget
dialog
- you should codify the runtime dep on youtube-dl via cmake. make a
dummy finder and set_package_properties it as type RUNTIME e.g.
https://invent.kde.org/plasma/plasma-disks/-/blob/master/cmake/Findsmartctl.cmake

some further nitpicks:
- _debug.h should actually be superfluous as qdebug can inject context
on its own https://doc.qt.io/qt-5/qtglobal.html#qSetMessagePattern
- Application::formatTime might want to use kformat::formatduration
https://api.kde.org/frameworks/kcoreaddons/html/classKFormat.html
- the way static singletons are managed looks a bit old school.
function local statics might be neater
https://en.cppreference.com/w/cpp/language/storage_duration#Static_local_variables

Single *instance() { static Single s; return  }

HS

Re: KHealthCertificate in kdereview

[Harald Sitter]

My only gripe, besides what Albert already pointed out, is that all
the properties are WRITEable but have no NOTIFY signal nor are they
CONSTANT. One of those things ought to change. Considering only the
certificate objects have properties and they are always constructed by
the parsers I guess you could just drop the WRITE and make them
CONSTANT?

There is a somewhat different approach, that I only bring up because I
do enjoy meta programming way too much: Currently the parsers have
exhaustive if-else constructs to map incoming fields to setters. What
you could do is make static maps from incoming keys to property key
and then write the property filing in an abstract fashion e.g. to
illustrate:

> static QMap propertyMap{{"tg", "disease"}, {"fr", 
> "dateOfPositiveTest"}, ...};
> while (reader.hasNext()) {
> cert.setProperty(propertyMap.value(key), CborUtils::readString(reader));
> // needs some error handling when key mapping fails and possibly type 
> conversion helpers
> }

Then the WRITE would make sense and I'd use a single "changed()"
signal to NOTIFY on all the properties. drkonqi's bugzilla library
does something like that to model API objects for example.

HS

Re: KDE CI: Administration » Dependency Build Extragear stable-kf5-qt5 WindowsMSVCQt5.15 - Build # 53 - Still Failing!

[Harald Sitter]

comparing the failing build to the last successful one it appears kdewin no
longer installs arpa/inet.h which lead me to this commit
https://invent.kde.org/packaging/kdewin/-/commit/25a254ab3ab0369e235db7418ac9b95226445a38
which seems a bit folly because it makes the installation conditional on
inet_ntop being available with a **different** header rendering the change
not particularly backwards compatible because of course kdelibs4support is
using the old header. One way forward would certainly be to port
kdelibs4support to an ifdef q_os_win32 that then includes winsock2 instead
of the posix headers. Ralf will probably know best what to do.

On Thu, Jul 8, 2021 at 8:46 AM Ben Cooksley  wrote:

> Hi all,
>
> Please find below a build log from a Windows dependency build job which is
> currently failing in kdelibs4support.
>
> Any ideas what may have caused this?
>
> Thanks,
> Ben
>
> -- Forwarded message -
> From: CI System 
> Date: Thu, Jul 8, 2021 at 8:46 AM
> Subject: KDE CI: Administration » Dependency Build Extragear
> stable-kf5-qt5 WindowsMSVCQt5.15 - Build # 53 - Still Failing!
> To: 
>
>
> *BUILD FAILURE*
> Build URL
> https://build.kde.org/job/Administration/job/Dependency%20Build%20Extragear%20stable-kf5-qt5%20WindowsMSVCQt5.15/53/
> Project: Dependency Build Extragear stable-kf5-qt5 WindowsMSVCQt5.15
> Date of build: Wed, 07 Jul 2021 18:00:04 +
> Build duration: 2 hr 46 min and counting
> * CONSOLE OUTPUT *
> [...truncated 53095 lines...]
> [2021-07-07T20:42:36.730Z] [84/533] Building CXX object
> src\CMakeFiles\KF5KDELibs4Support.dir\kdecore\kcurrencycode.cpp.obj
> [2021-07-07T20:42:36.730Z]
> C:\Craft\CI-Qt515\windows-msvc2019_64-cl-debug\include\qt5\QtCore/qsystemdetection.h(189):
> warning C4005: 'Q_OS_WIN': macro redefinition
> [2021-07-07T20:42:36.730Z] ..\src\kdecore\kcurrencycode.cpp: note: see
> previous definition of 'Q_OS_WIN'
> [2021-07-07T20:42:37.710Z] [85/533] Building CXX object
> src\CMakeFiles\KF5KDELibs4Support.dir\kdecore\kdebugdbusiface.cpp.obj
> [2021-07-07T20:42:37.710Z]
> C:\Craft\CI-Qt515\windows-msvc2019_64-cl-debug\include\qt5\QtCore/qsystemdetection.h(189):
> warning C4005: 'Q_OS_WIN': macro redefinition
> [2021-07-07T20:42:37.710Z] ..\src\kdecore\kdebugdbusiface.cpp: note: see
> previous definition of 'Q_OS_WIN'
> [2021-07-07T20:42:37.974Z] [86/533] Building CXX object
> src\CMakeFiles\KF5KDELibs4Support.dir\kdecore\kdebug.cpp.obj
> [2021-07-07T20:42:37.974Z]
> C:\Craft\CI-Qt515\windows-msvc2019_64-cl-debug\include\qt5\QtCore/qsystemdetection.h(189):
> warning C4005: 'Q_OS_WIN': macro redefinition
> [2021-07-07T20:42:37.974Z] ..\src\kdecore\kdebug.cpp: note: see previous
> definition of 'Q_OS_WIN'
> [2021-07-07T20:42:39.393Z] [87/533] Building CXX object
> src\CMakeFiles\KF5KDELibs4Support.dir\kdecore\klibrary.cpp.obj
> [2021-07-07T20:42:39.393Z]
> C:\Craft\CI-Qt515\windows-msvc2019_64-cl-debug\include\qt5\QtCore/qsystemdetection.h(189):
> warning C4005: 'Q_OS_WIN': macro redefinition
> [2021-07-07T20:42:39.394Z] ..\src\kdecore\klibrary.cpp: note: see previous
> definition of 'Q_OS_WIN'
> [2021-07-07T20:42:39.394Z] [88/533] Building CXX object
> src\CMakeFiles\KF5KDELibs4Support.dir\kdecore\k4aboutdata.cpp.obj
> [2021-07-07T20:42:39.394Z]
> C:\Craft\CI-Qt515\windows-msvc2019_64-cl-debug\include\qt5\QtCore/qsystemdetection.h(189):
> warning C4005: 'Q_OS_WIN': macro redefinition
> [2021-07-07T20:42:39.394Z] ..\src\kdecore\k4aboutdata.cpp: note: see
> previous definition of 'Q_OS_WIN'
> [2021-07-07T20:42:39.394Z] KDE5 FIXME: This code must be replaced by
> something with KLocalizedString
> [2021-07-07T20:42:39.394Z] KDE5 TODO: What about this code ?
> [2021-07-07T20:42:40.178Z] [89/533] Building CXX object
> src\CMakeFiles\KF5KDELibs4Support.dir\kdecore\kkernel_win.cpp.obj
> [2021-07-07T20:42:40.178Z]
> C:\Craft\CI-Qt515\windows-msvc2019_64-cl-debug\include\qt5\QtCore/qsystemdetection.h(189):
> warning C4005: 'Q_OS_WIN': macro redefinition
> [2021-07-07T20:42:40.178Z] ..\src\kdecore\kkernel_win.cpp: note: see
> previous definition of 'Q_OS_WIN'
> [2021-07-07T20:42:40.459Z] [90/533] Building CXX object
> src\CMakeFiles\KF5KDELibs4Support.dir\kdecore\ktemporaryfile.cpp.obj
> [2021-07-07T20:42:40.459Z]
> C:\Craft\CI-Qt515\windows-msvc2019_64-cl-debug\include\qt5\QtCore/qsystemdetection.h(189):
> warning C4005: 'Q_OS_WIN': macro redefinition
> [2021-07-07T20:42:40.459Z] ..\src\kdecore\ktemporaryfile.cpp: note: see
> previous definition of 'Q_OS_WIN'
> [2021-07-07T20:42:41.888Z] [91/533] Building CXX object
> src\CMakeFiles\KF5KDELibs4Support.dir\KF5KDELibs4Support_autogen\mocs_compilation.cpp.obj
> [2021-07-07T20:42:41.888Z]
> C:\Craft\CI-Qt515\windows-msvc2019_64-cl-debug\include\qt5\QtCore/qsystemdetection.h(189):
> warning C4005: 'Q_OS_WIN': macro redefinition
> [2021-07-07T20:42:41.888Z]
> src\KF5KDELibs4Support_autogen\mocs_compilation.cpp: note: see previous
> definition of 'Q_OS_WIN'
> [2021-07-07T20:42:41.888Z] Port to Qt5 native filter
> 

Re: AudioTube in KDEReview

[Harald Sitter]

On 16.06.21 21:27, Jonah Brüchert wrote:
>> - something is also wonky with the playlist. it doesn't cover the width
>> (when data fails to load). it is overlapped by the scrollbar. clear and
>> shuffle don't seem to have labels though there would be enough space
>> https://i.imgur.com/Q3IoaBj.png
> The left side should display the album cover, do you think the playlist
> should fill the whole page if there is none?

That would be an option. Alternatively what might make sense is show a
placeholdermessage [1] instead of the album cover and/or possibly an
icon as generic placeholder artwork. Not sure which makes more sense.
With a placeholder it'd certainly be more consistent from a visual POV.

https://api.kde.org/frameworks/kirigami/html/classorg_1_1kde_1_1kirigami_1_1PlaceholderMessage.html

>> - on some artists I get `TypeError: 'NoneType' object is not iterable `
>> https://i.imgur.com/U8BKHbQ.png
> Which exactly? I can't reproduce it with Daft Punk.

Ah sorry. It was the Thomas Bangalter entry. Curiously the search is
different today ^^. If you search for 'Bangalter' it happens with the
artist entry still.

HS

Re: AudioTube in KDEReview

[Harald Sitter]

Hola

On 16.06.21 00:44, Jonah Brüchert wrote:
> I would like to move AudioTube to KDEReview.

- the source is almost reuse compliant but not quite. needs some extra
data files equipped with CC-0 or the like [1][2]. You could then also
add an include on
https://invent.kde.org/sysadmin/ci-tooling/raw/master/invent/ci-reuse.yml
to your gitlab-ci.yml to ensure it stays at complete coverage

- l10n is not correctly set up. You need to set a translation domain on
the KLocalizedContext

- app crashes when ytmusicapi isn't installed ;) maybe add a
find_package that simply tries to run a simple script importing it? tag
the package RUNTIME. that way the runtime dep is properly codified

- same for youtube_dl which seems to be required behind the scenes

- app isn't kcrash enabled :((

- seeking doesn't seem to do anything. I get `audiotube(103398)/(qml)
onMoved: Value: 71454.30987821381` as output but then the seek doesn't
actually happen

- something is also wonky with the playlist. it doesn't cover the width
(when data fails to load). it is overlapped by the scrollbar. clear and
shuffle don't seem to have labels though there would be enough space
https://i.imgur.com/Q3IoaBj.png

- on some artists I get `TypeError: 'NoneType' object is not iterable `
https://i.imgur.com/U8BKHbQ.png

- on the subject of errors. I'm not sure the passive popup overlapping
the controls at the bottom is all that nice

- appdata should probably describe the 

- ytmusic.cpp forces LC_ALL to en_us, that seems a bit fishy and it
doesn't explain why either

- VideoInfoExtractor ctor should be explicit

- PlaylistUtils looks like it maybe should be a namespace not a class.
feel free to ignore me if you disagree

- in asyncytmusic.h there's a typo in 'ininitalized'

- ~YTMusicThread be tagged `override`

- example has a type in 'excaustive'

- you may want to do a pass over all strings. I'm seeing some action
strings not using title capitalization (e.g. i18n("Add to playlist")
i18n("Play next")) [3]

[1] https://apachelog.wordpress.com/2021/04/06/reuse-licensing-helper/
[2]
https://community.kde.org/Guidelines_and_HOWTOs/Licensing#License_Statements_in_Non-Source-Code_Files
[3] https://develop.kde.org/hig/style/writing/capitalization/

Re: New repo in kdereview: kasts

[Harald Sitter]

On Sat, May 29, 2021 at 10:20 PM Bart De Vries  wrote:
>
> On 27/05/2021 15:09, Harald Sitter wrote:
> > - the source is almost reuse compliant but not quite. needs some extra
> > data files equipped with CC-0 or the like [1][2]. You could then also
> > add an include on
> > https://invent.kde.org/sysadmin/ci-tooling/raw/master/invent/ci-reuse.yml
> > to your gitlab-ci.yml to ensure it stays at complete coverage
>
> We've made all source files reuse compliant with one exception: the dbus
> interface files.  We couldn't figure out which license to apply.
> Any pointers are welcome.

org.freedesktop.PowerManagement.Inhibit.xml can be simply CC0 with no
copyright holder. It's essentially auto-generated introspection data.
example at [1]

org.gnome.SessionManager.xml is a bit more complicated because it
contains exhaustive documentation that could possibly be considered
copyrightable.
I'm guessing it was excavated from gnome-session [2]? If so it's
probably GPL-2+ with gnome as copyright holder, **but** it may make
sense to send a mail to the maintainers to clarify the situation. You
could also replace this file with a rewrite: You really only need a
super trivial definition like
org.freedesktop.PowerManagement.Inhibit.xml, modeling merely the
Inhibit and Uninhibit methods. Neither the documentation nor the other
methods actually serve any purpose here anyway.

[1] 
https://community.kde.org/Guidelines_and_HOWTOs/Licensing#License_Statements_in_Non-Source-Code_Files
[2] 
https://gitlab.gnome.org/GNOME/gnome-session/-/blob/master/gnome-session/org.gnome.SessionManager.xml

> > - AudioManager deals a lot with time numbers. it'd aid readability
> > (and probably type safety) if you used std::chrono type and in
> > particular also chrono literals
>
> I'll have to have a closer look at this.  AudioManager is a wrapper
> around QMediaPlayer which is using qint64 for durations and positions.
> As such, the current implementation avoids type conversions by using
> qint64 everywhere for time numbers.
> While I agree that std::chrono might be a more logical choice here, I'm
> afraid it would also introduce a lot more type conversions to the
> underlying QMediaPlayer.

Fair point. I thought there's only the two setters where you interact
with QMP but since you also pass through signals from QMP it gets a
bit more complicated. I would still convert the types to get the
advantages of chrono but I fully understand that this isn't nearly as
neat as I had thought originally. Entirely up to you.

I now noticed your hack in AudioManagerPrivate::prepareAudioStream
though. I would strongly urge you to find another way of dealing with
this. Nested event loops (QEventLoop::exec) have shown to be fairly
crashy in the past, double so for QML application. If any event fires
(e.g. through a timer) that deletes an object or otherwise mutates
expected states out from under the current stack the application will
crash. QEventLoop::exec is really an anti-pattern most of the time
IMO.

HS

Re: New repo in kdereview: kasts

[Harald Sitter]

On Thu, May 27, 2021 at 12:20 PM Bart De Vries  wrote:
>
> Hello everyone!
>
> I would like to move kasts to kdereview.
>
> https://invent.kde.org/plasma-mobile/kasts  
> 
>
> Kasts is a podcast app for Plasma Mobile. It was started as a fork of 
> Alligator, the Plasma Mobile feed reader. It currently features a play queue, 
> play position resume/persistence, MPRIS2 support, and suspend inhibition.

Hey.
It's amazing. Also in incredible shape, well done!

Some stuff I've noticed:

- the source is almost reuse compliant but not quite. needs some extra
data files equipped with CC-0 or the like [1][2]. You could then also
add an include on
https://invent.kde.org/sysadmin/ci-tooling/raw/master/invent/ci-reuse.yml
to your gitlab-ci.yml to ensure it stays at complete coverage

- your appdata file has no screenshots defined

- since you require qt 5.15 you can use Qt::Core etc. targets instead
of Qt5::Core. this will make porting to qt6 less work

- the page stack between Settings and About is a bit wonky. they both
push onto layer stack rather the regular stack (I guess?) which seems
not exactly ideal considering from the way these two are presented in
the UI they should behave same as Queue and Episodes etc..
particularly problematic is however that if you switch between
settings and about you keep growing the page stack and the only way to
get back to the "real page" is to manually unwind the stack again

- also on the subject of the navigation pane: I believe the current
page ought to be highlighted in the navigation pane. when I'm drilled
down into a subpage of e.g. the Episodes page I wouldn't know that
this is where I came from other than through unwinding the stack
manually again

- something is wonky with the colors on desktop. in all listviews it
looks like the delegates are inactive/disabled colors for some reason.
e.g. https://i.imgur.com/xkgigs4.png

- I'm not super certain but also on that same page you might need to
turn the entire "by %1" sequence into a translatable string rather
than just "by". I don't think you can presume that every language has
that particular order? you might want to ask on the kde-i18n-doc
mailing list.

- the generic entry delegate hardcodes size formatting, this results
in my system usually talking about MiB everywhere but kasts is talking
about MB (yet indeed it still means MiB). You'll want to use kformat
[3]

- you may want to do a pass over all strings. I'm seeing some action
strings not using title capitalization (e.g. the actions in
GenericEntryDelegate.qml  - "Add to queue") [4]

- I see you are hardcoding a color in GenericHeader.qml, I'm not super
sure that will work correctly across different themes but then I also
don't really see the color actively used :shrug:

- there is a `// TODO: implement` in the main.qml. you might want to do that ;)

- AudioManager::timeString probably can be replaced by KFormat::formatDuration

- AudioManager has lots of commented out qdebugs. I suggest to either
remove them, or turn them into qCDebugs (so they may be
enabled/disabled at runtime)

- AudioManager deals a lot with time numbers. it'd aid readability
(and probably type safety) if you used std::chrono type and in
particular also chrono literals

- AudioManager uses some "old style" stringy connects
`loop.connect(, SIGNAL(timeout()), , SLOT(quit()));` these
SIGNAL() and SLOT() bits are only evaluated at runtime. To have the
compiler ensure the functions are valid I would very strongly suggest
to change them to function pointers like in the other connect calls.

- AudioManager also has some singleShot(0, lambda) calls. I believe
these are kind of unsafe since `this` might get deleted between the
call and the execution. you'll want to contextualize them
`singleShot(0, this, lambda)`

- QueueModel has an m_audio member that isn't ever set or used from
what I can tell

[1] https://apachelog.wordpress.com/2021/04/06/reuse-licensing-helper/
[2] 
https://community.kde.org/Guidelines_and_HOWTOs/Licensing#License_Statements_in_Non-Source-Code_Files
[3] 
https://invent.kde.org/plasma/plasma-nm/-/blob/9005f2580c37d5dbf32f1d264eb87d73ca723829/applet/contents/ui/ConnectionItem.qml#L258
[4] https://develop.kde.org/hig/style/writing/capitalization/

HS

Re: Qt5PatchCollection versions (broken QWE)

[Harald Sitter]

On Wed, May 26, 2021 at 7:39 PM Antonio Rojas  wrote:
>
> El miércoles, 26 de mayo de 2021 13:19:34 (CEST), Harald Sitter escribió:
> > Hola
> >
> > QWE and QtScript in our kde/5.15 branches currently have unaligned versions.
> >
> > QWE 5.15.4:
> > https://invent.kde.org/qt/qt/qtwebengine/-/blob/kde/5.15/.qmake.conf
> >
> > QtBase 5.15.3:
> > https://invent.kde.org/qt/qt/qtbase/-/blob/kde/5.15/.qmake.conf
> >
> > This then breaks version alignment expectations. For example QWECore
> > requires QtWebChannel at the same version but since the versions are
> > misaligned the requirement check changes.
>
> This is because the upstream QWE and QtScripts 5.15 branches are public,
> unlike the other Qt repos. The versioning issue is discussed here:
>
> https://www.qt.io/blog/building-qt-webengine-against-other-qt-versions
>
> Lowering the version number would be misleading since this is the real,
> upstream 5.15 code, which is post-5.15.4 already.

I suppose then we need to fix the cmake check?

Right now building the lot of our patch collection branches leads to
skrooge not being able to build because of that defect. That seems
silly at the best of times.

HS

Qt5PatchCollection versions (broken QWE)

[Harald Sitter]

Hola

QWE and QtScript in our kde/5.15 branches currently have unaligned versions.

QWE 5.15.4:
https://invent.kde.org/qt/qt/qtwebengine/-/blob/kde/5.15/.qmake.conf

QtBase 5.15.3:
https://invent.kde.org/qt/qt/qtbase/-/blob/kde/5.15/.qmake.conf

This then breaks version alignment expectations. For example QWECore
requires QtWebChannel at the same version but since the versions are
misaligned the requirement check changes.

CMake Error at 
/usr/lib/x86_64-linux-gnu/cmake/Qt5WebEngineCore/Qt5WebEngineCoreConfig.cmake:111
(find_package):
  Could not find a configuration file for package "Qt5WebChannel" that is
  compatible with requested version "5.15.4".
  The following configuration files were considered but not accepted:
/usr/lib/x86_64-linux-gnu/cmake/Qt5WebChannel/Qt5WebChannelConfig.cmake,
version: 5.15.3

I would think that we should simply align the versions at whatever
version seems appropriate. To that end I would propose that we lower
the versions of QWE and QtScript to .3.

Thoughts? Should I start an MR?

(Also, kinda unrelated but I couldn't find a good venue to discuss
things with all curators as gitlab issues are disabled for everything
but the backport tracker :-( similarly I'm not sure where one would
file a regression bug report if there were one - might need sorting
out TBH)

HS

Re: Any interest in a batch file renamer in KIO?

[Harald Sitter]

On Mon, May 17, 2021 at 12:38 PM Nomen Luni  wrote:
>
> Hi,
>
> I actually looked at KRename some time back and it wasn't quite what I
> wanted. It does actually appear as a service menu option when installed,
> so it has that base covered, however for my needs it's felt a little
> unwieldy. My application, whilst no doubt a little less capable feels
> smaller and more streamlined to operate and dare I say more at a level
> consistent with the Dolphin ethos in terms of the simplicity of the GUI
> - I realise this is subjective. If anyone has used the Thunar 'bulk
> rename' plugin, mine is heavily influenced by the interface of that (but
> implemented in Qt which was one of the prime reasons for its
> creation)... so it wasn't a case of 'new code is more fun,' so much as
> 'this is exactly what I want.'
>
> Since KRename already operates as a Dolphin plugin it shouldn't be too
> much work to integrate it directly into Dolphin, or perhaps even just
> ship it as a default plugin, however that isn't something I'm interested
> in working on as I don't use it... benevolent self interest and all that.
>
> Dolphin could really benefit from a batch rename function in my opinion,
> what form that functionality should take, pre-existing or new, is a
> worthwhile conversation. In any case, Harald's point regarding
> discoverability is a valid one, as I'm sure a large proportion of users
> never take the time to investigate the service menu plugins.

My point was more that all the "backendy" bits already exist in
krename, the discoverability it lends is just bonus. And while I
completely agree that the current UI is very... eh, advanced... you
could simply stick another simplistic UI on top, or rework the default
appearance of krename so it is simpler by default and powerful when
needed. The way I see it krename could definitely become more
appealing to potential users by being simpler, and at the same time if
you invest UI engineering into krename you don't have to worry about
any of the logic behind renaming in of itself since that already
exists and is QA'd.

HS

Re: Any interest in a batch file renamer in KIO?

[Harald Sitter]

Yo

On Sat, May 15, 2021 at 4:53 PM Nomen Luni  wrote:
>
> Hi Folks,
>
> First time poster. I've recently developed a batch file renaming utility
> which operates as a service menu plugin within Dolphin. If anyone has
> seen the 'bulk rename' plugin for Thunar, this is highly inspired by
> that app in terms of functionality but is a from-scratch implementation
> using the Qt stack.
>
> I'm writing to gauge if there's any interest for inclusion in Plasma and
> speaking with Nate Graham he said KIO might be the place for it to live
> and directed me here.
>
> So basically, is there any interest and if so, could someone give me
> some guidance on how to integrate/get it reviewed and added?
>
> The code is on Github. Currently it's compiling through Qt Creator:
>
> https://github.com/Nomen-Luni/Bionic-Batch-Renamer
> 

Neat!
Have you considered contributing to https://apps.kde.org/krename/

I know new code is more fun but krename is already incredibly powerful :)

HS

Re: Koko in KDEReview

[Harald Sitter]

On 04.05.21 17:53, Carl Schwan wrote:
> Le mardi, mai 4, 2021 4:53 PM, Adriaan de Groot  a écrit :
> 
>> On Tuesday, 4 May 2021 15:50:27 CEST Halla Rempt wrote:
>>
>>> On Tuesday, 4 May 2021 15:28:30 CEST Nate Graham wrote:
>>>
 I don't see anyone really trying to argue otherwise.
>>>
>>> I have certainly made that argument many times. Since only developers can
>>> add tags, it will be impossible for ordinary users to provide enough
>>> information to classify the bug. Tagging systems suck big-time. Looking it
>>> GIMP's gitlab issues shows that not even the OS is reliably tagged!
>>
>> What Halla said. Every time we have this conversation, Krita is the special
>> case, because it is a special case -- many many users, diverse platforms,
>> non-technical bug-reports. We must not discount Krita's experiences and needs
>> -- conversely not ignore the needs of some obscure edge-case tool that is 
>> only
>> going to get FreeBSD sysadmins to file bug reports (which might be fine in
>> GitLab issues, because there's only ever 3 users).
> 
> If Bugzilla was working so well for Krita, I'm wondering why they are 
> redirecting
> their users to write their bug reports first in an external tool 
> (krita-artists.org)
> instead of Bugzilla.

Passive aggression really doesn't move the debate forward :(

> Some documentation website aren't using docs.kde.org but their own tooling
> (e.g. docs.krita.org, docs.plasma-mobile.org, ...), should we also force them
> to use docs.kde.org? Should we force every project to use forum.kde.org?

... neither do straw men.

> Any migration has to be able to handle huge numbers of issues, and also
>> provide maintainers tools to manage them, and to handle the diversity of 
>> issue
>> meta-data that bugzilla handles.
>>
>> To move this conversation forward, we'd need a concrete example of "these are
>> the tools used to manage issue lifecycle, similar to how bugs lifecycle in
>> bugzilla works". I know Harald has built tools and views and things to help
>> out there, but we do need a .. well, a concrete proposal for how things would
>> work.
> 
> Currently, the extra tooling we maintain for closing bugs and adding comments 
> in Bugzilla
> when an MR is opened is currently natively supported by GitLab. For bug 
> triagging,
> there is also a very helpful tool made by GitLab: 
> https://gitlab.com/gitlab-org/gitlab-triage
> 
> This tool allows for example to add special labels when an issue/MR, older 
> than a
> few days, didn't get any comments yet or adding automatically OS labels when
> Windows/Arch/FreeBSD is mentioned in the issue.

Yep. I think to drive the point home: We have solved a great many things
with tooling, we may be able to get rid of some, we may need to add some
more, but we first need to know what the great many things (not just
tooling I guess) are that we do and rely on. Only then can we actually
a) go "yes, let's move" b) "here's the migration plan". Gitlab
insufficiencies may well be solved by some extra magic put on top.

So, I suggest that someone who cares to migrate sits down with the major
stake holders and figures out what we have come to rely on in bugz that
isn't available in gitlab (OS, versions, version supportedness, personal
tags, moving bugs between projects, global search etc.), and also what
gitlab does better or might improve. Write all the stuff down on a wiki
page. Then we can think about how to deal with the various problems. And
maybe in the end the answer is not everyone can have the same BTS.
Martin has raised a really good point there. But we really, really,
really do not want a 50/50 split and everyone picks the system that
takes their fancy and then we need twice the
tooling/solutions/clientsoftware AND on top of everything figure out how
to bounce bugs between two systems. It'd not be sustainable.

> Also, it's important to note that different teams have different needs and 
> finding
> a tool that fits everyone will be very difficult. For example in NeoChat, I 
> have
> special needs like asking the bug reporter to add some information about the
> matrix instance used, the libQuotient version used, ... and for that, I need a
> special bug reports template. Something that Bugzilla doesn't provide and 
> without
> it, the bugs report are in many cases worthless.

Side note: this isn't a special need TBH ;)
Pretty much everyone has that need. So much so that I kind of have a
general game plan that there ought to be a kbugreport utility which is
able to gobble up all the very specific data $product needs through
scripts or something and either attaches the data to an existing report
or files a new one. Cause a filing template also only gets you so far  +
for the causal user it's still a fairly meh experience.

HS

Re: Koko in KDEReview

[Harald Sitter]

On 04.05.21 15:28, Nate Graham wrote:
> On 5/4/21 1:16 AM, Harald Sitter wrote:
>> Every time the bugz vs gitlab schism comes up I eventually tune out with
>> the distinct feeling that there is strong opposition to moving. What I,
>> what we all, do not want is to end up with two systems that require us
>> to maintain two client libraries with double the bugs for the next 10
>> years, and everyone gets to roll a dice which platform a given product
>> tracks bugs on. So what we need is community agreement which BTS to use
>> long term and then we can drive the technical changes to make that
>> happen.
>>
>> Short to mid term bugz is the reality we have to live with.
> 
> There is policy, and there is reality. Policy is not self-enforcing, and
> if it attempts to prescribe a reality too different from the actual one,
> it breaks and looks somewhat silly.
> 
> Since we have no way of actually *disabling* the Issues feature in our
> GitLab instance, certain projects are inevitably going to start using it
> despite all the policy we can come up with. Why? Because it's generally
> better for most of the things that most of us care about (it does not
> have to better for literally everything to still be a net win) . I don't
> see anyone really trying to argue otherwise.
> 
> Therefore, I think we need to re-focus the conversation towards "how do
> we migrate to GitLab issues in a coordinated and supported manner."

Sure, I suppose, I mean, not this conservation, this conversation was
about koko and how it needs crash tracking because quite clearly there's
opportunity for crashing. The reality right here right now is that
drkonqi only sports bugz support and will not gain gitlab support until
at least October. Which is why I said that this is the reality we live
in short to mid term.

HS



OpenPGP_signature
Description: OpenPGP digital signature

Re: Koko in KDEReview

[Harald Sitter]

On 04.05.21 00:07, Carl Schwan wrote:
> Le lundi, mai 3, 2021 4:35 PM, Harald Sitter  a écrit :
> 
>> On 23.04.21 01:00, Carl Schwan wrote:
>>
> 
>>>>>>> -   please get a bugzilla produce created for it
>>>>>
> 
>>>>> Not a fan of that. This will ends up exactly like the www bugs, something
>>>>> that I look into every 6 months. We already have many issues opened in
>>>>> invent and it's working fine for us.
>>>>
> 
>>>> Did I miss something? The last agreement I recall was that we are using
>>>> bugzilla for bugs and gitlab for tasks for the time being. If even as
>>>> developer I have to go hunting where $project tracks their bugs I'm sure
>>>> not going to be a happy camper.
>>>>
> 
>>>>> Also we don't use KCrash.
>>>>
> 
>>>> Shouldn't you?
>>>
> 
>>> The problem is that DrKonqi doesn't really work on Plasma Mobile and I 
>>> don't think
>>> this justify getting locked up in using Bugzilla. If having a bugzilla 
>>> product
>>> is really required, we can request one but I can't guarantee that I will 
>>> look at it
>>> more often than I look at the kde-www bug reports in bugzilla (every 6 
>>> months).
>>
> 
>> Let's consider it required then.
>>
> 
>> If you don't care about crash reports that's your choice I guess, but it
>> does kinda call into question the product quality since you also don't
>> have an alternative system to the kcrash-drkonqi-bugzilla caravan. Quite
>> clearly koko would have benefited from crash tracking and since the only
>> solution we presently have for that is the aforementioned stack it quite
>> clearly also would have benefited from being on bugzilla to receive
>> those crash reports and potentially move to other products if the crash
>> is not in koko. After all, crashes get submitted to the product that
>> crashed, not the library of the top most frame.
>>
> 
>> I have to be honest, it is a bit surreal to even have to argue this. I
>> get thorough enjoyment out of throwing tomatoes at the current system
>> but to actively pretend that the problem-domain of crashing software
>> doesn't exist so you don't have to look at bugzilla sure as heck doesn't
>> solve anything. In particular since you pitched koko as convergent and
>> useful on the desktop.
>>
> 
>> If all that's stopping you from embracing crash tracking is drkonqi then
>> I am happy to tell you that sticking a mobile-suitable UI on top
>> shouldn't be all that difficult ;)
> 
> Would you be open to an MR adding GitLab support to DrKonqi?

Once there's actually agreement on moving to gitlab. The code is not the
problem here. Code is easy. We are hackers after all.

Every time the bugz vs gitlab schism comes up I eventually tune out with
the distinct feeling that there is strong opposition to moving. What I,
what we all, do not want is to end up with two systems that require us
to maintain two client libraries with double the bugs for the next 10
years, and everyone gets to roll a dice which platform a given product
tracks bugs on. So what we need is community agreement which BTS to use
long term and then we can drive the technical changes to make that happen.

Short to mid term bugz is the reality we have to live with.

HS



OpenPGP_signature
Description: OpenPGP digital signature

Re: Koko in KDEReview

[Harald Sitter]

On 23.04.21 01:00, Carl Schwan wrote:
> -   please get a bugzilla produce created for it
>>>
>>> Not a fan of that. This will ends up exactly like the www bugs, something
>>> that I look into every 6 months. We already have many issues opened in
>>> invent and it's working fine for us.
>>
>> Did I miss something? The last agreement I recall was that we are using
>> bugzilla for bugs and gitlab for tasks for the time being. If even as
>> developer I have to go hunting where $project tracks their bugs I'm sure
>> not going to be a happy camper.
>>
>>> Also we don't use KCrash.
>>
>> Shouldn't you?
> 
> The problem is that DrKonqi doesn't really work on Plasma Mobile and I don't 
> think
> this justify getting locked up in using Bugzilla. If having a bugzilla product
> is really required, we can request one but I can't guarantee that I will look 
> at it
> more often than I look at the kde-www bug reports in bugzilla (every 6 
> months).

Let's consider it required then.

If you don't care about crash reports that's your choice I guess, but it
does kinda call into question the product quality since you also don't
have an alternative system to the kcrash-drkonqi-bugzilla caravan. Quite
clearly koko would have benefited from crash tracking and since the only
solution we presently have for that is the aforementioned stack it quite
clearly also would have benefited from being on bugzilla to receive
those crash reports and potentially move to other products if the crash
is not in koko. After all, crashes get submitted to the product that
crashed, not the library of the top most frame.

I have to be honest, it is a bit surreal to even have to argue this. I
get thorough enjoyment out of throwing tomatoes at the current system
but to actively pretend that the problem-domain of crashing software
doesn't exist so you don't have to look at bugzilla sure as heck doesn't
solve anything. In particular since you pitched koko as convergent and
useful on the desktop.

If all that's stopping you from embracing crash tracking is drkonqi then
I am happy to tell you that sticking a mobile-suitable UI on top
shouldn't be all that difficult ;)

HS



OpenPGP_signature
Description: OpenPGP digital signature