Re: Glaxnimate KDE Review

[Adriaan de Groot]

On Wednesday, 1 May 2024 14:43:55 CEST Mattia Basaglia wrote:
> Review checklist:
> https://invent.kde.org/graphics/glaxnimate/-/issues/666

Hi Mattia,

Slightly out-of-scope of the regular review checklist, I'm building glaxnimate 
on FreeBSD with KF5. The use of submodules and bundled libraries is a bit 
unusual. I didn't expect submodules, and a plain "cmake" without them got me a 
weird message about a missing misc/ directory.

Anyway, *with* submodules, FreeBSD, Clang 17, it builds with remarkably few 
warnings; one in Qt-Color-Widgets, and a couple of cast warnings in image 
wrangling. Casting pointers to uchar to something else is always fraught.

Man, that splash screen is something. Suffice to say: it builds and runs 
somewhere where you possibly didn't expect it.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Post-MegaRelease projects

[Adriaan de Groot]

On Friday, 23 February 2024 03:27:00 CET Jin Liu wrote:
> Another thing I'd like to explore is to have some universal way to
> programmatically change KDE settings.

This is a thing that I'd really like to have -- but probably cannot contribute 
to -- also for Calamares (a Linux distro installer). It runs the plasmalnf 
tool (if configured to set up KDE Plasma) but that's something of a hack. I 
also get regular feature requests "configure  in Plasma" which I can't 
do, since the configuration is opaque to me.

[ade]

Re: KDE Review: Skladnik (t.g.f.k.a. KSokoban), returning a KDE1-KDE3 age dino

[Adriaan de Groot]

On Sunday, 12 November 2023 22:57:55 CET Friedrich W. H. Kossebau wrote:
> Would the file COPYING (GPLv2) in the toplevel dir then default the license
> for these files?
> See https://phabricator.kde.org/source/svn/browse/trunk/kdegames/;10132
> In short, what to do here for reuse checks? Ignore, because old repo and
> thus legacy rights? Can files be skipped in the check?

There are similar what-could-it-have-been questions around some of the kpat 
card decks -- later moved into kdegames. There was a short thread about that a 
month or two ago, although i forget where.

Since these are "source" you could well consider them to fall under the source 
license of the program. You could try chasing down Anders if you want to 
double-check.

You can always add an entry in the .dep5 file describing these povray sources 
as "best effort" documentation of the license, and then SPDX tag them GPLv2.

[ade]


signature.asc
Description: This is a digitally signed message part.

Re: drkonqi's many debuggers

[Adriaan de Groot]

On Monday, 28 August 2023 17:23:00 CEST Harald Sitter wrote:
> 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).

(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).

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Review request for MpvQt

[Adriaan de Groot]

On Friday, 25 August 2023 21:56:45 CEST Florea Banus George wrote:
> please review https://invent.kde.org/libraries/mpvqt, a libmpv wrapper
> library for qtquick/qml (no widgets).

Builds, and the example runs and can play a .webm file, on FreeBSD. There's a 
handful of warnings which I'll add to the review request.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Move Licentia to KDEREVIEW

[Adriaan de Groot]

On Friday, 8 July 2022 07:36:57 CEST Felipe Kinoshita wrote:
> Hey, I'd like to move Licentia  to
> KDEREVIEW.
> 
> Licentia is a simple app targeted at developers/creators who need to decide
> which license is suited to their projects, Licentia helps with that by
> listing a bunch of licenses, which with it's permissions, conditions and
> limitations, instructions about how to add a license to your project and a
> list of known projects that use said license.

