Re: playground/games/picmi moved to KDE Review

[Adriaan de Groot]

On Saturday, July 21, 2012 10:48:47 AM Jakob Gruber wrote:
 One other question: three of the included levels are small pictograms of
 Disney characters up to 31x32 px in size. I'm not sure if that could be
 a legal issue?

I'd suggest being on the safe side and dropping those: the characters 
(likenesses) are trademarks and their images copyrightable; depending on how 
you get the small pix the copyright might not apply, but trademark still 
would. 

[ade]

Re: Kdelibs Coding Style vs. preparations for Qt5

[Adriaan de Groot]

On Saturday, December 29, 2012 04:25:54 PM Albert Astals Cid wrote:
 Would there be any chance to have the style check done by a pre-commit hook?
 Or at least have a command-line tool that checks it for me?

Wouldn't that typically be a Krazy thing to check (and you can run Krazy 
checks from the command-line)? It'd be post-hoc, but at least the style issues 
can then be dealt with by those folks who run around fixing up Krazy things.

[ade]

Re: Moving Baloo forward

[Adriaan de Groot]

On Friday 17 January 2014 01:47:17 Albert Astals Cid wrote:
 Thus my suggestion is that after we get the wiki done and we explain
 clearly  the situation as Thomas Lübking suggested (i.e. if you really
 really really really need what Nepomuk provides and can't accept a single
 regression in that field, do not upgrade), we go ahead with moving to Baloo
 instead of Nepomuk.

I'm concerned about the portability aspect of Baloo. It seems to rely heavily 
on certain API (fgetxattr) while not testing for the availability of that API.

From a let's see if this stuff can build perspective it'd be nice if it gave 
a (better) hint about missing xapian, along the lines of what most KDE modules 
do when a required dependency is missing (is that 
macro_log_optional_feature?). 

Some files still have the boilerplate one line to give ... in the copyright 
header, too.

[ade]

Re: KDiagram libs (KChart, KGantt) in KDE Review

[Adriaan de Groot]

On Monday 09 February 2015 01:50:03 Friedrich W. H. Kossebau wrote:
 Yes, nearly copypaste: the copies of KDChart in Calligra  KMyMoney are
 older  (2.4.1, based on Qt4) versions, while the copy of KDChart in
 Massif-Visualizer matches the version of the KChart lib in KDiagram.

I've tried compiling the code on FreeBSD 10.1-RELEASE with Clang 3.4.1 (I'm 
assuming that's a supported compiler -- on techbase, searching for supported 
compiler doesn't give me much compatibility information newer than KDE 4.2).

 - I need to add /usr/local/include to the include search path; this is not 
kdiagram specific, but seems to be a general Qt5 issue on FreeBSD.
 
 - TestDrawIntoPainter seems to hang; after 2 min at 100% CPU I killed it. I 
ran it separately by hand and get output about missing OpenGL drivers (which 
is true, I'm building kdiagram in a restricted environment; I didn't 
originally expect to need to have DBUS running to be able to do the tests 
either) and debug output like:
QDEBUG : TestDrawIntoPainter::testTest() Time for drawing pixmap :/test: 
53682 ms
  Is that test supposed to take so much longer (minutes) than the other tests 
(deciseconds)?

So from a it-compiles-and-the-tests-pass point of view on my platform, it 
looks good.

[ade]

Re: Adding further modules to api.kde.org

[Adriaan de Groot]

On Thursday 10 September 2015 06:07:40 Jeremy Whiting wrote:
> It would be awesome to have what used to be in KDE SC on api.kde.org
> again. We have many libraries that aren't frameworks that are Qt5/KF5
> based which would be good to show on there imo.

Perhaps half of this is figuring out what actually constitutes the "Workspace 
API" that would be interesting here and how to subsequently pull information 
out of the metadata-services that we have (src-build? projects.kde.org? I 
don't know, I haven't followed very closely what lives where now).



[ade] (who is now reminded that the original ebn domain is expiring and needs 
renewal, yeah)

Re: Policy regarding QtWebKit and QtScript

[Adriaan de Groot]

On Wednesday 30 December 2015 01:34:46 Vadim Zhukov wrote:
> There is a little chance QtWebEngine will be ported on OpenBSD: if
> someone will come in and fix Chromium and QtWebEngine to bundle less,
> at least. I won't volunteer: handling a few hundreds of KDE ports +
> ports of Qt itself is already big enough task for me.
> 
> So, again, it was my seeing, both for today and tomorrow. Now I'm back
> to porting other KDE5 stuff. Thank you for reading!

Thank you, Vadim. I spent an hour or two on qtwebengine today. I got the 
feeling that the motto is "y0 dawg, i hear you like build systems so i put a 
buildsystyem in your buildsystem so you can buildsystem while you 
buildsystem". It is a frustrating experience.

I'm trying hard to not make this sound like whining, really.

 - Why am I building ninja when it's already packaged externally?
 - Why am I building yasm?
 - Same applies to most of the bundled stuff. A lot of the FreeBSD patches for 
Chromium itself are, indeed, unbundlings. But those need to be re-done for 
webengine, because who knows how the versions differ.
 - The qmake and gyp (horse pucky!) are strongly tied into linux/mac/boot2qt, 
so finding all the bits and pieces that need adjusting is tricky.
 - Example, I thought I had bunged freebsd-clang into the system properly, but 
gyp is still trying to discover the assembler version by calling gcc.
 - Example from qt3d (so external to this discussion), using a broken OffsetOf 
in a bundled third party library.

This sounds like a case where the unbundling OSsen -- OpenBSD, FreeBSD, 
probably some of the Linuxen -- can and should get together to help make more 
of Qt 5.6 a truly cross-platform development environment. (Randa?)

[ade]

Re: Policy regarding QtWebKit and QtScript

[Adriaan de Groot]

Kevin, first off thank you for responding so carefully to Vadim and to me. It 
does make a difference to porting efforts.

On Wednesday 06 January 2016 18:11:25 Kevin Kofler wrote:
> unbundling doesn't seem to be the main focus. And the reason there are so
> many patches is because they produced a different patch for EVERY SINGLE
> source file they modified! (That, and the fact that they're only named after
> the source files and not after the modifications actually done, also makes
> it really hard to decide at a glance what those patches really do. IMHO,
> this is an example of how NOT to manage downstream patches.)

Yeah. I find that a terrible confusing policy in FreeBSD ports too. But that's 
not my department, I'm afraid.

[ade]

Re: Policy regarding QtWebKit and QtScript

[Adriaan de Groot]

On Friday 25 December 2015 12:42:26 you wrote:
> On Donnerstag, 24. Dezember 2015 12:14:06 CET Adriaan de Groot wrote:
> > On Tuesday 22 December 2015 16:07:06 Lisandro Damián Nicanor Pérez Meyer
> > 
> > wrote:
> > > > The idea that users may have remainders of QtWebKit 5.5 on their disk
> > > > (or
> > > > not and thus unresolvable linkage) and install Qt 5.6 and still have
> > > > (not
> > > > recompiled) client code that is now gonna crash scares me a bit - it
> > > > doesn't really improve reputation. Distros will virtually *have* to
> > > > provide
> > > > downstream webkit solutions to cover 3rd party installs and we'll get
> > > > "somthing broke" reports on this all over the place.
> > > 
> > > What we distro packagers are going to do is to recompile QtWebkit for as
> > > long  ans possible/necessary.
> > 
> > If I recall correctly, the FreeBSD guys say that QtWebEngine (is that what
> > the new thing is called) is an absolute terror to get building in FreeBSD.
> > There are apparently source-compatibility issues and it takes a great big
> > stonkin' machine to compile it at all.
> 
> Sorry, but how is "it takes long to compile" and argument for or against a
> piece of software if there is no feature equivalent alternative that takes
> less time to compile?

Please don't focus on *one* single part of what I explicitly indicated was at-
that-time-hearsay. Since then I've actually tried to compile Qt 5.6 beta.
 
> Qt WebEngine is far easier to compile than Qt WebKit in my experience, and
> it certainly doesn't take significantly longer. And of course the former is
> far superior than the latter.

This bit makes it harder:

./tools/qmake/mkspecs/features/functions.prf:skipBuild("Qt WebEngine can 
currently only be built for Linux (GCC/clang), Windows (MSVC 2013 or 2015), OS 
X (10.9/XCode 5.1+) or Qt for Device Creation.")

So from the FreeBSD packagers' side, it *is* a big deal, because they not only 
have to get KDE software to work (which has traditionally been very cross-
platform, and is easy to work with), and Qt to work (which has traditionally 
been very cross-platform, and is generally easy to work with), but also deal 
with 975MB of Chromium. That is, as they say, quite a lump of coal in the 
stocking.

[ade]

Re: Policy regarding QtWebKit and QtScript

[Adriaan de Groot]

On Friday 25 December 2015 13:34:01 Allan Sandfeld Jensen wrote:
> Does Chromium build on FreeBSD already? In know in QtWebEngine we have
> several  qmake conditions that would need to be changed from linux to
> posix:!mac, but I haven't tried because I wasn't sure if FreeBSD was even
> support by Chromium.

There is a chromium port. I took a look at it, there's 380 patches that it 
applies. I don't know how much of that is related to the application or how 
much applies to the underlying engine. I have no idea if the application works 
(well). I'll kick off a build just before I leave for Xmas dinner.

[ade]

Re: Policy regarding QtWebKit and QtScript

[Adriaan de Groot]

On Tuesday 22 December 2015 16:07:06 Lisandro Damián Nicanor Pérez Meyer 
wrote:
> > The idea that users may have remainders of QtWebKit 5.5 on their disk (or
> > not and thus unresolvable linkage) and install Qt 5.6 and still have (not
> > recompiled) client code that is now gonna crash scares me a bit - it
> > doesn't really improve reputation. Distros will virtually *have* to
> > provide
> > downstream webkit solutions to cover 3rd party installs and we'll get
> > "somthing broke" reports on this all over the place.
> 
> What we distro packagers are going to do is to recompile QtWebkit for as
> long  ans possible/necessary.

If I recall correctly, the FreeBSD guys say that QtWebEngine (is that what the 
new thing is called) is an absolute terror to get building in FreeBSD. There 
are apparently source-compatibility issues and it takes a great big stonkin' 
machine to compile it at all.

But .. I haven't tried it myself. I probably should so I can replace the 
'apparently's above with 'defiitely'.

[ade]

Re: CI Requirements - Lessons Not Learnt?

[Adriaan de Groot]

On Monday, January 16, 2017 05:32:12 PM Eike Hein wrote:
> I'll be working up a new draft today taking some of the comments
> so far into account, and giving sysadmin the latitude to remove
> projects from CI at their decision if the guidelines are violated
> and maintaining a project on CI becomes unreasonable. This limits
> scope of enforcement (i.e. the consequences for falling out of
> line) to participation in CI instead of the community, which
> seems more pragmatic in hindsight.

Thanks, Eike. It's good to have a slightly more relaxed attitude towards the 
procedures. On the other hand, I think that the way the discussion wandered 
all over the distributions and #ifdefs map has obscured an important question: 
how important is CI to us (as a whole)?

In this thread, various people have mentioned that the CI is important. It's 
one of the big consumers of KDE source (besides developers and distro 
packagers; the distro packagers are on a different schedule and can probably be 
ignored for now).

But CI has a really important function: it shows us the health of the sources 
for everything; and that's something the release team needs, and the whole 
community can be interested in. So "opting out" of CI deprives us of a good 
view of the state of our software products.

[ade]

Re: Test your applications on Wayland

[Adriaan de Groot]

On Thursday, October 13, 2016 01:12:27 PM Martin Graesslin wrote:
> Just an example of an issue I run into today:
> https://git.reviewboard.kde.org/ r/129171/
> 
> Application just crashed on startup due to a missing nullptr check exposed
> by a different windowing systems.

 
This intrigued me, so I went looking at the Qt docs 
(e.g.http://doc.qt.io/qt-5/qguiapplication.html#clipboard)  to see if they 
said anything about the returned pointers:

===
QClipboard *QGuiApplication::clipboard()

Returns the object for interacting with the clipboard.
===
const QMimeData *QClipboard::mimeData(Mode mode = Clipboard) const

Returns a reference to a QMimeData representation of the current clipboard 
data.
===

Neither function's documentation says it can return a nullptr; neither says it 
can't. But what really surprises me in the documentation is the use of the 
words "object" and "reference" here. Since that's not what those functions are 
returning, and certainly the use of the word "reference" suggests to me (when 
somewhat-wrongly applied to a pointer) "can't be null".

So to a very limited extent we can claim it's the documentation's fault.

[ade]

Re: CI Requirements - Lessons Not Learnt?

[Adriaan de Groot]

On Friday, January 13, 2017 09:35:51 PM Eike Hein wrote:
> Quick follow-up notes: I improved the formatting a little more,
> please refresh if you were reading already - now waiting for
> comments, though.

I like it in general, although near the end I think I would prefer to have (c) 
maintainer is in control moved to (a). It's also a pretty heavy policy (in the 
sense of, having read it, going "whooo, have we really got to have this much 
bureaucracy?"), so that it'd be nice to have a light-weight, happy TL;DR 
version as well. Something that I'd formulate as follows:

"When you (are going to) bump an external dependency, drop a note to sysadmin@ 
and the CI group and distributions@ as well, so that many of the consumers of 
your code know what's going on and can adjust their tooling, base systems or 
packaging to suit."

(though perhaps that glosses over potential problems *too* much)

[ade]

Re: CI Requirements - Lessons Not Learnt?

[Adriaan de Groot]

I think there's a middle ground to be found between dog-piling on Martin and 
letting things slide; a middle ground between dependency-creep and sticking to 
a stale platform. So let's step back for a moment and ask "what went wrong?" 
(and try to answer that carefully!), "what is the impact?" and "how can we do 
our best to prevent this next time?" or "how can we do better?".

Probably the wording "went wrong" itself is wrong, because of the emotional 
load carried by wrong-doing.

Anyway, I'll carry on while wearing three hats: as a casual KDE contributor, 
as a casual CI contributor, and as a packager of KDE. Any "we" below 
ambiguously refers to one of those three roles or communities.

The software (code) we produce is consumed by a bunch of different parties as 
source code. The core developers are up to their elbows in it every day. Other 
contributors use the source casually. But there are also automated consumers 
of the source-code, and they're a lot less smart than the people: the CI 
systems which try to build stuff all the time (and developers, we do hope that 
you see there's a value in that). And packaging systems, which thrive on 
"here's a new version, do the same as with the last version" and don't like 
radical changes.

What constitutes a radical change is something that's up for discussion: I was 
recently annoyed by KDE software that shipped a tar.bz2 instead of a tar.xz .. 
not because that's difficult to deal with, but because it's an annoying and 
unnecessary bump in my packaging workflow.

Martin seems to find this thread an annoying and unnecessary bump in *his* 
development workflow, which I can understand too. I simply won't presume bad 
faith on his part, .. possibly a lack of regard for some of the consumers of 
the source, but he has a good reason, and I'll back him in making that choice.

> >> > On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin wrote:
> >> >> It should be rather obvious that we don't introduce new dependencies
> >> >> because we like to. There is a very important software reason to it.

At the same time, that choice right now is causing a problem (for one 
automated consumer of the source) and may cause a problem, or surprise and 
annoy, a bunch of other consumers of the source.

Can we agree that that's a reasonable answer to "what went wrong?": "A 
dependency was unexpectedly introduced / updated."

Note I'm trying to phrase this abstractly: that's because we have a concrete 
instance here, but it's an example of something that happens all the time 
(what's that you say about libinput? or KDE applications being released with 
dependencies on totally unreleased software that needs to be picked up from 
random GitHub commits). So please separate concrete-instance with general-
case.

So what's the impact?

Twofold: for CI it causes failing builds. We should consider that red-flag 
property of CI to be a *good* thing -- because it indicates something changed 
in our assumptions or in the code, and the source is no longer good (green), 
for some suitable definition of "good".

And for distro's, there's an upcoming problem, as indicated by Kevin Kofler. 
I'd flag the same thing: it's unpleasant when packaging  turns into 
packaging , ,  .. because of dependencies the packagers didn't 
know about beforehand. 

On Thursday 05 January 2017 21:49:52 Martin Gräßlin wrote:
> .. I think that this dependency is way more important to overall
> KWin than a few people having to manually build xkbcommon. Which is
> fairly trivial as David showed in his reply to the thread ..

The impact is mostly because the automated systems don't know all that much 
about dependency bumps, and also really aren't ready for manually-building-
stuff. As Martin has pointed out, there *is* now a release to build against, so 
this concrete case is not in the realm of random-GitHub-commit.

It is, however, a burden to CI and packagers. CI -- or rather the people 
behind CI, which I guess are largely Ben and Scarlett -- does its darnedest to 
give us an accurate picture of the state of KDE software. Packagers are the 
people who get the software in the hands of users.

My packaging and CI hats say "hey, don't bump dependencies, because it gets in 
the way of my workflow." My developer hat says "I don't want to be beholden to 
your idea of what the software stack is."

I claim that's not unreasonable for either hat to say. Furthermore, I claim 
that that's a source of conflict, and that we should subsequently work on 
resolving that conflict, or finding a mechanism for coping.

In other words, let's try to do better in future.

Martin has identified a problem with the CMake output (on CI, but this applies 
generally). It says that a versioned dependency is not satisfied, but doesn't 
say what version is available. Having that knowledge -- what's there -- makes 
it easier to explain why the bump is needed.

CI and packagers have identified a problem with the bump itself: they didn't 
know 

Re: Latte Dock in review phase

[Adriaan de Groot]

On Friday, 6 October 2017 09:47:26 CEST Jonathan Riddell wrote:
> Looks good from a brief look around I did from a packagers point of
> view (so not looking at the code).

The licensing is a funky (not bad, just .. unusual) mix of LGPL v2+ and GPL 
v2+; for instance app/ contains 7 files licensed  LGPL v2+, the rest looks like 
GPL v2+.

The code doesn't compile with clang. extras.h contains a definition of 
make_unique() for old GLIBCXX. That doesn't seem consistent with the required 
C++ version, C++14. The check is also wrong for clang / libstc++ , since it 
probably doesn't define __GLIBCXX__ at all. That definition should probably 
just 
be removed.

visibilitymanager_p.h is missing  as an include -- probably g++ 
#includes it via some round-about path, but clang / libstdc++ doesn't.

[ade]

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

Re: Latte : make_unique for gcc <=4.8

[Adriaan de Groot]

On Thursday, 9 November 2017 09:58:26 CET Tomaz Canabrava wrote:
> On Sun, Nov 5, 2017 at 4:12 PM, Michail Vourlakos 
> 
> > during the review phase in Latte we removed the following code in case it
> > would conflict in some cases:
> > 
> > #if __GLIBCXX__ <= 20150623
> > namespace std {
> > template
> > unique_ptr make_unique(Args &&... args)
..
> > #endif
> > 
> > 
> > this was needed for gcc versions that even though they are C++14
> > compatible they dont offer make_unique function. By removing that code we
> > broke compatibility with openSUSE Leap that uses gcc 4.8.5 ... so in order
> > to build latte packages a made a patch to readd that code.

The problem was at least partly (IIRC) that the check doesn't detect Clang, 
and then defines a duplicate (language-lawyering says it's undefined behavior). 
The problem isn't so much with gcc itself, as with the C++ STL version it 
ships with.

I wanted to point you to https://cmake.org/cmake/help/v3.8/prop_gbl/
CMAKE_CXX_KNOWN_FEATURES.html , but has-make-unique is not one other features 
CMake knows about.

As Sven points out, using symbol_exists() might work, or easier might be a 
try_compile() which will definitely tell you if std::make_unique compiles on 
the local system.

[ade]

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

Re: Importing kdiff3 - was - Re: Aw: Re: KDE inclusion

[Adriaan de Groot]

On Wednesday, January 24, 2018 6:08:03 PM EST Albert Astals Cid wrote:
> El dimecres, 24 de gener de 2018, a les 17:34:16 CET, Kevin Funk va 
escriure:
> > On Wednesday, 24 January 2018 16:24:10 CET Michael Reeves wrote:
> > > A little confused on where to start with this sponsor thing.
> > 
> > Huh? 'sponsor thing'? :)
> 
> I guess it's regarding the
> https://community.kde.org/Incubator/Incubation_Process
> 
> Which to my understanding was supposed to be a voluntary thing but it seems
> some people are forcing it on every single new project.

The amounts of "must" and "can't" on the page make it seem very non-voluntary. 
And like Kevin and Kevin, I have thought that this was *not* voluntary.

Same time, the states can be described as "provides absolutely minimal 
information needed to be a project", "communicates well with one person, the 
sponsor", "participates in the KDE community", "dead". Those are not a lot of 
bureaucracy (well, there is mention of a "committee", which I don't see 
defined anywhere).

The role of the sponsor described in the process is quite an active one: 
there's a number of steps to be taken, and communication to be handled. 
Probably not more than a few hours across several weeks, but it needs watching 
over.

[ade]

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

Re: Falkon in kdereview

[Adriaan de Groot]

On Wednesday, February 28, 2018 6:10:36 AM EST David Rosca wrote:
> There are also some autotests, although they are rather unstable on
> FreeBSD build. It looks like crash in QtWebEngine, but the backtrace
> from CI is without symbols, so it is unfortunately useless.

The KDE-FreeBSD developers are generally happy with *using* Qupzilla / Falkon 
though -- it's the autotests that fall over, not the browser itself. Something 
we'll have to look at by hand. Don't let it be a blocker.

That said, the FreeBSD CI VMs should have debug symbols, so we'll have to look 
at that since -- as you notice -- it makes the CI less useful for application 
developers.

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

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.

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.

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]

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

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: 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: 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]

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]

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

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

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