Where are you getting the data describing each license? In particular, the 
tags / metadata for them. There are plenty of online license-choice-helpers, 
although those generally have an agenda (e.g. GitHub's license chooser) and 
lots of ontologies for license description (e.g. one I made up in 2009 but 
lost the icons for).

Asking for information, not for a hidden "why bother" agenda.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: QFileSystemWatcher fails with sockets on FreeBSD

[Adriaan de Groot]

On Tuesday, 3 May 2022 12:27:22 CEST David Faure wrote:
> But on FreeBSD, it looks like QFileSystemWatcher doesn't support sockets, it
> tries to open them as a file?

I'm fairly sure we have other tests, much lower in the stack -- some Tier-1 
Framework -- that has the same kind of issues and that we  either XFAIL or 
#ifdef out. I wouldn't know where, though.

[ade]


signature.asc
Description: This is a digitally signed message part.

Re: RKWard is in kdereview - again

[Adriaan de Groot]

On Monday, 28 March 2022 17:39:17 CEST Thomas Friedrichsmeier wrote:
> On Mon, 28 Mar 2022 17:09:44 +0200
> Nicolas Fella  wrote:
> [...]
> 
> > Talking about FreeBSD: I started adding Gitlab CI and the FreeBSD
> > build fails: https://invent.kde.org/education/rkward/-/jobs/274861,
> > presumably due to having a different tar implementation than Linux.
> 
> Sweet!
> 
> > I'd appreciate if someone could comment/look into that
> 
> Ouch, that issue, again. The option can safely be stripped, but was
> added to make builds reproducible (
> https://invent.kde.org/education/rkward/-/merge_requests/6). I've
> limited that to "Linux" systems, now.

Relevant bits are a bug report asking for the same in ECM:

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

The corresponding MR:

https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/238

and associated commentary. Stealing from ECM is encouraged :) 

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: RKWard is in kdereview - again

[Adriaan de Groot]

On Saturday, 26 March 2022 21:34:06 CEST Thomas Friedrichsmeier wrote:
> KDE.org has been our home for a 7.5(!) years, now (after over a
> decade on sourceforge), but we still haven't left playground... After a
> lot of procrastination on that matter, a previous review failed due to
> lack of time on my part. Sorry! Now, finally, I'd like to ask you to
> start reviewing RKWard for inclusion into exragear / education, once
> more.
> 
...
> 
> RKWard is used productively on Linux/BSD, Mac, and Windows.

Congratulations! RKWard has been packaged on FreeBSD for a long time already 
(although it's only at version 0.7.1, not the latest release -- cc'ing the 
FreeBSD maintainer there).

On the FreeBSD side there's only two patches in packaging; one missing include 
(not needed with current git) and a CMake thingy that I don't quite understand 
(about gfortran). I do notice that there's a FindR.cmake in Cantor, and one in 
RKWard, and they are somewhat different: perhaps some coordination to make 
them both do the same (and the right) things?

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Unit tests all pass in Jenkins on Linux

[Adriaan de Groot]

On Sunday, 20 March 2022 21:43:58 CET David Faure wrote:
> On dimanche 13 mars 2022 17:53:13 CET Ben Cooksley wrote:
> > On Mon, Mar 14, 2022 at 4:40 AM David Faure  wrote:
> > > After the recent discussions on state of CI, I fixed the last unittest
> > > failures (kio, purpose... + apol fixed ECM) so that
> > > https://build.kde.org/job/Frameworks/view/Platform%20-%20SUSEQt5.15/
> > > is all green^H^Hblue again.
> > > Please keep it that way!
> > 
> > Thanks for looking into and fixing all of these David.
> 
> Now I'd like to fix the remaining unittest failures on FreeBSD.
> 
> I just fixed kcrash by reading the unittest code.
> However for the remaining ones, I need to actually debug on FreeBSD.
> Is there a FreeBSD virtual machine with the full setup already done for
> building KDE Frameworks, that I could either run locally or log into?

I suppose the CI-builders would qualify, but that's probably not a good idea 
in general. I tried to put together a VM image for KDE development back in 
2020: https://euroquis.nl/freebsd/2020/01/11/freebsd.html . An 8GB image is a 
bit much; I might be able to do a frameworks-development one with no graphical 
capability in a lot less space, but don't immediately have a place to host it.

[ade] (argh, yeah, kmail)


signature.asc
Description: This is a digitally signed message part.

Re: Towards Excellent Defect Management

[Adriaan de Groot]

On Friday, 17 September 2021 00:46:33 CEST Aleix Pol wrote:
> On Tue, Sep 14, 2021 at 5:23 PM Harald Sitter  wrote:
> > 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

https://open.sentry.io/licensing/

It's refreshing to read a straightforward take on this. And indeed, BSL 1.1 is 
**not** OSI-approved (I've watched plenty of the internal discussions about it 
and similar licenses) because it falls foul of freedom 0: the freedom to use 
the software for any purpose. That's roughly the same reason the "do no evil" 
license isn't OSI-approved ("but daaad, I *want* to do evil!").

> +1 makes sense to me, it's exciting to find new ways that people can
> help make our software better without a big effort.
> 
> I'd say the purpose of our manifesto clause that we need to rely
> exclusively on FOSS tools wasn't designed for cases like this one.

+1 to that, yes.

[ade] (pragmatically)

signature.asc
Description: This is a digitally signed message part.

Re: Progress is good for us but bad for documentation

[Adriaan de Groot]

On Wednesday, 9 June 2021 01:20:23 CEST Frederik Schwarzer wrote:
> I would like to ask you to report such documentation to me. We see the
> topic come up here and there but it then sometimes sinks into oblivion
> again because it was part of a merge request that has then been merged
> or so.

Here's a little example of docs and code getting mismatched, and layout 
issues. It's just something I spotted because today I'm chasing crash bugs in 
skanlite (the KDE scanner application, for e.g. flatbed scanners). A dependent 
library is libksane, which is sort-of-maybe-a-framework .. I decided to look 
on api.kde.org.

[[ typing this up, btw, takes way more time than just going out and fixing the 
documentation issues I've spotted, but that wouldn't illustrate the kind of 
persistent doc-rot we face; it's also not especially about this one bit of 
software from the KDE community ]]

KSane sources https://invent.kde.org/graphics/libksane
KSane api docs https://api.kde.org/libksane/html/index.html


## README.md

[[ visible on the api docs front page ]]

- dependency information, not one of these matches what's in CMakeLists.txt
- "CMake options" weirdly include the `D` which isn't part of the option name
- where this could be markdown links, it isn't
- formatting of bash command leaks into the documentation page

## KSaneIface

- plenty of typos incl "Read, Grean, Blue" colors
- (rather a personal bugbear) inconsistent start of docs, sometimes right 
after /** and sometimes on the next comment line
- do we have any standard for indicating boolean return values? Seeing 'true' 
and 'false' (with single-tick quotes) as return values (and sometimes without 
the ticks) is .. could be better.



It should be noted the API docs are pretty **good**, and that the docs-rot 
reaches the state of "could be better", not "is terribly wrong"; there's still 
non-zero effort to put into them and I don't know what's a good way to make 
everyone spring into action to polish them up.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Progress is good for us but bad for documentation

[Adriaan de Groot]

On Wednesday, 9 June 2021 01:20:23 CEST Frederik Schwarzer wrote:
> I would like to ask you to report such documentation to me. We see the
> topic come up here and there but it then sometimes sinks into oblivion
> again because it was part of a merge request that has then been merged
> or so.

Here's a little example of docs and code getting mismatched, and layout 
issues. It's just something I spotted because today I'm chasing crash bugs in 
skanlite (the KDE scanner application, for e.g. flatbed scanners). A dependent 
library is libksane, which is sort-of-maybe-a-framework .. I decided to look 
on api.kde.org.

[[ typing this up, btw, takes way more time than just going out and fixing the 
documentation issues I've spotted, but that wouldn't illustrate the kind of 
persistent doc-rot we face; it's also not especially about this one bit of 
software from the KDE community ]]

KSane sources https://invent.kde.org/graphics/libksane
KSane api docs https://api.kde.org/libksane/html/index.html


## README.md

[[ visible on the api docs front page ]]

- dependency information, not one of these matches what's in CMakeLists.txt
- "CMake options" weirdly include the `D` which isn't part of the option name
- where this could be markdown links, it isn't
- formatting of bash command leaks into the documentation page

## KSaneIface

- plenty of typos incl "Read, Grean, Blue" colors
- (rather a personal bugbear) inconsistent start of docs, sometimes right 
after /** and sometimes on the next comment line
- do we have any standard for indicating boolean return values? Seeing 'true' 
and 'false' (with single-tick quotes) as return values (and sometimes without 
the ticks) is .. could be better.



It should be noted the API docs are pretty **good**, and that the docs-rot 
reaches the state of "could be better", not "is terribly wrong"; there's still 
non-zero effort to put into them and I don't know what's a good way to make 
everyone spring into action to polish them up.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Koko in KDEReview

[Adriaan de Groot]

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).

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.

That it's **possible** to manage a gazillion issues in GitLab  (maybe EE 
features, though) can be seen by looking at https://gitlab.com/gitlab-org/
gitlab/-/issues GitLab issues in GitLab: there's 37 thousand of them, but 
there's also 78 pages of labels at https://gitlab.com/gitlab-org/gitlab/-/
labels to pick from. I suspect there's a non-0 amount of FTE's doing bug-
labeling -- can we afford that?

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Kirigami Addons in KDEReview

[Adriaan de Groot]

On Friday, 30 April 2021 23:39:17 CEST Nate Graham wrote:
> I would like to see
> https://invent.kde.org/libraries/kirigami-addons/-/issues/2 fixed first
> as the date picker is sort of almost unusable right now.

A good date picker would be most enthusiastically received by the myGNUHealth 
project, I think.

[ade]

signature.asc
Description: This is a digitally signed message part.

OpenEXR 3.0 Imath library

[Adriaan de Groot]

In FreeBSD ports -- not usually the forefront and bleeding edge of chasing 
software releases, although we track KDE things pretty closely -- OpenEXR has 
been updated to 3.0, which *apparently* splits off a new library called Imath, 
and messes around some other bits.

There's now a patch in our packaging against ECM:

https://cgit.freebsd.org/ports/tree/devel/kf5-extra-cmake-modules/files/patch-find-modules_FindOpenEXR.cmake

that in turn *seems* to do the right thing, al least packages build. The patch 
itself doesn't look all that right to me, though, and suffers from backwards-
incompatibility. So I'm sending a heads-up to -devel and to krita (I hope) 
that there is some rumbling going on around OpenEXR releases and there may 
need to be changes in ECM, kimageformats, krita and kio-extra's -- those 
patches have already landed downstream.

I've asked the downstream patch author to try upstreaming these bits, too.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: KDE CI: Frameworks » ktexteditor » kf5-qt5 FreeBSDQt5.15 - Build # 291 - Unstable!

[Adriaan de Groot]

On Monday, 5 April 2021 19:20:08 CEST Ben Cooksley wrote:
> On Tue, Apr 6, 2021 at 3:33 AM Christoph Cullmann 
> > I reverted my test commit to see if we have still some unpatched 5.15
> > with a broken QJSEngine around again.
> > 
> > Still, I think it would be great if one could have some patched version
> > in the CI.
> > 
> > Could one update there the Qt installation to the latest available patch
> > release?

It would be really useful if you specified **what** version; if ktexteditor 
requires Qt 5.15.2, then please set the minimum Qt version to 5.15.2. Do not 
allow 5.15.0 and then complain that it triggers crashes. Alternately, use 
QEXPECT_FAIL if you have a beef with specific Qt versions.

All that said, yes, we can update the CI builders to 5.15.2, which is what 
most folk on FreeBSD would be using now anyway.

[ade]



signature.asc
Description: This is a digitally signed message part.

Re: Requiring Qt 5.15 for KDE Frameworks 5?

[Adriaan de Groot]

On Saturday, 27 March 2021 14:11:38 CET David Faure wrote:
> While at it, can we also get your feedback on
> * Requiring C++17
> * Requiring CMake >= 3.16
> 
> Obviously this only matters for distributions that update KF5 every month.

FreeBSD is fine with all of that, we track frameworks within a week or two, 
CMake similarly, and ship recent clang (or gcc 10 on platforms that clang 
doesn't support).

[ade]


signature.asc
Description: This is a digitally signed message part.

Re: Koko in KDEReview

[Adriaan de Groot]

On Tuesday, 16 March 2021 20:10:46 CET Carl Schwan wrote:
> > > -   on the topic of licensing: 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
> 
> This will be a bit tricky since the remaining files were not written by any
> current contributors. I could try to contact the old contributors.

You don't need to contact them, you need to know what the license on the file 
is, and who contributed to it. Presumably you know the license (that was made 
clear to all contributors early in the lifetime of the project, I should hope) 
and git log will tell you who that was. Then you need one line

SPDX-License-Identifier:

for the file, and per contributor

SPDX-FileCopyrightText: Person Name 

(On that last one, some folk insist on "(C)" or "Copyright" after the :, and 
perhaps a year as well; the jury is still out on that).

[ade]


signature.asc
Description: This is a digitally signed message part.

Re: RFC: suffix ".in" instead of ".cmake" for template files to substitution processing

[Adriaan de Groot]

On Monday, 4 January 2021 08:21:57 CET Friedrich W. H. Kossebau wrote:

> And the proposal is to use ".in".
> 
> Pros:

I would support just consistently adding ".in" (which, in the case of 
producing Config files for cmake, means foo.cmake.in).

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: RFC: suffix ".in" instead of ".cmake" for template files to substitution processing

[Adriaan de Groot]

On Monday, 4 January 2021 08:21:57 CET Friedrich W. H. Kossebau wrote:

> And the proposal is to use ".in".
> 
> Pros:

I would support just consistently adding ".in" (which, in the case of 
producing Config files for cmake, means foo.cmake.in).

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: KACL from KIO isn't really POSIX-compliant

[Adriaan de Groot]

On 2020 dekula d. 11id 16:37:19 CET Aleix Pol wrote:
> > I tried compiling kio/src/core/kacl.cpp on FreeBSD, which does support
> > POSIX ACLs, and failed. This is because KACL's code uses non-standard
> > Linux-specific acl_* functions. I tried implementing them using standard
> > ones and it turned out to be impossible, mainly because types like acl_t
> > are opaque to the user of the library.

[[ I'm aware of Gleb's work, I'd really like a non-FreeBSD perspective on this 
]]

Here's *part* of the problem:

bool KACL::operator==(const KACL ) const
{
#if HAVE_POSIX_ACL
return (acl_cmp(d->m_acl, rhs.d->m_acl) == 0);
#else
Q_UNUSED(rhs);
return true;
#endif
}

It *looks* like portable code, it's checking if POSIX is available, does a 
comparison, that's fine. Except that acl_cmp() is **not** a POSIX function.

https://man7.org/linux/man-pages/man3/acl_cmp.3.html

The POSIX ACL spec sucks. There is no way to compare sets of ACLs. So the non-
portable Linux-specific function makes a lot of sense: that **should** have 
been in POSIX.

Gleb's question is about where this should be fixed. FreeBSD's libc is the 
"obvious" solution, because this is generally useful ACL API, but fixing up 
libc, especially with something grotty like a Linux-specific function 
(opinions expressed may not be my own) is a slowww process. But doing the 
same thing in KIO itself means a huge code bloat in KIO.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: RFC: Switching to min Qt version 5.14 for KF on December 14th

[Adriaan de Groot]

On Sunday, 6 December 2020 18:05:19 CET David Faure wrote:
> On dimanche 6 décembre 2020 17:39:38 CET Albert Astals Cid wrote:
> >  * MidnightBSD
> >  * openBSD
> > 
> > The BSDs are a bit more unfortunate.
> 
> Thanks for the information, Albert.
> 
> Apparently this means bumping the requirement to Qt 5.14 would break
> OpenBSD.
> 
> How can we reach OpenBSD KDE people?
> CC'ing kde-free...@kde.org, I know it's not the same, but maybe you guys
> know? ;)

Rafael Sadowski , ping them on invent or on phab (or in the CC of this message 
:) ).

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Fwd: KCalendarCore Require Libical 3.0

[Adriaan de Groot]

On Tuesday, 24 November 2020 22:39:44 CET Allen Winter wrote:
> On Tuesday, November 24, 2020 8:13:12 AM EST Allen Winter wrote:
> > I plan to implement this new requirement 2 weeks from now.
> > unless there are good reasons against.
> > 
> > Unless there are objections, I'd like to require libical v3.0 in
> > kcalendarcore. libical v3.0.0 was released over 3 years ago (28 Oct 2017)

That's fine from the KDE-FreeBSD side, CI builders are up-to-date:

libical-3.0.8_1Implementation of the IETF Calendaring and 
Scheduling protocols

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: NeoChat in KDEReview

[Adriaan de Groot]

On Sunday, 22 November 2020 21:16:53 CET Adriaan de Groot wrote:
> Thanks Carl for chasing Albert's comments so quickly. Here's my review
> comments on neochat 5316e32004fcfa60d72f373e2e55b44b8fecf2c7 (master HEAD as
> of right now).

I should add that, in spite of all my gripes, this is the first Matrix client 
I've used that I actually *like*. I'm not sure just what it is, though. 
Spectral and Fractal and Nheko have their quirks, just enough to turn me off 
(although I use nheko regularly anyway because up until recently it was the 
best of the lot) and Quaternion looks the most like an old-school IRC client.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: NeoChat in KDEReview

[Adriaan de Groot]

Thanks Carl for chasing Albert's comments so quickly. Here's my review 
comments on neochat 5316e32004fcfa60d72f373e2e55b44b8fecf2c7 (master HEAD as 
of right now).

On Sunday, 22 November 2020 12:40:16 CET Carl Schwan wrote:
> Le samedi, novembre 21, 2020 1:26 AM, Albert Astals Cid  a 
écrit :
> > El dijous, 19 de novembre de 2020, a les 23:27:24 CET, Carl Schwan va 
escriure:
> > > Tobias and I have been working on a Matrix client using Kirigami,
> > > named NeoChat. NeoChat is still missing a few features to become

I'm going to admit that I'm using KDE Frameworks 5.75, rather than 5.76. For 
Kirigami, where application use is now strongly steering development and 
bugfixing, that might be a terrible choice. I've been told at least some bugs 
are fixed in 5.76 already.

That said:

-1. Uses the Spectral icon in the About page and in the systray (only 
confusing if Spectral is also around, and depending on your relationship with 
Spectral, might be kind of rude).

0. Emoji fonts continue to be an issue (a packaging issue, I'm sure -- noto 
emoji and noto-extra or equivalents seem to be needed) .

1. Alongside the "write your message" there are three buttons. None of them 
have tooltips. There's a smiley (for emoji), a paperclip (for attachments) and 
a lemon juicer. Is there ever, ever, any reason to click the lemon juicer?

2. Clicking on the emoji button gets me an emoji picker -- with no tooltips, 
and no way to get back to writing a text message. (I suspect this is 
frameworks-version dependent, since the text block is also way too tall)

3. In the upper-right of the chat pane, there's a round (it was square-ish 
yesterday) button with an up-chevron in it. No tooltip. Clicking on it does 
nothing (I get an error message on stdout: searching for non-existent event .. 
which makes me think this goes back in history looking for mentions). It'd be 
nice to have it disabled when there's nothing it can do.

4. There's no way to resize or hide the list of channels. Most of the time 
that's the least interesting thing on screen -- I just need a channel avatar 
and number of messages, not the full description of each channel.

5. The show-room-members pane doesn't have a tooltip, and doesn't highlight 
like a button does (like the emoji button).

Usage scenarios:

6. Click on the text-field for writing messages. Type "derp". Notice flashing 
text cursor in text-field. Click on the room-list. Text-cursor disappears from 
text-field. Type something: this doesn't appear *anywhere*. It doesn't search 
or filter the room list, nor does it go to the regular text input.

Since there's a "search" field for rooms, I expect that typing things into 
neochat goes to the-message-to-be-sent **except** if something explicitly 
different is chosen. Quasselclient does this: click on the chats list and 
start typing, and it re-sets focus to the message box.

7. RMB "mark as read" on a room to clear the unread-messages-count is kind of 
unintuitive. Especially since scrolling all the way up in the chat list, and 
then all the way down, doesn't clear it either. It feels like a "you must 
acknowledge these" kind of thing.

8. Clicking on the rooms-list pane makes the topmost-right button -- the show-
room-members-pane button -- disappear. It reappears if you click on the 
message text-field.

9. If I go to the hamburger-menu, and pick accounts, there's a list of 
accounts (just one). I tried to add one of my other accounts -- 
opendesktop.org -- which doesn't work: I get a red message immediately that 
that thing is not a Matrix server. I know it is, because my Quaternion-based 
chatbot is on it :S This is an improvement on yesterday, though, when I got no 
error message (or it took so long I didn't notice anymore).

10. So if I decide I don't want to login after all, there's no obvious cancel 
button. The hamburger menu doesn't take me back to chat-mode. The only way to 
get back to chatting is to click the "back" arrow between the burger and the 
current-page-title until I get there. This starts to get annoying around the 
time I've gone "(hamburger) Accounts" "(button) Add Account" "(hamburger) 
Settings" "(hamburger) About" and have to click 4 < to get out of that.



(Those parts of this that are already fixed with Frameworks 5.76, just shout 
at me "YOUR FAULT FOR DISREGARDING CMAKE ERRORS")

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Call for Mentors (and Admins) for Season of KDE 2021

[Adriaan de Groot]

On Saturday, 24 October 2020 13:44:10 CEST Carl Schwan wrote:
> > -   added Calamares projects (there's a dozen hacktoberfest issues
> > available, all of which are also suitable SoK things)
> 
> Thanks a lot for this  We are still looking for mentors so if anyone has a
> bit of time and good ideas of potential projects, please consider mentoring
> for SoK 2021.

In retrospect I'm less sure about this: the 2018 announcement talks about 40- 
and 80-day projects, which the Calamares jobs emphatically are **not**. Maybe 
I'm getting this confused with Code-In or something where the emphasis is on 
smaller contributions and getting started in development.

With Calamares development typically being on a 14-day cycle, I'm not sure 
that *anything* I can come up with would actually consume that much time.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: plasma-systemmonitor in kdereview

[Adriaan de Groot]

On 2020 tobula d. 19id 00:28:38 CEST Albert Astals Cid wrote:
> El dijous, 1 d’octubre de 2020, a les 11:36:12 CEST, Arjen Hiemstra va 
escriure:
> > I'd hereby like to announce that plasma-systemmonitor is in kdereview. It
> > can be found at https://invent.kde.org/plasma/plasma-systemmonitor .
> 
> How serious are these cmake warnings? http://paste.debian.net/1167754/

If this one error is to believed (and is faithfully cut-and-pasted):

  Error: description missing, will result in broken appdata field as
   is mandatory at
  /home/tsdgeos/devel/kde/plasma-systemmonitor/src/faces/applicationstable/
metadata.desktop
Call Stack (most recent call first):
  src/faces/CMakeLists.txt:1 (kpackage_install_package)

Then we have a typo problem somewhere else as well, since "sumary" is an 
unlikely element name.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: CI Breakage in Solid on FreeBSD

[Adriaan de Groot]

On Thursday, 15 October 2020 11:22:02 CEST Ben Cooksley wrote:
> Yesterday changes were landed to Solid, allowing it to make use of new
> libimobiledevice API. Unfortunately these changes failed to handle the
> situation where an older version of libimobiledevice is in use, causing a
> build failure on FreeBSD.

We -- Ahmed, Kai Uwe, me -- are on it. It won't be an instant-fix because 
IDEVICE_DEVICE_PAIRED isn't a #define, it's an enum value, but we'll get to 
it.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: CI Breakage in Solid on FreeBSD

[Adriaan de Groot]

On Thursday, 15 October 2020 11:22:02 CEST Ben Cooksley wrote:
> Yesterday changes were landed to Solid, allowing it to make use of new
> libimobiledevice API. Unfortunately these changes failed to handle the
> situation where an older version of libimobiledevice is in use, causing a
> build failure on FreeBSD.

We -- Ahmed, Kai Uwe, me -- are on it. It won't be an instant-fix because 
IDEVICE_DEVICE_PAIRED isn't a #define, it's an enum value, but we'll get to 
it.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Supported C++ standard (aka compiler version) Overview Table for various distros?

[Adriaan de Groot]

On Wednesday, 14 October 2020 12:07:04 CEST Neal Gompa wrote:
> On Wed, Oct 14, 2020 at 5:33 AM Milian Wolff  wrote:
> > Hey all,
> > 
> > I would like to push for C++17 usage in KDevelop to make it more fun to
> > develop there. This is an extragear app, so I believe we can take this
> > decision separately from the surrounding KDE ecosystem.
> > 
> > Does anyone know if there's an overview page similar to [1], but for Linux
> > distributions?

> I think you'll be generally fine.

That ^^

FreeBSD on x86-es and arm64 ships with clang 8, 10 or 11 depending on the 
FreeBSD version; everything supported is clang 10-or-later.

FreeBSD on PowerPC (Power 9) is gcc -- gcc 9 or later I think.

OpenBSD latest release lists clang 8 and gcc 4 and gcc 3 .. let's assume / 
hope they use clang as the compiler for KDE bits.

OpenIndiana / Illumos (OpenSolaris) lists gcc 7 as the base compiler.


Linuxes not in "the big five" that I happen to have on-hand:
- KaOS (Debian-ish) has gcc 9.3.
- Manjaro (Arch) has clang-10 and gcc 10.
- ArcoLinux (Arch) has gcc 10.
- Netrunner 19 (Debian) has clang-7 and gcc 8, this is the oldest distro I'm 
still running, mostly for its pre-Qt 5.12 state.


I think you'll be fine, even on obscure or outdated systems.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Call for Mentors (and Admins) for Season of KDE 2021

[Adriaan de Groot]

On Thursday, 10 September 2020 16:11:08 CEST Caio Jordão Carvalho wrote:
> As discussed in the SoK/GSoC BoF that we had yesterday, our plan is
> to start the next edition of Season of KDE soon. But first we need to
> include
> some ideas in our ideas page and, most importantly, *we need mentors*! So

I couldn't tell if SoK was moving forward or likely to happen this year, but 
since I wrote up a bunch of starter-issues for Calamares (close-to-a-KDE-
project) for Hacktoberfest (not-a-KDE-activity) which also fit the SoK theme, 
I did the following:

- updated SoK wiki front (https://community.kde.org/SoK) to mention 2021
- added a general About page
- added Calamares projects (there's a dozen hacktoberfest issues available, 
all of which are also suitable SoK things)

I did not:
- even try to update https://season.kde.org/ (because Drupal, so it's not 
something I think I can reach)

The s.k.o site makes it look like December 2019 is in the future, which is 
kind of confusing. It'd be better to have it showing, say, the text "SoK 2020 
is over, we're collecting ideas for 2021, the fancy JavaScript wheel-calendar-
thingy is switched off but take a look at the Wiki for now" so it's clear 
where we're at.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: KDE Frameworks 5.74.0 released

[Adriaan de Groot]

On Sunday, 13 September 2020 13:16:47 CEST Andreas Müller wrote:
> On Sat, Sep 12, 2020 at 1:33 PM David Faure  wrote:
> > 12th September 2020. KDE today announces the release of KDE Frameworks
> > 5.74.0.
> Not mentioned here: Many (All?) licenses are now according to REUSE
> policy [1]. Reading that did not help me much so my questions here:
> For example syntax-highlighting 5.73 was clearly stated as MIT. With
> 5.74.0 it is - have not the slightest idea.

In v5.73.0, there is a top-level file called COPYING, which contains the MIT 
license (and a weird reference to "above copyright notice", which notice is 
missing from the file).

The data included with the library (XML files), however, is variously LGPL, 
GPL, .. I didn't dive into it exactly. In other words, while the *code* is 
MIT, the whole thing might not be (please ask a lawyer, and look closely at 
exactly what you are combining).


In v5.74.0, there is no top-level file anymore. So you don't get a single 
message "this is MIT" -- which is confusing, maybe, except that the message 
was factually misleading in v5.73.0. The LICENSES/ directory tells you what 
licenses are used, across the whole repository, but not what-goes-where.

With grep, you now have a single [*], unambiguous, way of finding out what 
licenses apply to the code: `grep -r SPDX-License-Identifier src/`

That's easier than guessing the applicable license from the text blobs and the 
myriad spellings of each license.



So the (perhaps unfortunate) conclusion is, in licensing, "it's complicated" 
and the previously unambiguous assertion "MIT" was not, in fact, unambiguous 
or entirely true.


[ade]


[*] For greater coverage `reuse spdx` will give you a report on each file with 
additional information, known as an SPDX bill of materials. `reuse lint` will 
tell you this:

* Files with copyright information: 147 / 1508
* Files with license information: 72 / 1508

So for this repo, there's a ways to go still.

signature.asc
Description: This is a digitally signed message part.

Re: KDE Frameworks 5.74.0 released

[Adriaan de Groot]

On Sunday, 13 September 2020 13:16:47 CEST Andreas Müller wrote:
> On Sat, Sep 12, 2020 at 1:33 PM David Faure  wrote:
> > 12th September 2020. KDE today announces the release of KDE Frameworks
> > 5.74.0.
> Not mentioned here: Many (All?) licenses are now according to REUSE
> policy [1]. Reading that did not help me much so my questions here:
> For example syntax-highlighting 5.73 was clearly stated as MIT. With
> 5.74.0 it is - have not the slightest idea.

In v5.73.0, there is a top-level file called COPYING, which contains the MIT 
license (and a weird reference to "above copyright notice", which notice is 
missing from the file).

The data included with the library (XML files), however, is variously LGPL, 
GPL, .. I didn't dive into it exactly. In other words, while the *code* is 
MIT, the whole thing might not be (please ask a lawyer, and look closely at 
exactly what you are combining).


In v5.74.0, there is no top-level file anymore. So you don't get a single 
message "this is MIT" -- which is confusing, maybe, except that the message 
was factually misleading in v5.73.0. The LICENSES/ directory tells you what 
licenses are used, across the whole repository, but not what-goes-where.

With grep, you now have a single [*], unambiguous, way of finding out what 
licenses apply to the code: `grep -r SPDX-License-Identifier src/`

That's easier than guessing the applicable license from the text blobs and the 
myriad spellings of each license.



So the (perhaps unfortunate) conclusion is, in licensing, "it's complicated" 
and the previously unambiguous assertion "MIT" was not, in fact, unambiguous 
or entirely true.


[ade]


[*] For greater coverage `reuse spdx` will give you a report on each file with 
additional information, known as an SPDX bill of materials. `reuse lint` will 
tell you this:

* Files with copyright information: 147 / 1508
* Files with license information: 72 / 1508

So for this repo, there's a ways to go still.

signature.asc
Description: This is a digitally signed message part.

Re: Introducing KDE Activity Filter

[Adriaan de Groot]

On Tuesday, 14 July 2020 10:57:41 CEST Ingo Klöcker wrote:
> On Dienstag, 14. Juli 2020 10:20:33 CEST Kåre Särs wrote:
> > Is there a way to verify that the yaml file is syntactically correct
> > before
> > pushing the change?
> 
> There are loads of YAML linters/validators, online and offline. In fact,
> this would be an opportunity to test-drive the awesome GitLab CI/CD. I
> volunteer to implement this, if sysadmin is okay with this.

There's a bunch of different tools for YAML validation indeed. "kwalify" was 
one, I think. With a name like that .. :) Unfortunately, lots of the tools are 
also unmaintained, as I found out when I went looking recently.

JSON-schema claims, though, to be maintained and applies to YAML and beyond 
(for those sensible cases where your YAML is a representation of JSON, and not 
the edge cases of what YAML can do).

For Calamares, which is chock-full of simple YAML files, I ended up bodging a 
tool together in Python where most of the code ends up being validation logic, 
followed by one call to the Python library `jsonschema`. There's probably 
other ready-to-go tools like it.

https://github.com/calamares/calamares/blob/calamares/ci/configvalidator.py

A typical schema file for JSON-schema can be represented in YAML as well 
(because YAML is JSON, or something). Here's one, which has some enums, 
handles a list, and also contains string and boolean settings:

https://github.com/calamares/calamares/blob/calamares/src/modules/welcome/
welcome.schema.yaml

> Or do you mean "semantically correct", i.e. also checking for valid
> projects?

(From a JSON-schema perspective) You might periodically generate a schema type 
that checks the repository-re, for the simple case of |-separated full 
repository names. Personally I'd be more inclined to follow Albert's original 
question, and change the tool not to eat a RE but a YAML list-of-repo-names.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Shift for parts of the CI system to Qt 5.15

[Adriaan de Groot]

On Saturday, 20 June 2020 10:11:04 CEST Volker Krause wrote:
> On Saturday, 20 June 2020 08:20:18 CEST Ben Cooksley wrote:
> > - kaffeine
> 
> This doesn't look like something caused by Qt 5.15, more like an issue with
> the FreeBSD DVB headers, builds on Linux.

https://invent.kde.org/multimedia/kaffeine/-/merge_requests/1

There's a weird bundled set of includes, which in normal packaging we were rm 
-rf'ing, but in the CI builds they're there. The MR ignores them more 
gracefully.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Shift for parts of the CI system to Qt 5.15

[Adriaan de Groot]

On Saturday, 20 June 2020 10:11:04 CEST Volker Krause wrote:
> On Saturday, 20 June 2020 08:20:18 CEST Ben Cooksley wrote:
> > - kaffeine
> 
> This doesn't look like something caused by Qt 5.15, more like an issue with
> the FreeBSD DVB headers, builds on Linux.

https://invent.kde.org/multimedia/kaffeine/-/merge_requests/1

There's a weird bundled set of includes, which in normal packaging we were rm 
-rf'ing, but in the CI builds they're there. The MR ignores them more 
gracefully.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Shift for parts of the CI system to Qt 5.15

[Adriaan de Groot]

On Saturday, 20 June 2020 10:11:04 CEST Volker Krause wrote:
> On Saturday, 20 June 2020 08:20:18 CEST Ben Cooksley wrote:
> > - kaffeine
> 
> This doesn't look like something caused by Qt 5.15, more like an issue with
> the FreeBSD DVB headers, builds on Linux.

https://invent.kde.org/multimedia/kaffeine/-/merge_requests/1

There's a weird bundled set of includes, which in normal packaging we were rm 
-rf'ing, but in the CI builds they're there. The MR ignores them more 
gracefully.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Move Koko to KDEReview

[Adriaan de Groot]

On Friday, 12 June 2020 18:05:36 CEST Carl Schwan wrote:
> > I'm kind of unsure how i feel about it downloading things on cmake time.
> 
> I asked a few packagers I know and for them, since the packagers can
> download the files and put them into the tarball, it should be fine. But
> they also said that it would be way better to have it fetched as run time

There's a couple of angles here:
- if your CMakeLists.txt tries to download something, it will fail.
- if you expect packagers to download additional files then put that in GIANT 
LETTERS in several places; also make any attempted download fail gracefully 
with a useful message ("additional source files are needed ..").

It's not that unusual for a single package to require multiple source tarballs 
or additional source files, but you need to support it *and* be clear about 
what's needed.

Koko does the right thing in accepting an already-downloaded file; it'd be 
nice to fail more gracefully, and you should make it more prominent rather 
than hidden on line 106 of CMakeLists.txt in a subdirectory.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Move Koko to KDEReview

[Adriaan de Groot]

On Thursday, 11 June 2020 23:43:52 CEST Albert Astals Cid wrote:
> I'm kind of unsure how i feel about it downloading things on cmake time.

A fair number of distro's / packagers will go "um nope" (if the package 
building machines even *have* an internet connection during configure / build 
stages).

[ade]

signature.asc
Description: This is a digitally signed message part.

D10829: [WIP] Use DocumentId class

[Adriaan de Groot]

adridg added a comment.
Herald added a subscriber: kde-frameworks-devel.


  This looks abandoned or stalled. @michaelh do you have any plans on this 
front?

REPOSITORY
  R293 Baloo

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

To: michaelh, adridg, #baloo, #frameworks
Cc: kde-frameworks-devel, alexeymin, hurikhan77, lots0logs, LeGast00n, cblack, 
fbampaloukas, domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, 
bruns, abrahams

D23692: kdesu: set kernel flags to prevent ptrace instead of relying on setgid

[Adriaan de Groot]

adridg closed this revision.
adridg added a comment.


  Migrated to invent, https://invent.kde.org/frameworks/kdesu/-/merge_requests/1

REPOSITORY
  R299 KDESu

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

To: maltek, adridg, #frameworks
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D13327: Fix conversion error when compiled against MDNSRESPONDER option

[Adriaan de Groot]

adridg abandoned this revision.
adridg added a comment.


  Pretty much exact same changes were done in D15479 


REPOSITORY
  R272 KDNSSD

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

To: adridg
Cc: sitter, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D13328: A backend is required for kdnssd

[Adriaan de Groot]

adridg abandoned this revision.
adridg added a comment.


  Yeah, let's not then.

REPOSITORY
  R272 KDNSSD

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

To: adridg
Cc: aacid, cgiboudeaux, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns

D23338: Use baseFactory for K_PLUGIN_FACTORY_DECLARATION_WITH_BASEFACTORY_SKEL

[Adriaan de Groot]

adridg abandoned this revision.
adridg added a comment.


  Re-filed on invent

REPOSITORY
  R244 KCoreAddons

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

To: adridg
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D10825: [WIP] Introduce aliases DocId, DeviceId and Inode

[Adriaan de Groot]

adridg added a comment.
Herald added a subscriber: kde-frameworks-devel.


  This looks abandoned with 2 years of no movement. @michaelh do you still feel 
this is a WIP?

REPOSITORY
  R293 Baloo

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

To: michaelh, adridg, #baloo, #frameworks
Cc: kde-frameworks-devel, ngraham, alexeymin, hurikhan77, lots0logs, LeGast00n, 
cblack, fbampaloukas, domson, ashaposhnikov, michaelh, astippich, spoorun, 
bruns, abrahams

D10826: [WIP] Introduce DocumentId class

[Adriaan de Groot]

adridg added a comment.
Herald added a subscriber: kde-frameworks-devel.


  This looks abandoned with 2 years of no movement. @michaelh do you still feel 
this is a WIP?

REPOSITORY
  R293 Baloo

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

To: michaelh, adridg, #baloo, #frameworks
Cc: kde-frameworks-devel, anthonyfieroni, svuorela, hurikhan77, lots0logs, 
LeGast00n, cblack, fbampaloukas, domson, ashaposhnikov, michaelh, astippich, 
spoorun, ngraham, bruns, abrahams

D10856: [WIP] Make tests compile, except one

[Adriaan de Groot]

adridg added a comment.
Herald added a subscriber: kde-frameworks-devel.


  This looks abandoned, no movement in over two years. @michaelh did you still 
want to introduce docId instead of quint64? This diff was supposed to supplant 
D10851  but seems to have fallen asleep as 
well. (In retrospect, perhaps I would have suggested first introducing just 
`using docId = quint64;` somewhere, to get the more-expressive-type-name part 
out of the way before real changes)

REPOSITORY
  R293 Baloo

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

To: michaelh, adridg, #baloo, #frameworks
Cc: kde-frameworks-devel, hurikhan77, lots0logs, LeGast00n, cblack, 
fbampaloukas, domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, 
bruns, abrahams

D10851: autotests: Introduce alias DocId

[Adriaan de Groot]

adridg added a comment.
Herald added a subscriber: kde-frameworks-devel.


  This looks abandoned, no movement in over two years. @michaelh do you want to 
explicitly abandon this one, so we have a clean slate for invent? None of the 
docId type changes seem to have made it to master (see also D10856 
)

REPOSITORY
  R293 Baloo

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

To: michaelh, adridg, #baloo, #frameworks
Cc: kde-frameworks-devel, hurikhan77, lots0logs, LeGast00n, cblack, 
fbampaloukas, domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, 
bruns, abrahams

Re: Information regarding upcoming Gitlab Migration

[Adriaan de Groot]

On 2020 mayula d. 1id 07:08:41 CEST Ben Cooksley wrote:
> On Fri, May 1, 2020 at 2:46 AM Nate Graham  wrote:
> > If I'm understanding things, we have solutions to most or all of the
> > objections raised so far:
> > 
> > - Projects will be allowed to live in--or at least appear in--multiple
> > top-level groups (e.g. plasma-framework could appear in both the
> > Frameworks top-level group and also the Plasma top-level group)
> 
> Projects will have the option to appear in multiple groups yes.

Forgive me for coming full circle on this discussion, but

- a group can have at most one workboard
- a group offers some facilities for managing issues and reviews that cross 
over repositories within that group
- a project (this is one-to-one with "repository", right?) can have as many 
workboards as it likes

If a project can appear in more than one group, isn't the whole distinction 
between flat and namespaced a little .. 

well, how would this proposal fly?

- Put everything in a single group called "kde" (this matches proposal 2 if I 
still remember the original numbering right -- flat, but not at top-level)
- Other groups hold things from "kde" (this matches proposal 3, giving more 
structure / hierarchy)

People browsing *top* level would see group "kde" (for all I care, bookmark 
that one as "I want to browse the list of 1442 repositories") and a bunch of 
logical groups based on how the community organizes itself. People working 
inside a specific group can do their workboardy-things and focus on the 
repositories for that group, while people with an overall interest go to the 
KDE group.



Somehow I get the feeling that we started with some technical limitations 
which were driving particular choices, where those limitations aren't exactly 
what we assumed that they were, and now it looks to me like those limitations 
do not have to meaningfully impact *any* of the choices.

(*if* my understanding is correct; I've been wrong enough times already today)

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Information regarding upcoming Gitlab Migration

[Adriaan de Groot]

On 2020 mayula d. 1id 07:08:41 CEST Ben Cooksley wrote:
> On Fri, May 1, 2020 at 2:46 AM Nate Graham  wrote:
> > If I'm understanding things, we have solutions to most or all of the
> > objections raised so far:
> > 
> > - Projects will be allowed to live in--or at least appear in--multiple
> > top-level groups (e.g. plasma-framework could appear in both the
> > Frameworks top-level group and also the Plasma top-level group)
> 
> Projects will have the option to appear in multiple groups yes.

Forgive me for coming full circle on this discussion, but

- a group can have at most one workboard
- a group offers some facilities for managing issues and reviews that cross 
over repositories within that group
- a project (this is one-to-one with "repository", right?) can have as many 
workboards as it likes

If a project can appear in more than one group, isn't the whole distinction 
between flat and namespaced a little .. 

well, how would this proposal fly?

- Put everything in a single group called "kde" (this matches proposal 2 if I 
still remember the original numbering right -- flat, but not at top-level)
- Other groups hold things from "kde" (this matches proposal 3, giving more 
structure / hierarchy)

People browsing *top* level would see group "kde" (for all I care, bookmark 
that one as "I want to browse the list of 1442 repositories") and a bunch of 
logical groups based on how the community organizes itself. People working 
inside a specific group can do their workboardy-things and focus on the 
repositories for that group, while people with an overall interest go to the 
KDE group.



Somehow I get the feeling that we started with some technical limitations 
which were driving particular choices, where those limitations aren't exactly 
what we assumed that they were, and now it looks to me like those limitations 
do not have to meaningfully impact *any* of the choices.

(*if* my understanding is correct; I've been wrong enough times already today)

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Information regarding upcoming Gitlab Migration

[Adriaan de Groot]

On 2020 mayula d. 1id 07:08:41 CEST Ben Cooksley wrote:
> On Fri, May 1, 2020 at 2:46 AM Nate Graham  wrote:
> > If I'm understanding things, we have solutions to most or all of the
> > objections raised so far:
> > 
> > - Projects will be allowed to live in--or at least appear in--multiple
> > top-level groups (e.g. plasma-framework could appear in both the
> > Frameworks top-level group and also the Plasma top-level group)
> 
> Projects will have the option to appear in multiple groups yes.

Forgive me for coming full circle on this discussion, but

- a group can have at most one workboard
- a group offers some facilities for managing issues and reviews that cross 
over repositories within that group
- a project (this is one-to-one with "repository", right?) can have as many 
workboards as it likes

If a project can appear in more than one group, isn't the whole distinction 
between flat and namespaced a little .. 

well, how would this proposal fly?

- Put everything in a single group called "kde" (this matches proposal 2 if I 
still remember the original numbering right -- flat, but not at top-level)
- Other groups hold things from "kde" (this matches proposal 3, giving more 
structure / hierarchy)

People browsing *top* level would see group "kde" (for all I care, bookmark 
that one as "I want to browse the list of 1442 repositories") and a bunch of 
logical groups based on how the community organizes itself. People working 
inside a specific group can do their workboardy-things and focus on the 
repositories for that group, while people with an overall interest go to the 
KDE group.



Somehow I get the feeling that we started with some technical limitations 
which were driving particular choices, where those limitations aren't exactly 
what we assumed that they were, and now it looks to me like those limitations 
do not have to meaningfully impact *any* of the choices.

(*if* my understanding is correct; I've been wrong enough times already today)

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Information regarding upcoming Gitlab Migration

[Adriaan de Groot]

On 2020 prilula d. 28id 13:35:22 CEST Ben Cooksley wrote:
> Would some form of git alias/custom command script that works similar
> to the following be suitable?
> 
> git kde-clone skrooge
> 
> That script would then search the appropriate groups (ignoring any
> personal repositories including forks), find the necessary repository
> and perform the clone as appropriate for you. Should it find multiple
> results it would output it's results and then exit with a failure
> (giving you names and the clone urls to pick from manually)

That'd actually be pretty cool.

As a standalone script it'd be useful to migrate existing checkouts, so that's 
shooting two birds in one foot. And then you can have a somewhat structured 
namespace, still with simple lookup and unstructured names (until, as Bhushan 
points out in a different message in this thread, you get non-unique labels 
when decomposing structures names).


[ade]


signature.asc
Description: This is a digitally signed message part.

Re: Information regarding upcoming Gitlab Migration

[Adriaan de Groot]

On 2020 prilula d. 29id 06:46:55 CEST Bhushan Shah wrote:
> We have gotten a request for namespacing from projects on multiple
> occassion, in cgit our workaround has always been that we prefix the
> repo name with namespace- (i.e wikitolearn-courses-backend).
> 
> While this works out with our current workflow, it is not really
> optimal. I've also mentioned various new contributor focused
> requirements which lead us to this proposal for structuring in previous
> emails.


Your mention of namespaces reminds me that there was **also** a discussion in 
this thread about workboards and reviews.

GitLab can have **one** workboard per group. So depending on how the 
categories / namespaces work out, we have choices in the overall number of 
workboards:

 - one big one (flat)
 - one per (sub)group / namespace

We should look at this as well. Arguments I've seen in this thread

 - one big one is unmanageably large
 - (sub)communities have asked for smaller (split) workboards
 - split workboards make it harder to work over group boundaries
 - one big one allows moving reviews and tasks to where they belong

(The last point is "because there are no group boundaries").


>From the sound of it (without re-reading this entire thread today) it's a 
distinction between generalists and specialists and a good workflow depends on 
what it is you're trying to coordinate (drat, another "it depends" issue).

[ade]


signature.asc
Description: This is a digitally signed message part.

Re: Information regarding upcoming Gitlab Migration

[Adriaan de Groot]

On 2020 prilula d. 28id 13:35:22 CEST Ben Cooksley wrote:
> Would some form of git alias/custom command script that works similar
> to the following be suitable?
> 
> git kde-clone skrooge
> 
> That script would then search the appropriate groups (ignoring any
> personal repositories including forks), find the necessary repository
> and perform the clone as appropriate for you. Should it find multiple
> results it would output it's results and then exit with a failure
> (giving you names and the clone urls to pick from manually)

That'd actually be pretty cool.

As a standalone script it'd be useful to migrate existing checkouts, so that's 
shooting two birds in one foot. And then you can have a somewhat structured 
namespace, still with simple lookup and unstructured names (until, as Bhushan 
points out in a different message in this thread, you get non-unique labels 
when decomposing structures names).


[ade]


signature.asc
Description: This is a digitally signed message part.

Re: Information regarding upcoming Gitlab Migration

[Adriaan de Groot]

On 2020 prilula d. 28id 13:35:22 CEST Ben Cooksley wrote:
> Would some form of git alias/custom command script that works similar
> to the following be suitable?
> 
> git kde-clone skrooge
> 
> That script would then search the appropriate groups (ignoring any
> personal repositories including forks), find the necessary repository
> and perform the clone as appropriate for you. Should it find multiple
> results it would output it's results and then exit with a failure
> (giving you names and the clone urls to pick from manually)

That'd actually be pretty cool.

As a standalone script it'd be useful to migrate existing checkouts, so that's 
shooting two birds in one foot. And then you can have a somewhat structured 
namespace, still with simple lookup and unstructured names (until, as Bhushan 
points out in a different message in this thread, you get non-unique labels 
when decomposing structures names).


[ade]


signature.asc
Description: This is a digitally signed message part.

Re: Information regarding upcoming Gitlab Migration

[Adriaan de Groot]

There are a whole bunch of considerations and use-cases being discussed at 
once in this thread, and Leinir's post made me think a bit about different 
actors can interact with "the collection of repositories".

One actor is "tooling", as Albert has pointed out. Whatever the resulting 
structure is, it needs to be communicated to tool authors on time for tools to 
be updated, released, and rolled out for use. Tools mentioned so far:
 - kdesrc-build
 - i18n / scripty
 - release scripts
The tools don't have An Opinion regarding the layout, they just need to be 
updated.

A tool-like actor that I don't think has been mentioned so far is "existing 
checkouts". I have a src/kde with all the bits I've looked at "recently". 
There may even be some SVN checkouts there -- I'm willing to forget about 
those. Surprising and annoying me every time I update those sometime in the 
future is not good, but it's only going to annoy me once (per repo, so at most 
143 times for my clones).

I'd be *vaguely* worried about existing crontabs and automatic jobs that we've 
forgotten about, or which others have forgotten about. Those aren't fixable in 
the face of any changes to repositories, anyway.


Turning to human actors, who are the more interesting ones,

On 2020 prilula d. 28id 10:38:36 CEST Dan Leinir Turthra Jensen wrote:
> On Monday, 27 April 2020 21:25:09 BST Albert Astals Cid wrote:
> > El dilluns, 27 d’abril de 2020, a les 13:58:02 CEST, Bhushan Shah va
> > > On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote:
> > > > Does this mean that to clone it we'll have to go "git clone
> > > > kde:games/knetwalk" or something along the lines?

> > > > If that's the case I'd much prefer if we didn't do this, at the moment
> > > > it's already uncomfortable for me to remember the URL for some of the
> > > > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > > > problem and I personally don't see the advantage.


Humans come in all shapes and sizes; here's one called Aleix who likes to 
remember the name of a thing, one single label. (Ironic: this particular Aleix 
is also labelled "Aleix Pol" and possibly "Aleix Pol Gonzales") The question 
I'd ask is "in what **context** do you need to remember the URL of a repo?" 
and for that matter: "why is 'knetwalk' an obvious thing to remember, and 
'games/knetwalk' not-obvious?"

Context here can mean many things. In this thread we've had mentioned:
 - people just browsing and wanting A Big List
   Here a hierarchical approach means more clicks and navigating a tree,
   rather than a flat structure.
 - people browsing for a known label
   Using ^F in a flat list or some search field (see also Ian Wadham's
   message just now) doesn't seem *that* different to me, although I've
   got to give ^F the benefit of speed and simplicity.
 - developers sharing a task list and reviews

.. probably more. Some of these roles have, depending on the chosen solution, 
problems that can be solved with a *technical* addition 
(bigflatlistofrepositories.kde.org .. or whatever), others are going to need a 
social solution.



Personally, I'm with Leinir here:

> Just adding my "i don't use kdesrc-build, and git clone kde:x everything
> myself" voice, here. 

Perhaps it's the "old school", but kdesrc-build doesn't do anything for me. 
I'm intermittently interested in the source of some random part of KDE -- 
generally because it's mentioned on IRC -- and then I need that source where I 
can look at it. Whether it's 'git clone' or 'kdesrc-build --just-the-source-
please' doesn't matter much.

If there's any compiling to be done, the less magic there is between me and 
the compile, the better.

So, yeah: `git clone kde:x` all the way, but I'm also not really invested in 
the structure of the label x, or the precise configuration of kde:.


> Now, if a simple(ish) script can be created to make
> something akin to the kde: rewriting work, even if what it really does is to
> search gitlab and create a clone with the appropriate command, i could deal
> with that, but having the ability to simply ask for the project name is
> more than a little useful.

I think we shouldn't underestimate how names are a social construct, though: 
the current flat structure comes after a structured SVN naming epoch. But I'd 
totes +1 a search-and-redirector, especially if it means I can write `git 
clone kde:peruse` and the resulting .git/config has followed the redirects and 
whatnot and ended up with `url: kdeforreal:audio/peruse`

(That said, bigflatlistofrepositories.kde.org .. or maybe call it cgit.kde.org 
.. could be a particular view onto gitlab which does flattening and search, 
but only if there's people around to create it and maintain it)

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Information regarding upcoming Gitlab Migration

[Adriaan de Groot]

There are a whole bunch of considerations and use-cases being discussed at 
once in this thread, and Leinir's post made me think a bit about different 
actors can interact with "the collection of repositories".

One actor is "tooling", as Albert has pointed out. Whatever the resulting 
structure is, it needs to be communicated to tool authors on time for tools to 
be updated, released, and rolled out for use. Tools mentioned so far:
 - kdesrc-build
 - i18n / scripty
 - release scripts
The tools don't have An Opinion regarding the layout, they just need to be 
updated.

A tool-like actor that I don't think has been mentioned so far is "existing 
checkouts". I have a src/kde with all the bits I've looked at "recently". 
There may even be some SVN checkouts there -- I'm willing to forget about 
those. Surprising and annoying me every time I update those sometime in the 
future is not good, but it's only going to annoy me once (per repo, so at most 
143 times for my clones).

I'd be *vaguely* worried about existing crontabs and automatic jobs that we've 
forgotten about, or which others have forgotten about. Those aren't fixable in 
the face of any changes to repositories, anyway.


Turning to human actors, who are the more interesting ones,

On 2020 prilula d. 28id 10:38:36 CEST Dan Leinir Turthra Jensen wrote:
> On Monday, 27 April 2020 21:25:09 BST Albert Astals Cid wrote:
> > El dilluns, 27 d’abril de 2020, a les 13:58:02 CEST, Bhushan Shah va
> > > On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote:
> > > > Does this mean that to clone it we'll have to go "git clone
> > > > kde:games/knetwalk" or something along the lines?

> > > > If that's the case I'd much prefer if we didn't do this, at the moment
> > > > it's already uncomfortable for me to remember the URL for some of the
> > > > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > > > problem and I personally don't see the advantage.


Humans come in all shapes and sizes; here's one called Aleix who likes to 
remember the name of a thing, one single label. (Ironic: this particular Aleix 
is also labelled "Aleix Pol" and possibly "Aleix Pol Gonzales") The question 
I'd ask is "in what **context** do you need to remember the URL of a repo?" 
and for that matter: "why is 'knetwalk' an obvious thing to remember, and 
'games/knetwalk' not-obvious?"

Context here can mean many things. In this thread we've had mentioned:
 - people just browsing and wanting A Big List
   Here a hierarchical approach means more clicks and navigating a tree,
   rather than a flat structure.
 - people browsing for a known label
   Using ^F in a flat list or some search field (see also Ian Wadham's
   message just now) doesn't seem *that* different to me, although I've
   got to give ^F the benefit of speed and simplicity.
 - developers sharing a task list and reviews

.. probably more. Some of these roles have, depending on the chosen solution, 
problems that can be solved with a *technical* addition 
(bigflatlistofrepositories.kde.org .. or whatever), others are going to need a 
social solution.



Personally, I'm with Leinir here:

> Just adding my "i don't use kdesrc-build, and git clone kde:x everything
> myself" voice, here. 

Perhaps it's the "old school", but kdesrc-build doesn't do anything for me. 
I'm intermittently interested in the source of some random part of KDE -- 
generally because it's mentioned on IRC -- and then I need that source where I 
can look at it. Whether it's 'git clone' or 'kdesrc-build --just-the-source-
please' doesn't matter much.

If there's any compiling to be done, the less magic there is between me and 
the compile, the better.

So, yeah: `git clone kde:x` all the way, but I'm also not really invested in 
the structure of the label x, or the precise configuration of kde:.


> Now, if a simple(ish) script can be created to make
> something akin to the kde: rewriting work, even if what it really does is to
> search gitlab and create a clone with the appropriate command, i could deal
> with that, but having the ability to simply ask for the project name is
> more than a little useful.

I think we shouldn't underestimate how names are a social construct, though: 
the current flat structure comes after a structured SVN naming epoch. But I'd 
totes +1 a search-and-redirector, especially if it means I can write `git 
clone kde:peruse` and the resulting .git/config has followed the redirects and 
whatnot and ended up with `url: kdeforreal:audio/peruse`

(That said, bigflatlistofrepositories.kde.org .. or maybe call it cgit.kde.org 
.. could be a particular view onto gitlab which does flattening and search, 
but only if there's people around to create it and maintain it)

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Information regarding upcoming Gitlab Migration

[Adriaan de Groot]

There are a whole bunch of considerations and use-cases being discussed at 
once in this thread, and Leinir's post made me think a bit about different 
actors can interact with "the collection of repositories".

One actor is "tooling", as Albert has pointed out. Whatever the resulting 
structure is, it needs to be communicated to tool authors on time for tools to 
be updated, released, and rolled out for use. Tools mentioned so far:
 - kdesrc-build
 - i18n / scripty
 - release scripts
The tools don't have An Opinion regarding the layout, they just need to be 
updated.

A tool-like actor that I don't think has been mentioned so far is "existing 
checkouts". I have a src/kde with all the bits I've looked at "recently". 
There may even be some SVN checkouts there -- I'm willing to forget about 
those. Surprising and annoying me every time I update those sometime in the 
future is not good, but it's only going to annoy me once (per repo, so at most 
143 times for my clones).

I'd be *vaguely* worried about existing crontabs and automatic jobs that we've 
forgotten about, or which others have forgotten about. Those aren't fixable in 
the face of any changes to repositories, anyway.


Turning to human actors, who are the more interesting ones,

On 2020 prilula d. 28id 10:38:36 CEST Dan Leinir Turthra Jensen wrote:
> On Monday, 27 April 2020 21:25:09 BST Albert Astals Cid wrote:
> > El dilluns, 27 d’abril de 2020, a les 13:58:02 CEST, Bhushan Shah va
> > > On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote:
> > > > Does this mean that to clone it we'll have to go "git clone
> > > > kde:games/knetwalk" or something along the lines?

> > > > If that's the case I'd much prefer if we didn't do this, at the moment
> > > > it's already uncomfortable for me to remember the URL for some of the
> > > > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > > > problem and I personally don't see the advantage.


Humans come in all shapes and sizes; here's one called Aleix who likes to 
remember the name of a thing, one single label. (Ironic: this particular Aleix 
is also labelled "Aleix Pol" and possibly "Aleix Pol Gonzales") The question 
I'd ask is "in what **context** do you need to remember the URL of a repo?" 
and for that matter: "why is 'knetwalk' an obvious thing to remember, and 
'games/knetwalk' not-obvious?"

Context here can mean many things. In this thread we've had mentioned:
 - people just browsing and wanting A Big List
   Here a hierarchical approach means more clicks and navigating a tree,
   rather than a flat structure.
 - people browsing for a known label
   Using ^F in a flat list or some search field (see also Ian Wadham's
   message just now) doesn't seem *that* different to me, although I've
   got to give ^F the benefit of speed and simplicity.
 - developers sharing a task list and reviews

.. probably more. Some of these roles have, depending on the chosen solution, 
problems that can be solved with a *technical* addition 
(bigflatlistofrepositories.kde.org .. or whatever), others are going to need a 
social solution.



Personally, I'm with Leinir here:

> Just adding my "i don't use kdesrc-build, and git clone kde:x everything
> myself" voice, here. 

Perhaps it's the "old school", but kdesrc-build doesn't do anything for me. 
I'm intermittently interested in the source of some random part of KDE -- 
generally because it's mentioned on IRC -- and then I need that source where I 
can look at it. Whether it's 'git clone' or 'kdesrc-build --just-the-source-
please' doesn't matter much.

If there's any compiling to be done, the less magic there is between me and 
the compile, the better.

So, yeah: `git clone kde:x` all the way, but I'm also not really invested in 
the structure of the label x, or the precise configuration of kde:.


> Now, if a simple(ish) script can be created to make
> something akin to the kde: rewriting work, even if what it really does is to
> search gitlab and create a clone with the appropriate command, i could deal
> with that, but having the ability to simply ask for the project name is
> more than a little useful.

I think we shouldn't underestimate how names are a social construct, though: 
the current flat structure comes after a structured SVN naming epoch. But I'd 
totes +1 a search-and-redirector, especially if it means I can write `git 
clone kde:peruse` and the resulting .git/config has followed the redirects and 
whatnot and ended up with `url: kdeforreal:audio/peruse`

(That said, bigflatlistofrepositories.kde.org .. or maybe call it cgit.kde.org 
.. could be a particular view onto gitlab which does flattening and search, 
but only if there's people around to create it and maintain it)

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Type=FSDevice desktop files

[Adriaan de Groot]

On 2020 prilula d. 26id 23:45:09 CEST David Faure wrote:
> This was useful back then, for USB keys and CDROMs (kids, ask your parents
> what that was), before Solid, before the plasma device notification popup...

I have a CDRom drive. It contains an OpenBSD 6.3 install CD, even -- that's 
for testing the very-very-slow-ongoing removal of HAL support code from Solid 
and Plasma, which is consumed only by FreeBSD. (Except I need to get a 
*second* drive, and a linux machine working with it, to cross check the user-
experience)

[ade]


signature.asc
Description: This is a digitally signed message part.

Re: Kup in KDE Review

[Adriaan de Groot]

On Monday, 6 April 2020 12:32:54 CEST Simon Persson wrote:
> Please help to review kup.

- It's probably worthwhile looking at REUSE licensing compliance (see 
reuse.software, or ask on IRC #kde-devel) so that the license is machine-
readable and checkable.
- Although you find_package(LibGit2) you were linking "old style" instead of 
using the imported target LibGit2::LibGit2. I pushed a build fix, now it 
builds on FreeBSD as well.


- Uses a handful of deprecated methods; depending on what exactly you want to 
be compatible with, you might chase those.


[ade]

Re: Does FreeBSD have HAL?

[Adriaan de Groot]

On Saturday, 4 January 2020 18:16:30 CET David Faure wrote:
> qdbus --system org.freedesktop.HalManage

Does not exist. There's some complications around HAL. We don't necessarily 
run it, but solid wants it, and the CD-eject functionality of Plasma Device 
notifier needs it (so I can't eject CD's on my home machine). I'm not 100% 
sure bsdisks can do all the things we want already.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: KTimeTracker in kdereview

[Adriaan de Groot]

On Tuesday, 19 November 2019 05:20:23 CET Alexander Potashev wrote:
> KTimeTracker is a time tracker desktop application which is well
> suited for tracking labor time you spend on a specific
> project/feature/customer.

Builds clean on FreeBSD; that's a +1.

I ran it once, it works nicely .. I'd have a fistful of feature requests for 
it before it can replace Charm Time Tracker in my workflow, though.

[ade]


signature.asc
Description: This is a digitally signed message part.

Re: KIOFuse in kdereview

[Adriaan de Groot]

On Monday, 4 November 2019 23:08:44 CET Alexander Saoutkin wrote:
> Currently, KIOFuse has been tested to work on Linux, although there are no
> technical reasons why it can’t work on FreeBSD.

I'm working on this, and Fabian Vogt has been a tremendous help in moving that 
forward; we can say "it *does* work on FreeBSD, but there's an intermittent 
test failure that needs to be investigated".

[ade]

D25084: Allow a Multiple instances to become Unique

[Adriaan de Groot]

adridg added a comment.


  Now you (@davidedmundson ) mention it, yeah .. I've only tested positively, 
to see if konsole then does what I want. You're right that this could have 
surprising effects when multiple unique applications share a prefix (e.g. 
org.kde.plasma.something and org.kde.plasma.somethingentirelydifferent). There 
would have to be a closer check to find "this is really an instance of the 
intended application" and not have accidents with startsWith().

REPOSITORY
  R271 KDBusAddons

BRANCH
  multiple_to_unique

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

To: tcanabrava, adridg
Cc: davidedmundson, adridg, ngraham, kde-frameworks-devel, LeGast00n, GB_2, 
michaelh, bruns

D25084: Allow a Multiple instances to become Unique

[Adriaan de Groot]

adridg accepted this revision.
adridg added a comment.
This revision is now accepted and ready to land.


  This has been applied to FreeBSD ports because it works. +1 (with the other 
konsole patch that **is** on invent).

REPOSITORY
  R271 KDBusAddons

BRANCH
  multiple_to_unique

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

To: tcanabrava, adridg
Cc: adridg, ngraham, kde-frameworks-devel, LeGast00n, GB_2, michaelh, bruns

D21146: KProcessInfoList -- add proclist backend for FreeBSD

[Adriaan de Groot]

adridg accepted this revision.
adridg added a comment.
This revision is now accepted and ready to land.


  Let's get this in, and then quibble about how much commentary needs to be 
written for the `_p.h` file (since, looking back, it's a bit heavy on the C++ 
fancyness -- my Opinions have changed a little)

REPOSITORY
  R244 KCoreAddons

BRANCH
  procstat_v3

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

To: tcberner, #freebsd, adridg, davidedmundson
Cc: pino, apol, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24431: Restore cursor thumbnailer

[Adriaan de Groot]

adridg added inline comments.

INLINE COMMENTS

> CMakeLists.txt:149
>  
> -# if(X11_Xcursor_FOUND)
> -#
> -#set(cursorthumbnail_PART_SRCS cursorcreator.cpp)
> -#
> -#add_library(cursorthumbnail MODULE ${cursorthumbnail_PART_SRCS})
> -#
> -#target_link_libraries(cursorthumbnail ${X11_Xcursor_LIB} 
> ${KIO_LIBRARIES})
> -#
> -#install(TARGETS cursorthumbnail DESTINATION ${KDE_INSTALL_PLUGINDIR})
> -#install( FILES cursorthumbnail.desktop DESTINATION 
> ${KDE_INSTALL_KSERVICES5DIR})
> -#
> -# endif()
> -#
> +if(X11_FOUND)
> +

X11_Xcursor_FOUND, since X11 can be found without Xcursor.

REPOSITORY
  R320 KIO Extras

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

To: broulik, #plasma, fredrik, ngraham
Cc: adridg, ngraham, kde-frameworks-devel, kfm-devel, iasensio, fprice, 
LeGast00n, MrPepe, fbampaloukas, alexde, GB_2, Codezela, feverfew, meven, 
michaelh, spoorun, navarromorales, firef, andrebarros, bruns, emmanuelp, 
mikesomov

Re: Work Branches

[Adriaan de Groot]

On Saturday, 5 October 2019 04:11:11 CEST Ben Cooksley wrote:
> 2) Protect all branches, aside from a given prefix (proposed to be work/)

+1 for a simple and clear policy.

[ade]

signature.asc
Description: This is a digitally signed message part.

D23692: kdesu: set kernel flags to prevent ptrace instead of relying on setgid

[Adriaan de Groot]

adridg accepted this revision.
adridg added a comment.
This revision is now accepted and ready to land.


  LGTM on the FreeBSD side (I've checked, the procctl() code does block 
debugger access which is all we're asking to do).

REPOSITORY
  R299 KDESu

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

To: maltek, adridg, #frameworks
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D23335: Q_UNUSED doesn't need a ; after it.

[Adriaan de Groot]

This revision was automatically updated to reflect the committed changes.
Closed by commit R244:8e34c0b97393: Q_UNUSED doesnt need a ; after it. 
(authored by adridg).

REPOSITORY
  R244 KCoreAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D23335?vs=64272=64282

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

AFFECTED FILES
  src/lib/plugin/kpluginfactory.h

To: adridg, davidedmundson
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D23338: Use baseFactory for K_PLUGIN_FACTORY_DECLARATION_WITH_BASEFACTORY_SKEL

[Adriaan de Groot]

adridg created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
adridg requested review of this revision.

REVISION SUMMARY
  The existing macro always inherits from KPluginFactory -- making
  it hard to use when sub-classing KPluginFactory in order to extend it.
  The parameter `baseFactory` to the macro isn't used.
  
  Use `baseFactory` as the base class for the plugin.
  
  BUG #410851

TEST PLAN
  This is a tough one. Who knows what kind of junk people have put
  into baseFactory, since it's not used.

REPOSITORY
  R244 KCoreAddons

BRANCH
  master

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

AFFECTED FILES
  src/lib/plugin/kpluginfactory.h

To: adridg
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D23335: Q_UNUSED doesn't need a ; after it.

[Adriaan de Groot]

adridg created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
adridg requested review of this revision.

REVISION SUMMARY
  This reduces compiler warnings (-Wall, or just clang) about unnecessary ;s.

REPOSITORY
  R244 KCoreAddons

BRANCH
  master

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

AFFECTED FILES
  src/lib/plugin/kpluginfactory.h

To: adridg
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D22765: Docs: fix bad example code

[Adriaan de Groot]

This revision was automatically updated to reflect the committed changes.
Closed by commit R296:2d39e2f0ad56: Docs: fix bad example code (authored by 
adridg).

REPOSITORY
  R296 KDeclarative

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22765?vs=62614=62623

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

AFFECTED FILES
  README.md

To: adridg, davidedmundson
Cc: kde-frameworks-devel, LeGast00n, sbergeron, michaelh, ngraham, bruns

D22765: Docs: fix bad example code

[Adriaan de Groot]

adridg created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
adridg requested review of this revision.

REVISION SUMMARY
  - setupBindings() doesn't take an engine parameter
  - setupBindings() is deprecated and suggests to call setupContext() instead, 
although you need to setup the engine as well **and** tell KDeclarative to use 
that engine.

TEST PLAN
  - the previous example code wouldn't compile

REPOSITORY
  R296 KDeclarative

BRANCH
  fix-apidocs

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

AFFECTED FILES
  README.md

To: adridg
Cc: kde-frameworks-devel, LeGast00n, sbergeron, michaelh, ngraham, bruns

D21146: KProcessInfoList -- add proclist backend for FreeBSD

[Adriaan de Groot]

adridg added inline comments.

INLINE COMMENTS

> adridg wrote in kprocesslist_unix_procstat.cpp:38
> I absolutely have Opinions on C++ style that apply here, so I'm going to talk 
> to Tobias elsewhere.

In order to simplify cleanup, I'd use a RAII class as well:

  /** @brief Wrapper around procstat_open_sysctl()
   * 
   * Hangs on to a procstat instance for its friend classes, and closes
   * it on destruction. Cast to bool to check for success.
   */
  struct ProcStat
  {
  ProcStat()
  {
  pstat = procstat_open_sysctl();
  }
  ~ProcStat()
  {
  procstat_close(pstat);
  }
  operator bool() const
  {
  return pstat;
  }
  
  struct procstat *pstat;
  };

Lines 37-42 become `ProcStat p; if (!p) return rc;`, but more importantly you 
can drop cleanup from other return paths since the destructor handles it.

> kprocesslist_unix_procstat.cpp:46
> +struct kinfo_proc *procs;
> +procs = procstat_getprocs(pstat, KERN_PROC_PROC, 0, _count);
> +

Similarly, you could

  struct ProcStatProcesses
  {
  public:
  ProcStatProcesses(ProcStat& pstat) : parent(pstat)
  {
  procs = procstat_getprocs(parent.pstat, KERN_PROC_PROC, 0, 
_count);
  }
  ~ProcStatProcesses()
  {
  if (procs)
  {
  procstat_freeprocs(parent.pstat, procs);
  }
  }
  operator bool() const
  {
  return procs && proc_count > 0;
  }
  
  ProcStat& parent;
  unsigned int proc_count;
  struct kinfo_proc *procs;
  }

I'd probably also write an iterator for it, returning KProcessInfo from 
`operator*()`, so that the magic is hidden away in small classes and the 
overall algorithm becomes a very short bit of text. You might call that 
over-engineered, since there's nothing wrong with the code as-written.

REPOSITORY
  R244 KCoreAddons

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

To: tcberner, #freebsd, adridg, davidedmundson
Cc: pino, apol, kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns

Maintainence status of Kooka?

[Adriaan de Groot]

Kooka had its last release in 2011, as a KDE3 application. However, master is 
a KF5-based application, with version number 0.90 in CMakeLists.txt. Is there 
any intention to do a release? (That's mostly a question for Jonathan) We 
revived it in FreeBSD packaging, calling current master 0.61.296 (from git 
describe), but it feels a little weird to ship packages of unreleased 
software.

[ade]

signature.asc
Description: This is a digitally signed message part.

D21305: Add the FreeBSD default-path for os-release.

[Adriaan de Groot]

adridg abandoned this revision.
adridg added a comment.


  Thanks for looking at this, Harald. For various downstream packaging reasons, 
we're going to be stuck with patching, so I'm going to give up on this 
particular patch.

REPOSITORY
  R244 KCoreAddons

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

To: adridg, sitter
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D21305: Add the FreeBSD default-path for os-release.

[Adriaan de Groot]

adridg edited the test plan for this revision.

REPOSITORY
  R244 KCoreAddons

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

To: adridg, sitter
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D21305: Add the FreeBSD default-path for os-release.

[Adriaan de Groot]

adridg edited the test plan for this revision.

REPOSITORY
  R244 KCoreAddons

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

To: adridg, sitter
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D21305: Add the FreeBSD default-path for os-release.

[Adriaan de Groot]

adridg created this revision.
adridg added a reviewer: sitter.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
adridg requested review of this revision.

REVISION SUMMARY
  - After much hemming and hawing we ended up with /usr/local/etc/os-release, 
which isn't one of the standard paths (according to freedesktop.org) so in 
spite of us **having** the file, not all software that looks for it will find 
it. Patch in the correct path.
  - Patching in the correct path in the original code inserted #ifdefs that 
interact really badly with the existing code-layout.
  - Switch to iterating over a constant list; with Clang and -O3 this yields 
slightly smaller code compared to the original. This code is also much easier 
to #ifdef for specific needs (e.g. for NetBSD and OpenBSD).

TEST PLAN
  - Included in downstream packaging.
  - Test for functionality: ```
  
  #include 
  #include 
  
  static void derp(const QString& s)
  {
  
qDebug() << s;

KOSRelease r(s);
qDebug() << "  name" << r.name() 
<< "\n  version" << r.version();
  
  }
  
  int main(int argc, char **argv)
  {
  
derp(QString());
derp("/usr/local/etc/os-release");

return 0;
  
  }
  
- Test for code size:
  
  
  #include 
  #include 
  
  QString defaultFilePath()
  {
  #ifdef ONE
  
if (QFile::exists(QStringLiteral("/etc/os-release"))) {
return QStringLiteral("/etc/os-release");
} else if (QFile::exists(QStringLiteral("/usr/lib/os-release"))) {
return QStringLiteral("/usr/lib/os-release");
} else {
return QString();
}
  
  #endif
  #ifdef TWO
  
for (const auto& path : { 
QStringLiteral("/etc/os-release"),
QStringLiteral("/usr/lib/os-release")
}) {
if (QFile::exists(path)) {
return path;
}
}
return QString();
  
  #endif
  }

REPOSITORY
  R244 KCoreAddons

BRANCH
  master

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

AFFECTED FILES
  src/lib/util/kosrelease.cpp

To: adridg, sitter
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D21245: KAr::openArchive: Also check ar_longnamesIndex is not < 0

[Adriaan de Groot]

adridg accepted this revision.
adridg added a comment.
This revision is now accepted and ready to land.


  ar_longnamesIndex is used as an array-index into ar_longnames, which is 
new[]ed, so a negative index is UB. This patch voids that case.

REPOSITORY
  R243 KArchive

BRANCH
  master

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

To: aacid, adridg
Cc: adridg, kde-frameworks-devel, michaelh, ngraham, bruns

D21146: KProcessInfoList -- add proclist backend for FreeBSD

[Adriaan de Groot]

adridg added inline comments.

INLINE COMMENTS

> kprocesslist_unix_proc.cpp:56
>  #else
> +#  ifdef Q_OS_FREEBSD
> +static const char formatC[] = "pid,state,user,command";

Are there situations where you would end up here? I mean, libprocstat is in 
base, since 9.0, so it is unlikely to be gone at any point.

> kprocesslist_unix_procstat.cpp:38
> +struct procstat *pstat;
> +pstat = procstat_open_sysctl();
> +

I absolutely have Opinions on C++ style that apply here, so I'm going to talk 
to Tobias elsewhere.

REPOSITORY
  R244 KCoreAddons

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

To: tcberner, #freebsd, adridg, davidedmundson
Cc: pino, apol, kde-frameworks-devel, michaelh, ngraham, bruns

Re: liquidshell in kdereview

[Adriaan de Groot]

On Saturday, 13 April 2019 14:08:18 CEST Martin Koller wrote:
> > # License issues
> > 
> > None, actually. Well done. Consistent use of GPLv3+ everywhere. You might
> > want to add SPDX identifiers, but that would be the icing on the cake.
> 
> Where, which and how would I need to add SPDX identifiers ?

You don't *need* to. Like I said, icing on the cake, which is like .. vanilla 
sauce on the apfelstruedel. Makes it complete and wonderful, but it's 
acceptable without it.

SPDX identifiers are machine-readable, standardised, tags in source files that 
help tooling that works with licensing (meta) data. See spdx.org; something 
like (off the top of my head, not necessarily the right identifier or format, 
etc.)

// SPDX-Identifier: GPLv2+

at the top of C++ source files does the trick.

> Where is this documented in KDE guidelines ?
> Here
> https://community.kde.org/Policies/Licensing_Policy
> I don't find anything.

It's not.

> > # Source issues
> > 
> > Doesn't report nicely at end of CMake (use FeatureSummary).
> 
> included now

Thanks.

> > # Compatibility issues
> > 
> > Fails to document that NetworkManager and BlueZ are required.
> 
> Not sure I understand.

Would have been nice to have that in the README, is what I mean.

> > Uses bash for things that are POSIX shell scripts.
> 
> What do you mean ?

You have a shell script (start_liquidshell). It uses no bash features at all. 
A POSIX system (ok, liquidshell is for Linux only, so this can be argued) has 
a /bin/sh for shell scripts.

> I did this since I remember having read that /bin/sh is not the correct way.

Fine by me.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Last minute GSoC proposal with Roks - anyone interested in mentoring?

[Adriaan de Groot]

On Saturday, 13 April 2019 23:36:43 CEST Valorie Zimmerman wrote:
> It's been a few days. Is anyone willing to step up to mentor this student?
> Tomaz cannot mentor two students, but he's willing to co-mentor. Without
> another mentor, we must turn this one down, rather than over-burden and
> possibly burn out Tomaz.
> 
> If you are interested in mentoring but have not yet been invited to the
> app, please write kde-soc-managem...@kde.org and tell us what
> google-connected email address you want us in use. Also, subscribe to
> KDE-Soc-Mentor mail list:
> https://mail.kde.org/mailman/listinfo/kde-soc-mentor.
> 
> Valorie
> 
> On Wed, Apr 10, 2019 at 3:27 PM Valorie Zimmerman <
> 
> valorie.zimmer...@gmail.com> wrote:
> > I need comments on this proposal in the app, so I know where we are. Is
> > anyone besides Tomaz willing to mentor this student? One mentor with two
> > students is burnout country, and we can't send anyone there!

I'll do it (somewhat hesitantly .. I do tend to vanish myself occasionally, so 
not sure I'll be there all the time. OTOH, I like graph theory, and my kids do 
too, so we'll have some good testers available).

My @kde address was used last year for GSoC, and I think I'm still subscribed.

[ade]

signature.asc
Description: This is a digitally signed message part.

Re: Symmy in kde-review

[Adriaan de Groot]

On Friday, April 12, 2019 10:13:10 AM CEST Jonathan Riddell wrote:
> On Sat, 25 Nov 2017 at 13:31, Elvis Angelaccio  
wrote:
> > symmy has been moved to kde-review for the usual review process.
> > 
> > It's a tiny frontend for the symmetric encryption functionality of GPG. It
> > doesn't handle signing or public/private keys, as we already have kgpg or
> > kleopatra for that.
> > 
> > Symmy can be useful if you have to send some sensitive file to someone, of
> > if you want to store it on some proprietary cloud service.

I should have piped up earlier:

# Compatibility

I wonder about Messages.sh. It claims to need bash, but I don't actually see 
any bash-ism in it. $() command substitution is POSIX-compatible.

I haven't looked at tooling to produce manpages from docbook, but good on you 
for including a manpage.

Compiled without meaningful warnings w/ clang 6 (which is often more picky 
than gcc).

# Licensing

You might want to add SPDX identifiers to files, but that's icing on the cake. 
Looks like a consistent GPLv2+ codebase, well-documented.

# Runtime

Since it's supposed to be a CLI application, you might want to massage the QPA 
loading a bit, since when I run it (ssh'ed in to my build machine) It does 
this:

[adridg@beastie ~/src/kde/symmy/build]$ ./src/symmy 
qt.qpa.xcb: could not connect to display 
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though 
it was found.
This application failed to start because no Qt platform plugin could be 
initialized. Reinstalling the application may fix this problem.

Available platform plugins are: wayland-org.kde.kwin.qpa, bsdfb, minimal, 
offscreen, vnc, xcb.

Abort trap (core dumped)



But overall: well done, welcome to extragear.

[ade]


signature.asc
Description: This is a digitally signed message part.

Re: liquidshell in kdereview

[Adriaan de Groot]

On Sunday, March 10, 2019 1:25:14 PM CEST Martin Koller wrote:
> since some time has already passed and there was no conclusion, I'll try
> once again to announce liquidshell.

# Documentation issues

The features list, both in German and English, lists a bunch of features that 
distinguish it from, say, twm, not from Plasma.

The feature list in English doesn't match the one in German. The English one 
includes dubious claims such as "instant startup" and "low memory footprint", 
which I'd still want to see measured and/or demonstrated.

Typo's in (English) README.

# License issues

None, actually. Well done. Consistent use of GPLv3+ everywhere. You might want 
to add SPDX identifiers, but that would be the icing on the cake.

# Source issues

Doesn't report nicely at end of CMake (use FeatureSummary).

Ancient CMake and Qt versions listed as "minimum" (that's ok, I guess).

Unusual source layout and file suffixes (again, I guess it's ok, just weird 
and being difficult).

Poor C++11 hygiene (include guards, conversions, nullptr).

# Compatibility issues

Fails to document that NetworkManager and BlueZ are required. 

Uses bash for things that are POSIX shell scripts.

Those (two items) above are symptoms of "liquidshell is a shell for Martin 
Koller and people with exactly his computer setup and workflow". Since the KDE 
community has traditionally produced general, flexible software, it's weird to 
have a restricted, limited, non-flexible product as well.

[ade]


signature.asc
Description: This is a digitally signed message part.

D20133: [UserMetaData] Untangle Windows, Linux/BSD/Mac and stub code.

[Adriaan de Groot]

adridg added a comment.


  I'd start to think about three separate files , unix_impl.cpp, 
windows_impl.cpp, stub_impl.cpp (although then you get API-syncing issues, 
probably, when only one of them is updated).

REPOSITORY
  R286 KFileMetaData

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

To: bruns, #baloo, #frameworks, #windows, #freebsd, ngraham, astippich
Cc: adridg, kde-frameworks-devel, gennad, domson, ashaposhnikov, michaelh, 
astippich, spoorun, ngraham, bruns, abrahams

D20007: Add GetProcessList for retrieving the list of currently active processes

[Adriaan de Groot]

adridg added a comment.


  On FreeBSD, `/proc` is not necessarily mounted (it might be a Linuxism). So 
while I do **have** `/proc`, it's empty because procfs isn't mounted there. If 
I **do** mount it, then there's the expected list of processes and a curproc 
symlink. But `/proc/` doesn't contain  a `stat` file .. there's a 
`status`, though. Let me mess around a bit with that... yes, changing to 
`status` makes all 6 tests pass. So I'd suggest something like
  
#ifdef Q_OS_FREEBSD
  QString statusFileName(QStringLiteral("/status"));
#else
  QString statusFileName(QStringLiteral("/stat"));
#endif
  
  and then later on
  
filename += statusFileName;

REPOSITORY
  R244 KCoreAddons

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

To: hallas, davidedmundson, broulik
Cc: vonreth, adridg, elvisangelaccio, kde-frameworks-devel, michaelh, ngraham, 
bruns

D20007: Add GetProcessList for retrieving the list of currently active processes

[Adriaan de Groot]

adridg added a comment.


  Config: Using QtTest library 5.12.1, Qt 5.12.1 (x86_64-little_endian-lp64 
shared (dynamic) release build; by Clang 6.0.1 (tags/RELEASE_601/final 335540))
  PASS   : KProcessListTest::initTestCase()
  
PASS   : KProcessListTest::testKProcessInfoConstructionAssignment()
FAIL!  : KProcessListTest::testProcessInfoList() 'processInfoList.empty() 
== false' returned FALSE. ()
   Loc: 
[/home/adridg/src/kde/tier-1/kcoreaddons/autotests/kprocesslisttest.cpp(89)]
FAIL!  : KProcessListTest::testProcessInfo() 'processInfo.isValid() == 
true' returned FALSE. ()
   Loc: 
[/home/adridg/src/kde/tier-1/kcoreaddons/autotests/kprocesslisttest.cpp(108)]
PASS   : KProcessListTest::testProcessInfoNotFound()
PASS   : KProcessListTest::cleanupTestCase()
Totals: 4 passed, 2 failed, 0 skipped, 0 blacklisted, 1ms
  
  I'll chase this for 34 minutes now (until 2pm)

REPOSITORY
  R244 KCoreAddons

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

To: hallas, davidedmundson, broulik
Cc: vonreth, adridg, elvisangelaccio, kde-frameworks-devel, michaelh, ngraham, 
bruns

D17071: Don't include any directory sizes in DirectorySizeJob

[Adriaan de Groot]

adridg added a comment.


  With UFS, stat(1) tells me
  
[adridg@beastie .../kio/build]$ stat .
2080587972 222556 drwxr-xr-x 9 adridg adridg 4294967295 17 "Nov 22 14:40:28 
2018" "Nov 22 14:42:22 2018" "Nov 22 14:42:22 2018" "Nov 22 14:39:51 2018" 
131072 17 0x800 .
  
  So that's a size of 17 -- on UFS that looks like the count of the files in 
the directory (I added a file and then size is 18).
  
  Without this patch: jobtest has 71 tests, all pass.
  With this patch: jobtest has 71 tests, all pass.
  
  (Note that I ran the test against Frameworks 5.51, since I don't have 5.52 
installed yet)

REPOSITORY
  R241 KIO

BRANCH
  master

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

To: davidedmundson, dfaure, apol
Cc: adridg, apol, kde-frameworks-devel, michaelh, ngraham, bruns

D17070: Don't double-count size of directories in DirectorySizeJob

[Adriaan de Groot]

adridg added a comment.


  With UFS, stat(1) tells me
  
[adridg@beastie .../kio/build]$ stat .
2080587972 222556 drwxr-xr-x 9 adridg adridg 4294967295 17 "Nov 22 14:40:28 
2018" "Nov 22 14:42:22 2018" "Nov 22 14:42:22 2018" "Nov 22 14:39:51 2018" 
131072 17 0x800 .
  
  So that's a size of 17 -- on UFS that looks like the count of the files in 
the directory (I added a file and then size is 18).
  
  Without this patch: jobtest has 71 tests, all pass.
  With this patch: jobtest has 71 tests, 1 fails.
  
QDEBUG : JobTest::directorySize() totalSize:  50
QDEBUG : JobTest::directorySize() totalFiles:  7
QDEBUG : JobTest::directorySize() totalSubdirs:  4
FAIL!  : JobTest::directorySize() 'job->totalSize() >= 60' returned FALSE. 
(totalSize was 50)
   Loc: [/home/adridg/src/kde/tier-3/kio/autotests/jobtest.cpp(1099)]
  
  With this patch, and D17071  as well, the 
failure is the same: 71 tests, 1 fails, same case and failure message.
  
  (Note that I ran the test against Frameworks 5.51, since I don't have 5.52 
installed yet)

REPOSITORY
  R241 KIO

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

To: davidedmundson, dfaure
Cc: adridg, kde-frameworks-devel, michaelh, ngraham, bruns

D15072: [server] Abort drag start on correct conditions and without posting error

[Adriaan de Groot]

adridg added inline comments.

INLINE COMMENTS

> adridg wrote in datadevice_interface.cpp:103
> this looks like it's still missing a !, based on the explanation "when the 
> client does not have an implicit pointer grab"

I need new glasses :)

REPOSITORY
  R127 KWayland

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

To: romangg, #kwin
Cc: adridg, kde-frameworks-devel, michaelh, ngraham, bruns

D15072: [server] Abort drag start on correct conditions and without posting error

[Adriaan de Groot]

adridg added inline comments.

INLINE COMMENTS

> datadevice_interface.cpp:103
>  // TODO: allow touch
> -if (seat->hasImplicitPointerGrab(serial) && 
> seat->focusedPointerSurface() != origin) {
> -wl_resource_post_error(resource, 0, "Surface doesn't have pointer 
> grab");
> +if (!seat->hasImplicitPointerGrab(serial) || 
> seat->focusedPointerSurface() != origin) {
> +// Surface doesn't have pointer grab.

this looks like it's still missing a !, based on the explanation "when the 
client does not have an implicit pointer grab"

REPOSITORY
  R127 KWayland

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

To: romangg, #kwin
Cc: adridg, kde-frameworks-devel, michaelh, ngraham, bruns

D14927: KConfig: handle directory symlinks correctly.

[Adriaan de Groot]

adridg added a comment.


  Sorry, this is getting very confusing:
  
  - when running all tests, unpatched: testDelete and testThreads fail
  - when running all tests, patched: testDefaults fails
  
  I suspect there are some more missing canonicalizations, but I don't have 
time right now to go hunting them.

REPOSITORY
  R237 KConfig

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

To: dfaure, adridg, arichardson
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D14927: KConfig: handle directory symlinks correctly.

[Adriaan de Groot]

adridg added a comment.


  Without patch, all tests
  
  
  Totals: 44 passed, 2 failed, 0 skipped, 0 blacklisted, 225ms
  
  The two failed tests are:
  
  - testThreads
  - testDelete
  
  With patch, all tests
  =
  
  Totals: 45 passed, 1 failed, 0 skipped, 0 blacklisted, 229ms
  
  The one failed test is:
  
  - testDefaults
  
  Without patch, some tests
  =
  
  Some tests means run `HOME=/tmp/drop bin/kconfigtest testDelete  testThreads  
testDefaults`
  
* Start testing of KConfigTest *
Config: Using QtTest library 5.10.1, Qt 5.10.1 (x86_64-little_endian-lp64 
shared (dynamic) release build; by Clang 5.0.0 (tags/RELEASE_500/final 312559))
PASS   : KConfigTest::initTestCase()
FAIL!  : KConfigTest::testDelete() '!delgr.exists()' returned FALSE. ()
   Loc: [/home/adridg/src/kde/tier-1/kconfig/autotests/kconfigtest.cpp(802)]
PASS   : KConfigTest::testThreads()
FAIL!  : KConfigTest::testDefaults() Compared values are not the same
   Actual   (group.readEntry("entry1", QString())): "hello"
   Expected (Default) : "Default"
   Loc: [/home/adridg/src/kde/tier-1/kconfig/autotests/kconfigtest.cpp(399)]
PASS   : KConfigTest::cleanupTestCase()
  
  
  
  Without patch, some tests
  =
  
* Start testing of KConfigTest *
Config: Using QtTest library 5.10.1, Qt 5.10.1 (x86_64-little_endian-lp64 
shared (dynamic) release build; by Clang 5.0.0 (tags/RELEASE_500/final 312559))
PASS   : KConfigTest::initTestCase()
PASS   : KConfigTest::testDelete()
FAIL!  : KConfigTest::testThreads() Compared values are not the same
   Actual   (group.readEntry("entry1", QString())): "hello"
   Expected (Default) : "Default"
   Loc: [/zbigone/src/kde/tier-1/kconfig/autotests/kconfigtest.cpp(399)]
PASS   : KConfigTest::testDefaults()
PASS   : KConfigTest::cleanupTestCase()
Totals: 4 passed, 1 failed, 0 skipped, 0 blacklisted, 41ms
* Finished testing of KConfigTest *

REPOSITORY
  R237 KConfig

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

To: dfaure, adridg, arichardson
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D14927: KConfig: handle directory symlinks correctly.

[Adriaan de Groot]

adridg added a comment.


  This shows up in the unit tests. Whether it has any effect in real life is 
unknown. FreeBSD often -- sometimes, maybe, depending on FS setup and layout -- 
has /home -> /usr/home or /home -> usr/home, and of course there could be weird 
user setups as well where .cache is symlinked to a different location with more 
disk space. In any case, this is triggering unit-test failures in the CI, so 
cleaning it up to consistently compare the same kind of filename is a good 
thing. I'll give this a test on my home system and give a shout when I have.

REPOSITORY
  R237 KConfig

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

To: dfaure, adridg, arichardson
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

Re: ktextwidgets on FreeBSD

[Adriaan de Groot]

On Saturday, 4 August 2018 13:06:42 CEST David Faure wrote:
> Anyone running FreeBSD, who could to try and debug this hanging unittest
> from the ktextwidgets framework?
> 
> https://build.kde.org/view/Frameworks/job/Frameworks%20ktextwidgets%20kf5-qt
> 5%20FreeBSDQt5.10/9/testReport/junit/(root)/TestSuite/ktextwidgets_krichtext
> edittest/
> 
> There's no waiting of any kind in the code, it's straight QTextDocument
> usage, this shouldn't deadlock or anything. Yet it times out (after 30
> seconds!!) quite often in CI.

I just built master -- after changing the CMakeLists.txt to accept Frameworks 
5.46 which I have on my live desktop -- and ran the tests twice with "make 
test".

Start 1: ktextwidgets-kfindtest
1/5 Test #1: ktextwidgets-kfindtest    Passed0.45 sec
Start 2: ktextwidgets-kreplacetest
2/5 Test #2: ktextwidgets-kreplacetest .   Passed0.60 sec
Start 3: ktextwidgets-krichtextedittest
3/5 Test #3: ktextwidgets-krichtextedittest    Passed0.56 sec
Start 4: ktextwidgets-ktextedit_unittest
4/5 Test #4: ktextwidgets-ktextedit_unittest ...   Passed0.51 sec
Start 5: ktextwidgets-kpluralhandlingspinboxtest
5/5 Test #5: ktextwidgets-kpluralhandlingspinboxtest ...   Passed0.45 sec


Start 1: ktextwidgets-kfindtest
1/5 Test #1: ktextwidgets-kfindtest    Passed1.03 sec
Start 2: ktextwidgets-kreplacetest
2/5 Test #2: ktextwidgets-kreplacetest .   Passed7.48 sec
Start 3: ktextwidgets-krichtextedittest
3/5 Test #3: ktextwidgets-krichtextedittest    Passed0.84 sec
Start 4: ktextwidgets-ktextedit_unittest
4/5 Test #4: ktextwidgets-ktextedit_unittest ...   Passed1.82 sec
Start 5: ktextwidgets-kpluralhandlingspinboxtest
5/5 Test #5: ktextwidgets-kpluralhandlingspinboxtest ...   Passed1.00 sec


This was on a fairly loaded system (parallel building packages at the same 
time) but you can see the time taken for the test is quite large. A third run 
even used 20.75 wall-clock seconds.

During the kreplacetest, I can see a window popping up, and then going away, 
multiple times. It's weird. But the third test does seem to run successfully 
here -- I'll have to dig into how the CI runs the tests, exactly.

[ade]



signature.asc
Description: This is a digitally signed message part.

D13752: Kill solidautoeject

[Adriaan de Groot]

adridg added a comment.


  - Start systemsettings; under *workspace*, *startup and shutdown*, find 
*background services*.
  - Untick the box for *Drive Ejector*; also check status is *not running*, 
click *stop* button if it is still running.
  - Insert CD, pick *open in file manager* from the device notifier popup
  - Check that it's mounted, from a konsole
  - Press button on CD drive: no result
  - Choose eject from device notifier:  CD is ejected

REPOSITORY
  R120 Plasma Workspace

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

To: broulik, #plasma, #frameworks, adridg, davidedmundson, dfaure, fvogt, ervin
Cc: anthonyfieroni, mart, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol

D13752: Kill solidautoeject

[Adriaan de Groot]

adridg added a comment.


  It's not clear to me what this revision is trying to change (in terms of 
user-visible behavior) or how to test the change; what I've written above is 
current behavior on FreeBSD 11 with Plasma 5.12.5; HAL is running.

REPOSITORY
  R120 Plasma Workspace

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

To: broulik, #plasma, #frameworks, adridg, davidedmundson, dfaure, fvogt, ervin
Cc: mart, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol