Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches

[Volker Krause]

On Mittwoch, 7. Februar 2024 19:48:27 CET Friedrich W. H. Kossebau wrote:
> Am Sonntag, 4. Februar 2024, 19:22:28 CET schrieb Ben Cooksley:
> > On Mon, Feb 5, 2024 at 4:28 AM Friedrich W. H. Kossebau 
> > 
> > wrote:
> > > Hi,
> > > 
> > > ((cc:kde-frameworks-devel for heads-up, replies please only to
> > > kde-core-deve))
> > > 
> > > I hit the problem that when working on a repo which would like to use
> > > latest
> > > KF development state to integrate some new KF API just added in
> > > cooperation
> > > with that very repo wanting to use it, I cannot do so when someone had
> > > added a
> > > flatpak job on CI to that repo.
> > > 
> > > Because with such flatpak jobs it seems they are limiting the available
> > > KF
> > > version not to the current latest one, as expected for continuous
> > > integration,
> > > 
> > > but some older (anywhere documented?) snapshot:
> > > "runtime-version": "6.6-kf6preview",
> > 
> > Please see https://invent.kde.org/packaging/flatpak-kde-runtime/-/tree/kf6
> > for what is in the KF6 preview.
> 
> Thanks. So documented by implementation :)
> 
> > > What can be done here to reestablish the old immediate continuous
> > > integration
> > > workflow? Where new APIs (also from KF) are instantly available?
> > 
> > With Flatpak new APIs were never instantly available - there has always
> > been a delay as the Flatpak Runtime uses the most recent released version
> > of our software.
> 
> I guess this was shadowed by feature development of KF having stalled during
> the Qt5/KF5->Qt6/KG6 porting phase as well as Qt6-based flatpaks jobs only
> activated recently.
> 
> > > Right now this is a new extra burden which makes working on new features
> > > with
> > > KF and apps more complicated. Thus less interesting, and one/I would
> > > rather
> > > duplicate code in apps to get things done.
> > > 
> > > Blocking latest KF API from usage also means less testing of that before
> > > the
> > > initial release.
> > > 
> > > 
> > > Besides all the resource costs to create flatpaks on master builds by
> > > default
> > > every time, when those are usually not used by anyone anyway.
> > 
> > Those applications that have a hard dependency on features being added to
> > Frameworks are not good candidates for making use of our Continuous
> > Delivery systems i'm afraid.
> > Both Flatpak and Craft based (Linux Appimages, Android APKs, Windows and
> > macOS) CD jobs are best optimised for those applications that rely on the
> > stable Frameworks releases.
> > 
> > There are ways (in .craft.ini) to make newer Frameworks available, but
> > that
> > requires that the system recompiles that Framework each time you trigger a
> > build and is therefore not recommended.
> > 
> > Allowing those systems to use the "latest" artifacts of Frameworks would
> > be
> > a non-trivial exercise.
> 
> So effectively this means:
> * KF - no CI on new API with non-KF repos, only KF-internal CI
> * KF - no CD, only released versions
> 
> Which makes KF a second class product, with lesser testing :(
> And less interesting to contribute to, given it gets worse CI/CD care.

CI builds can (as they always could on Gitlab and currently mostly do) use 
latest KF master. CD builds can't (and never could, binary factory had the 
same limitation). Nothing is getting worse here, the only thing you cannot 
have is unconditionally using latest KF and expect CD builds for that based on 
cached runtime/platform parts.

The most common way of working for apps seems to be supporting at least the 
last released version of KF, if needed with version ifdefs to already 
integrate newer code. In most cases that is very limited effort, and as soon as 
more than one contributor is involved that is usually highly desired anyway to 
not randomly force full rebuilds on others.

There are cases where this is not feasible, e.g. in case of very tight 
coupling or QML code that cannot easily be ifdef'ed. In that case you either 
wait for the next release, or you can only have CD builds in the release 
branch I'd say. Using expensive "full-stack" CD builds for that would need a 
very good justification given the cost IMHO.

I can't speak for KDE Games obviously, but for the stuff I am involved in I 
most definitely wouldn't want to miss CD builds anymore. There's a bunch of 
people daily-driving Itinerary from those for example, and that is such a big 
help for QA. Bug reports are practically always still relevant, the turnaround 
time for feedback is days or even hours rather than weeks or months, and a 
whole bunch of issues gets caught before even hitting the releases. On top of 
that the Flatpak build provides an extra safety net there for finding 
incompatibilities with two major external dependencies (poppler and zxing), by 
using the latest versions of those.

One thing I do agree on though is that there is no point in running jobs (CI 
nor CD) that really /nobody/ cares about anymore, and the occasional cleanup 
there is probably 

Re: What can we expect from our developers

[Volker Krause]

On Dienstag, 30. Januar 2024 22:05:16 CET Ingo Klöcker wrote:
> On Dienstag, 30. Januar 2024 21:47:51 CET Friedrich W. H. Kossebau wrote:
> > I think I understand where you are coming from, that all the work on
> > software done here makes the more sense the more users there are. IMHO
> > though reaching more users of Free Software should be done in ways and for
> > platforms which are not giving more power to monopolists or those which
> > seem set to become some. Flatpak, Snap, Windows, macOS... they are all
> > about binaries. There is no simple way, part of the concept, to get the
> > sources, patch something to one's likes and then regenerate the very same
> > package, just as custom one. Or is there?
> 
> Yes, there is. They can simply use our infrastructure for this. We are doing
> much more than just providing the sources. We provide the fully functional
> CI/ CD machinery for building custom versions (minus digital signatures
> which we reserve for our official release artifacts).

That, and for Flatpak specifically this is very much part of the concept/
toolchain even. I find the support/integration in e.g. GNOME Builder for this 
particular impressive, I don't think many other packaging formats/toolchains 
are getting anywhere close in terms of "time to modified app running locally", 
with no need to deal with dependencies manually, and with no risk of impacting 
the rest of your system.

Regards,
Volker

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

[Volker Krause]

On Samstag, 27. Januar 2024 18:22:35 CET Friedrich W. H. Kossebau wrote:
> There are only 2 open checkboxes:
> 
> [ ] Passing CI job for Reuse linting
> 
> The challenge is that there are a number of old files where the contributors
> might be hard to contact for an explicit license statement (CMakeLists.txt,
> AUTHOR, Messages.sh, ...)
> 
> Given the same is true for most other KDE games and then some KDE software,
> and Skladnik is actually some (very) old KDE software, just other than its
> KDE games siblings for some time had been excluded from release coverage, I
> would ask us to make a pragmatic exception on the requirement here.

Yes, and doing that is actually existing practice. This point applies 
primarily to new code, we obviously can't expect this to get magically fixed in 
preexisting code that just moved around or got renamed.

Regards,
Volker


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

Re: Usage of KF5/KF6 in targets and CMake config files outside of Frameworks

[Volker Krause]

On Thursday, 9 March 2023 16:58:40 CET Heiko Becker wrote:
> while looking at a MR for libkcddb (part of Gear) I wondered if the
> transition
> from Qt5/KF5 to Qt6/KF6 could be used to get rid of the KF5/6 prefix in
> target
> names and CMake config files for libraries that aren't acutally part of
> Frameworks.
> 
> It always seemed a bit illogical and possibly confusing to me to have e.g.
> KF5Cddb as CMake config file and KF5::Cddb as target name, because it's
> masquerading to be part of something (Frameworks), which isn't actually
> true.
> Especially since we market Frameworks as a common group of libraries, with
> common rules and policies, which may only be followed in part (or maybe not
> at all) by other projects.
> 
> Changing that obviously involves some (temporary) compatibility concerns,
> but that doesn't play any role with the move to Qt6/KF6. So I suggest to
> use the chance and get rid of said prefix with the upcoming porting.
> 
> One example where this was done already some time ago is libkgapi:
> https://invent.kde.org/pim/libkgapi/-/commit/8d15e66f1ed87a52377111735e24888
> b7f924a49

... and much more recently in a number of other PIM modules as well.

My impression so far was that it's already largely consensus that using the KF 
prefix outside of Frameworks was a mistake we made in the early 5 days, and 
that should be corrected when the opportunity arises.

There is one possible exception I can see for this, libraries with an imminent 
move to Frameworks. We have used the fact those were already using the KF 
prefix in several cases (e.g. KContact, KCalendarCore, KDAV) for a seamless 
switch from Gear to Frameworks. Many of the remaining users don't fall into 
that category though.

Regards,
Volker

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

Re: KUnifiedPush in KDE Review

[Volker Krause]

On Mittwoch, 8. Februar 2023 13:11:52 CET Aleix Pol wrote:
> On Tue, Feb 7, 2023 at 6:36 PM Volker Krause  wrote:
> > Hello everyone,
> > 
> > I'd like to get KUnifiedPush
> > (https://invent.kde.org/libraries/kunifiedpush) through KDE Review.
> > 
> > KUnifiedPush contains the client-side building blocks we need for making
> > use of the UnifiedPush (https://unifiedpush.org/) push notification
> > standard.
> > 
> > In particular there are three parts:
> > - an application-side client library
> > - a client-side push notification daemon ("distributor")
> > - a KCM to configure the preferred push provider and to see registered
> > applications
> > 
> > We might want to split out the application-side part eventually, to not
> > mix
> > platform and framework parts, but that shouldn't affect the review.
> > 
> > Open issues:
> > - this is only working for the D-Bus part of the UnifiedPush spec, there
> > is a start of an Android implementation but that is still non-functional
> > if the app isn't running while the platform receives a push notification.
> > That needs some understanding of both the Qt <-> Android integration and
> > the Android mechanisms around broadcast receivers and the restrictions on
> > those, help very much welcome.
> > - while this is generally functional and usable, actual deployment is also
> > depending on having a default push provider (the server side part). There
> > have been a few discussions at FOSDEM on how to progress that.
> > 
> > For more background, there has been an Akademy talk on this, and there is
> > a
> > writeup of that here:
> > https://volkerkrause.eu/2022/11/12/kde-unifiedpush-push-notifications.htm
> > l.
> > 
> > Thanks!
> > Volker
> 
> Hi Volker,
> This sounds great, super encouraging to see progress on this front!
> 
> I was wondering, what's the reason to include this in libraries rather
> than frameworks directly? Is it because of the current state of KDE
> Frameworks transition? 

unclear policies regarding adding things to the frameworks group mainly, when 
I use frameworks directly I get told to use something else, when I use 
something else I get told to use frameworks :)

> I see that KUnifiedPush already sees itself as
> tier 1 (which is probably also something to address since it has a
> number of KF dependencies).

The application-side part is only depending on Qt::DBus so far, the extra KF 
dependencies are for the KCM. Splitting would fix that as well.

Following discussions with the UnifiedPush team about push message encryption 
OpenSSL might become an additional dependency. Technically message encryption 
is something to be solved on the application layer, UnifiedPush just passes on 
opaque messages and thus can't ensure encrypted content. But it's probably a 
good idea to have a recommended default implementation around (RFC 8188/HTTP 
ECE).

> Splitting it would make sense, but I understand this is something to
> happen at least with Plasma 6 as Plasma 5 is feature frozen.

Right. There's no time pressure as we need the server side sorted out as well 
anyway. The only reason this is still mainly 5-focused is that it started 
early last year already.

A split would look like this I guess:
frameworks/kunifiedpush - containing src/client, src/interfaces and src/shared, 
with the latter turned into public API.
plasma?/kunifiedpush-distributor - containing everything else, and a copy of 
src/interfaces, and depending on frameworks/kunifiedpush for what's now in src/
shared.

Regards,
Volker

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

KUnifiedPush in KDE Review

[Volker Krause]

Hello everyone,

I'd like to get KUnifiedPush (https://invent.kde.org/libraries/kunifiedpush) 
through KDE Review.

KUnifiedPush contains the client-side building blocks we need for making use of 
the UnifiedPush (https://unifiedpush.org/) push notification standard.

In particular there are three parts:
- an application-side client library
- a client-side push notification daemon ("distributor")
- a KCM to configure the preferred push provider and to see registered 
applications

We might want to split out the application-side part eventually, to not mix 
platform and framework parts, but that shouldn't affect the review.

Open issues:
- this is only working for the D-Bus part of the UnifiedPush spec, there is a 
start of an Android implementation but that is still non-functional if the app 
isn't running while the platform receives a push notification. That needs some 
understanding of both the Qt <-> Android integration and the Android 
mechanisms around broadcast receivers and the restrictions on those, help very 
much welcome.
- while this is generally functional and usable, actual deployment is also 
depending on having a default push provider (the server side part). There have 
been a few discussions at FOSDEM on how to progress that.

For more background, there has been an Akademy talk on this, and there is a 
writeup of that here: 
https://volkerkrause.eu/2022/11/12/kde-unifiedpush-push-notifications.html.

Thanks!
Volker

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

Re: Frameworks 6 Branching

[Volker Krause]

On Montag, 19. Dezember 2022 15:39:07 CET Fusion Future wrote:
> On 2022/12/19 20:17, Volker Krause wrote:
> >  From that point on, KDE Frameworks 5 is considered feature-frozen,
> >  feature
> > 
> > work should continue to happen in the master branch, primarily targeting
> > KF6 then.
> 
> If I merge a merge request now in Frameworks group now, will the change
> exist in KF5.102, or KF6?

Until branching everything that goes into Frameworks master branch will end up 
both in the next KF5 and the first KF6 release.

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

Frameworks 6 Branching

[Volker Krause]

Hello everyone (and sorry for the massive cross-posting),

we are nearing an important milestone in the KDE Frameworks 6 development, 
branching and thus splitting the development of KDE Frameworks 5 and 6.

Slightly behind the plan from Akademy this is currently scheduled for the first 
week of January.

>From that point on, KDE Frameworks 5 is considered feature-frozen, feature 
work should continue to happen in the master branch, primarily targeting KF6 
then. Bugfixes of course can and should be backported for quite some time to 
come, and KF5 releases will continue with the same pattern as previously. At 
some future point we might start to increase the interval between releases 
though, as the amount of changes decreases.

If you are using kdesrc-build all this should hopefully be transparent. Make 
sure to update to the latest version though and set already existing 6 builds 
to use the now existing "kf6-qt6" branch group.

On the CI we still have some work to do to keep the existing Qt 6 Plasma and 
application builds working after branching (as those essentially rely on a 
Qt6-based KF5, not a "proper" KF6), at least for a transitional period.

Despite all the careful planning and preparation it is quite possible that 
this will cause disruptions of some form though, two major versions of 
Frameworks at the same time is uncharted territory for our tooling.

If you have input or questions about this or want to help, the bi-weekly KF6 
meeting happening tomorrow at 17:00 CET in https://meet.kde.org/b/ada-mi8-aem 
would be a good place to discuss this. If you can't make it, adding your 
topics to the agenda 
(https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/22) is 
also an option. Email (kde-frameworks-devel) or chat 
(#kde-devel) work as well of course.

Regards,
Volker

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

Re: Reviewing the process for giving people commit rights

[Volker Krause]

On Freitag, 1. April 2022 17:36:50 CEST Nicolas Fella wrote:
> To summarize: I don't see a need to change how applications are
> reviewed, but perhaps there are steps we can integrate into the
> application process to communicate better the social etiquette that
> comes with commit access.

I agree.

The current process has worked with very very few issues for decades, and is a 
defining part of our community. Substantially changing that for a single 
prematurely merged MR seems hard to justify (and it's not like we wouldn't 
occasionally have cases of longer term contributors prematurely merging MRs 
either).

Yes, Gitlab makes it easier to contribute without commit access. However, 
commit access isn't only needed for the merge button, it also enables 
collaborating with others on work branches in the main repository.

For an occasional drive-by contributor that is usually not needed, but looking 
at the Gitlab activity of the contributor we are talking about here, it's not 
what I see there. That's a two month continued involvement in kwin, including 
working non-trivial changes in longer-lived branches.

It of course doesn't hurt to occasionally reiterate the expectations and 
responsibilities, to (new) contributors and sponsors alike, but I don't see a 
failure or the process here.

Regards,
Volker



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

Re: Submitting KTextTemplate for KF6

[Volker Krause]

On Samstag, 5. März 2022 19:16:02 CET Ben Cooksley wrote:
> On Sun, Mar 6, 2022 at 6:00 AM Stephen Kelly  wrote:
> > On 26/02/2022 10:38, Volker Krause wrote:
> > > On Sonntag, 20. Februar 2022 16:02:59 CET Stephen Kelly wrote:
> > >> Hello,
> > >> 
> > >> The Qt 5 based Grantlee libraries were depended on by some KDE
> > 
> > applications.
> > 
> > >> For Qt 6, I've created a separate repo for KTextTemplate for one of the
> > >> Grantlee libraries. The other library is separate and can be dealt with
> > >> separately.
> > >> 
> > >> Currently the code lives here:
> > >> 
> > >> https://github.com/steveire/ktexttemplate
> > >> 
> > >> I'd like to get the process moving on getting this reviewed and into
> > 
> > KF6.
> > 
> > >> It's not clear to me what the next step is. I tried googling terms like
> > >> "how to submit a library to kde frameworks", but didn't find anything
> > >> useful.
> > >> 
> > >> https://techbase.kde.org/KDE_Frameworks describes how to build
> > >> frameworks, but not how to submit a new one.
> > >> 
> > >> I've checked and I can still use invent.kde.org, so it would be good if
> > >> there is a standard process I can follow for the rest.
> > > 
> > > I don't think the process of integrating a so far external project into
> > > Frameworks happened often enough for this to be documented as a
> > 
> > streamlined
> > 
> > > process. I'd suggest the following steps:
> > > 
> > > (1) Import the repo into invent.kde.org
> > > (2) Go through the KDE Review process
> > > (3) Request inclusion into Frameworks
> > > 
> > > Happy to see this moving :)
> > 
> > Ok. I was thinking there might be some 'review' area of invent.k.o, but
> > I've just made
> > 
> > https://invent.kde.org/skelly/ktexttemplate
> > 
> > Does that satisfy (1)?
> 
> It starts the process yes.
> 
> > I think there are changes like CamelCase headers to conform to KF6
> > norms. I'm not sure if others can help with that now. Can any KDE
> > account push to the above repo?
> 
> No, only you are able to push to that repository, but people can send you
> merge requests.
> 
> To give people access to the repository you can either:
> a) Invite the teams/kde-developers group to the repository as a 'Developer'
> which will grant access to it; or
> b) Ask Sysadmin to move the repository into libraries/ which is where it
> would go prior to becoming a Framework (which it can only do when it
> completes KDE Review)

I'd say let's do (b) next so it's in a more canonical place and easier to 
find, and then trigger the KDE Review process.

Regards,
Volker

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

Re: Submitting KTextTemplate for KF6

[Volker Krause]

On Sonntag, 20. Februar 2022 16:02:59 CET Stephen Kelly wrote:
> Hello,
> 
> The Qt 5 based Grantlee libraries were depended on by some KDE applications.
> 
> For Qt 6, I've created a separate repo for KTextTemplate for one of the
> Grantlee libraries. The other library is separate and can be dealt with
> separately.
> 
> Currently the code lives here:
> 
> https://github.com/steveire/ktexttemplate
> 
> I'd like to get the process moving on getting this reviewed and into KF6.
> 
> It's not clear to me what the next step is. I tried googling terms like
> "how to submit a library to kde frameworks", but didn't find anything
> useful.
> 
> https://techbase.kde.org/KDE_Frameworks describes how to build
> frameworks, but not how to submit a new one.
> 
> I've checked and I can still use invent.kde.org, so it would be good if
> there is a standard process I can follow for the rest.

I don't think the process of integrating a so far external project into 
Frameworks happened often enough for this to be documented as a streamlined 
process. I'd suggest the following steps:

(1) Import the repo into invent.kde.org
(2) Go through the KDE Review process
(3) Request inclusion into Frameworks

Happy to see this moving :)

Regards,
Volker

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

Re: KHealthCertificate in kdereview

[Volker Krause]

On Montag, 12. Juli 2021 13:36:11 CEST Harald Sitter wrote:
> My only gripe, besides what Albert already pointed out, is that all
> the properties are WRITEable but have no NOTIFY signal nor are they
> CONSTANT. One of those things ought to change. Considering only the
> certificate objects have properties and they are always constructed by
> the parsers I guess you could just drop the WRITE and make them
> CONSTANT?

CONSTANT vs NOTIFY is a bit pointless on Q_GADGETs as NOTIFY isn't possible 
there at all, but WRITE is indeed neither needed nor desired here. Fixed.

> There is a somewhat different approach, that I only bring up because I
> do enjoy meta programming way too much: Currently the parsers have
> exhaustive if-else constructs to map incoming fields to setters. What
> you could do is make static maps from incoming keys to property key
> and then write the property filing in an abstract fashion e.g. to
> 
> illustrate:
> > static QMap propertyMap{{"tg", "disease"}, {"fr",
> > "dateOfPositiveTest"}, ...}; while (reader.hasNext()) {
> > cert.setProperty(propertyMap.value(key), CborUtils::readString(reader));
> > // needs some error handling when key mapping fails and possibly type
> > conversion helpers }
> 
> Then the WRITE would make sense and I'd use a single "changed()"
> signal to NOTIFY on all the properties. drkonqi's bugzilla library
> does something like that to model API objects for example.

Good idea in general, however tricky to apply here I think as the amount of 
different types or ways of parsing the raw data is not significantly less than 
the amount of properties, so I don't expect much to be gained by this.

Thanks!
Volker

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

Re: KHealthCertificate in kdereview

[Volker Krause]

On Montag, 12. Juli 2021 00:36:05 CEST Albert Astals Cid wrote:
> El diumenge, 11 de juliol de 2021, a les 15:32:27 (CEST), Volker Krause va 
escriure:
> > Hi,
> > 
> > KHealthCertificate is a library for decoding digital vaccination, test and
> > recovery certificates. Supported formats/features are:
> > * EU DGC: almost all data found in vaccination, test and recovery
> > certificates, verification of ECDSA and RSA/PSS signatures.
> > * India: basic support for vaccination certificates, no signature
> > verification yet.
> > 
> > https://invent.kde.org/pim/khealthcertificate
> > 
> > If you have more samples/information about the Indian system, or systems
> > deployed elsewhere in the world, I'd be very much interested :)
> > 
> > The first user of this is the basic vaccination certificate manager in
> > Itinerary (currently optional), other potential users who have expressed
> > interest are Qrca and MyGnuHealth, as well as a possible stand-alone
> > vaccination certificate wallet app for Plasma Mobile.
> > 
> > Beyond kdereview the goal would be to join an automated release process,
> > Plasmo Gear is probably the best option of those given the expected users.
> > 
> > A note on translations: The only user-visible strings right now are those
> > in the EU DGC JSON files mapping various codes to human readable texts.
> > Those datasets are supposed to be translated eventually, by upstream.
> > This however isn't implemented yet apparently, the official apps are
> > waiting for this as well (e.g.
> > https://github.com/Digitaler-Impfnachweis/covpass-android/blob/
> > main/covpass-sdk/src/main/java/de/rki/covpass/sdk/storage/
> > EUValueSetRepository.kt#L11). So I'd rather wait for that getting fixed
> > rather than bothering our translators with various medical product names
> > :)
> > 
> > For testing this you need a fairly recent KF5, KCodecs 5.84 for Base45
> > support and Prison 5.85 if your phone screen is too small for the usually
> > very large barcodes.
> 
> Rename some non installed headers in src/lib to *_p.h ?
> 
> I tried reading the headers to see how i would use this and i was left with
> some questionmarks.
> 
> Am I supposed to call KHealthCertificateParser::parse? With what? Because it
> says "data received from a barcode scanner" but i guess that's not the
> QImage data?
> 
> Also it returns a QVariant ? What's in there?

Documentation has been expanded and private headers are renamed.

Thanks!
Volker

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

Re: KHealthCertificate in kdereview

[Volker Krause]

On Sonntag, 11. Juli 2021 16:07:37 CEST Friedrich W. H. Kossebau wrote:
> Quick feedback after looking at the cmake code:
> 
> * do not explicitly list ECM_KDE_MODULE_DIR, it is part of ECM_MODULE_PATH
> * do not use KDEFrameworkCompilerSettings for non-KF projects, only
> KDECompilerSettings
> * no need to set CMAKE_AUTOMOC & CMAKE_AUTORCC, done by KDECompilerSettings
> for required ECM
> * set(CMAKE_CXX_STANDARD 17) before including KDECompilerSettings
> * call feature_summary as last thing, for consistency and some logic in
> execution
> * avoid REQUIRED in find_package() calls, only use in
> set_package_properties, so cmake will not cancel in middle of run, but get
> to listing found/notfound summary (Qt, ECM, KF are harder to do here due to
> macros expected later, and usually present, so fine there)
> * include the 3 KDE cmake setting modules as first and in this order:
>   include(KDEInstallDirs)
>   include(KDECMakeSettings)
>   include(KDECompilerSettings NO_POLICY_SCOPE)
> * I recommend using set_target_properties() right next to add_${target},
>   easier to find on need and product definition in one place makes more
> sense

done, with the exception of switching away from KDEFrameworksCompilerSettings, 
that can only be done for 5.85, for earlier versions that would require 
copying a bunch of settings it seems.

Thanks,
Volker

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

KHealthCertificate in kdereview

[Volker Krause]

Hi,

KHealthCertificate is a library for decoding digital vaccination, test and 
recovery certificates. Supported formats/features are:
* EU DGC: almost all data found in vaccination, test and recovery 
certificates, verification of ECDSA and RSA/PSS signatures.
* India: basic support for vaccination certificates, no signature verification 
yet.

https://invent.kde.org/pim/khealthcertificate

If you have more samples/information about the Indian system, or systems 
deployed elsewhere in the world, I'd be very much interested :)

The first user of this is the basic vaccination certificate manager in 
Itinerary (currently optional), other potential users who have expressed 
interest are Qrca and MyGnuHealth, as well as a possible stand-alone 
vaccination certificate wallet app for Plasma Mobile.

Beyond kdereview the goal would be to join an automated release process, 
Plasmo Gear is probably the best option of those given the expected users.

A note on translations: The only user-visible strings right now are those in 
the EU DGC JSON files mapping various codes to human readable texts. Those 
datasets are supposed to be translated eventually, by upstream. This however 
isn't implemented yet apparently, the official apps are waiting for this as 
well (e.g. https://github.com/Digitaler-Impfnachweis/covpass-android/blob/
main/covpass-sdk/src/main/java/de/rki/covpass/sdk/storage/
EUValueSetRepository.kt#L11). So I'd rather wait for that getting fixed rather 
than bothering our translators with various medical product names :)

For testing this you need a fairly recent KF5, KCodecs 5.84 for Base45 support 
and Prison 5.85 if your phone screen is too small for the usually very large 
barcodes.

Thanks,
Volker

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

Re: Koko in KDEReview

[Volker Krause]

On Dienstag, 16. März 2021 20:10:46 CET Carl Schwan wrote:
> Le mardi, mars 16, 2021 12:55 PM, Harald Sitter  a écrit :
> > -   since it doesn't appear in the UI, I can't check: is the geodata
> > 
> > actually getting localized? at least the geocoder seems to spit out
> > non-localized values
> 
> Yeah, it's not localized :( Cities and region names are using the local
> name and countries are using the English name. It probably make sense to
> fix the contries name to be localized but the cities/regions names won't
> be realistic since there are just too many of them (~137 562).

Countries and country subdivisions (regions) are part of the iso-codes 
translation catalogs we depend on already anyway. See also https://
phabricator.kde.org/T12429 for an API proposal to make that easily accessible 
(needs feedback to continue).

Cities also recently came up in the context of KWeather. If we want that, it 
might be doable by compiling the city database ourselves based on OSM/
Wikidata, including all translations found in there. That is very likely also 
not complete, but certainly a lot more realistic than trying to translate this 
ourselves.


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

Re: KDE Frameworks 6 - Virtual Sprint setup

[Volker Krause]

On Freitag, 29. Januar 2021 15:57:59 CET Adam Szopa wrote:
> Hello,
> I've been talking with David Faure about setting up a Sprint focused on KF6 
> work. Some of the topics would include:
> - Reviewing the KF6 board
> (https://phabricator.kde.org/project/board/310/[1]): -- Clean up
> -- Tagging Junior Jobs
> - Working out a structure/process for handling:
> -- "Stuck" tasks
> -- Unit test regressions
> - Decide the 5.15 minimum requirement bump timeline
> - Decide on a 6 branching strategy and timeline
> - Decide if/how ECM should support multiple Qt versions
> 
> That's just an example list - the wiki[1] should include the up to date and
> detailed topics.
> 
> The Sprint will use the KDE BBB instance - same tech that powered last years
>  Akademy; I'll coordinate that with our sysadmins to have it available.
> 
> As for the date and length, usually Virtual Sprints are a weekend thing. I'd
> love to hear from you if that sounds OK, and which weekend would be
> workable for you (how soon can we get this started) and your preferred
> availability hours. I'll set up a poll later to pinpoint the final timing.

Poll: https://framadate.org/LGvewKljewnW6836
Wiki: https://community.kde.org/Sprints/KF6/2021Virtual

Regards,
Volker

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

Re: KDE Frameworks 6 - Virtual Sprint setup

[Volker Krause]

On Freitag, 29. Januar 2021 15:57:59 CET Adam Szopa wrote:
> Hello,
> I've been talking with David Faure about setting up a Sprint focused on KF6 
> work. Some of the topics would include:
> - Reviewing the KF6 board
> (https://phabricator.kde.org/project/board/310/[1]): -- Clean up
> -- Tagging Junior Jobs
> - Working out a structure/process for handling:
> -- "Stuck" tasks
> -- Unit test regressions
> - Decide the 5.15 minimum requirement bump timeline
> - Decide on a 6 branching strategy and timeline
> - Decide if/how ECM should support multiple Qt versions
> 
> That's just an example list - the wiki[1] should include the up to date and
> detailed topics.
> 
> The Sprint will use the KDE BBB instance - same tech that powered last years
>  Akademy; I'll coordinate that with our sysadmins to have it available.
> 
> As for the date and length, usually Virtual Sprints are a weekend thing. I'd
> love to hear from you if that sounds OK, and which weekend would be
> workable for you (how soon can we get this started) and your preferred
> availability hours. I'll set up a poll later to pinpoint the final timing.

Thanks for driving this, I'm in! European hours preferred, any weekend 
starting from w6 should be possible.

Regards,
Volker

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

Re: PSA: Please do not use KDEFrameworkCompilerSettings for non-KF projects

[Volker Krause]

On Mittwoch, 20. Januar 2021 13:51:15 CET Harald Sitter wrote:
> On 19.01.21 16:57, Friedrich W. H. Kossebau wrote:
> > Hi,
> > 
> > the docs of the module tell us:
> > "KDEFrameworkCompilerSettings - Set stricter compile and link flags for
> > KDE
> > Frameworks modules."
> > https://api.kde.org/ecm/kde-module/KDEFrameworkCompilerSettings.html
> > 
> > And it has been meant that way. E.g. because extending those settings with
> > more strict settings or new features would be done with other KF-specific
> > requirements or policies in mind, always matching those of the current
> > version (given KF & ECM are released in-sync).
> > Having to take care of backward-compatibility with non-KF usage and to do
> > proper documentation adds additional burden not wanted here.
> > 
> > As convenient it is to not have to write out e.g. all the
> > add_definitions(
> > 
> > -DQT_NO_CAST_TO_ASCII
> > -DQT_NO_CAST_FROM_ASCII
> > -DQT_NO_URL_CAST_FROM_STRING
> > -DQT_NO_CAST_FROM_BYTEARRAY
> > -DQT_NO_SIGNALS_SLOTS_KEYWORDS
> > -DQT_USE_QSTRINGBUILDER
> > -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT
> > 
> > )
> > that needs some other solution.
> > 
> > For ECM/KF5 times the train has left, we need to handle those existing
> > abuses. But please fix your projects now already by changing back to
> > KDECompilerSettings and the manual boilerplate, so in ECM/KF6 times that
> > burden is gone.
> 
> Perhaps there should be a unit test asserting this somehow?
> LXR reports `247 occurences found.` so this seems a fairly wide spread
> issue :(
> 
> Perhaps hardcode a list of all cmake project names that are frameworks
> in ECM and then test that the settings are only used with one of them?
> Just an idea.

How about we try to come up with an alternative solution for what looks like a 
wide-spread demand for centrally maintained high-quality compiler settings 
instead then? That might also make any kind of enforcement to not use this 
outside of Frameworks unnecessary :)

Regards,
Volker


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

Re: KDE review for KWeatherCore

[Volker Krause]

On Samstag, 2. Januar 2021 12:44:31 CET Dominik Haumann wrote:
> This is just by looking at the first two header files.
> 
> Looking at WeatherForecast.cpp:
> 
> double maxTemp = std::numeric_limits::min();
> double minTemp = std::numeric_limits::max();
> 
> Initializing the temperature to 0, 0, sounds a bit more sane to me, but
> that is disputable I guess.

Nice find. This looks quite familiar, the weather forecast accumulation code 
in Itinerary does something very much like this, to make std::min/std::max 
work without special-casing invalid values.

However the way it's done here will fail for negative max temperatures, as 
std::numeric_limits::min() is not what one might expect (it's the 
smallest positive value for floating point types), you want 
std::numeric_limits::lowest().

Regards,
Volker

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

Re: KDE review for KWeatherCore

[Volker Krause]

Having implemented the weather support for Itinerary, rebasing that onto a 
more comprehensive framework would indeed be welcome :)

I haven't looked too deeply at the implementation or the API yet, most of the 
feedback below is based on things learned when implementing this for 
Itinerary.

## api.met.no license and ToS compliance

The data is coming from the Norwegian Meteorological Institute, CC-licensed 
and with an API that doesn't require authentication, well documented and with 
a mailinglist for service changes and roadmap/disruption announcements. As far 
as implementing Open Data by organizations/public administration goes this is 
exemplary and unfortunately quite rare.

So at the very least we should follow their license and terms of services as 
close as possible, in letter and in spirit. Not all of that can be ensured by 
the library, some of this needs to be handled by the application. In the 
latter case those requirements need to be clearly documented though.

In particular I remember implementing the following aspects:

(1) add a point of contact to the User-Agent header, in case your client 
misbehaves. I only see this done in one place, https://invent.kde.org/
libraries/kweathercore/-/blob/master/src/weatherforecastsource.cpp#L52, which 
looks suspiciously like a verbatim copy from Itinerary, without even adjusting 
the contact address.

(2) Request throttling. The ToS seem to have been changed in wording since I 
last looked at this, but the requirement is still similar: Ensure we don't run 
unnecessary many queries. The Itinerary implementation uses a random interval 
between 120-150 minutes as lower bound, based on previous suggestions in the 
ToS.

The already suggested daemon is one way to ensure this globally, however I'm 
very reluctant to suggest a daemon for this, considering the deployment issues 
this causes for e.g. Flatpak or APKs. Itinerary uses a simple file cache and 
file mtimes, something like this should also hold up in a multi-process setup 
with a bit of extra care I think.

(3) Attribution, as required by the CC-BY license. This has to happen in the 
UI, but as a library user I need to know about this requirement, so this needs 
prominent mention in the docs I'd say.

See https://api.met.no/doc/TermsOfService for more details.


I also see other services used there I'm not familiar with, are we complying 
with their licenses and terms of services?


## Privacy considerations

(1) Requested geo coordinates are passed to the online API as-is, ie. this is 
potentially leaking a high-resolution position of the user to the outside. We 
can't avoid this entirely obviously, but we can reduce the impact by reducing 
the coordinate resolution. 

Itinerary uses 1/10th of a degree for this, which unless you get close to the 
poles are areas of a few kilometers in size, ie. rather than leaking your home 
address it's only leaking your home town.

(2) What does the sunrise API offer beyond the existing sunrise API we have in 
KF5::Holidays? The latter has the advantage of doing the entire calculation 
locally.

See https://api.kde.org/frameworks/kholidays/html/
namespaceKHolidays_1_1SunRiseSet.html

(3) Similarly, we do have a full offline implementation for timezone lookup by 
geo coordinates here: https://api.kde.org/kdepim/kitinerary/html/
namespaceKItinerary_1_1KnowledgeDb.html#ac409f468badee3c05438695009d7c67f

(4) There are http: only requests send to api.geonames.org it seems.


Similarly as with the compliance point, some of this can be argued to be the 
job of the using application. It would seem safer though is the library would 
try  to avoid mistakes to begin with.


## Other observations

(1) The license seems to be GPL-2.0-or-later, which is incompatible with the 
Frameworks license policy. See https://community.kde.org/Policies/
Licensing_Policy

(2) The result types (DailyForecast, HourlyForecast, etc) might benefit from 
being Q_GADGETs and having Q_PROPERTYs added, so they can be directly consumed 
by QML?

(3) binary compatibility measures seem to be missing in a number of places: 
https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B


Regards,
Volker

On Montag, 21. Dezember 2020 07:16:09 CET hanyoung wrote:
> KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for
> querying weather forecast data. During the development of KWeather, we
> found the need to have a weather library. KWeatherCore is the result of
> extracting weather data fetching code from KWeather. I think having a
> dedicated weather library can serve the following propose: - simplify the
> KWeather code
> - easier to develop a weather daemon
> - potentially less code duplication across KDE
> 
> Many of you may have already seen my previous email to kde-devel mailing
> list.
> Thank you for your constructive suggestions. Here are something I want to 
clarify:
> > I would also propose to consider doing a demon instead, so different
> > 

Re: KOpeningHours in kdereview

[Volker Krause]

On Donnerstag, 10. Dezember 2020 21:09:23 CET Johan Ouwerkerk wrote:
> On Thu, Dec 10, 2020 at 6:00 PM Volker Krause  wrote:
> > The most notable feature gap compared to the official specification is
> > probably school holidays, we lack a collection of international data for
> > that so far. That only occurs in about 2k out of the 1.8M opening hours
> > expressions in the full OSM database, so that's not a massive problem in
> > practice.
> This may be more difficult than you perhaps realise: at least in the
> Netherlands such holidays are not fixed. They can vary regionally, as
> well from year to year and potentially also depend on
> denomination/religion. A good example of this is that in the southern
> part of the Netherlands care is taken to ensure Carnival falls within
> an official holiday, but the same might not apply "north of the
> rivers". (Additional fun complication is the temporary colloquial
> renaming of towns during the festival).

The public holiday data isn't included in this library, we depend on 
KF5::Holidays for that. If that provides wrong information this will produce 
wrong output as well of course.

What you can get however from KOpeningHours is the information if an 
expression is relying on public holiday data, so you can make application-
specific decisions to what extend you trust the result if needed.

Regards,
Volker

Re: KOpeningHours in kdereview

[Volker Krause]

On Donnerstag, 10. Dezember 2020 20:27:07 CET Ingo Klöcker wrote:
> On Donnerstag, 10. Dezember 2020 17:56:15 CET Volker Krause wrote:
> > The most notable feature gap compared to the official specification is
> > probably school holidays, we lack a collection of international data for
> > that so far. That only occurs in about 2k out of the 1.8M opening hours
> > expressions in the full OSM database, so that's not a massive problem in
> > practice.
> 
> I'd say that currently the most notable feature gap is lack of knowledge
> about Corona lock-downs. I guess that currently a massive amount of
> locations are not open even if the opening hours data in OSM says so. :/

OSM models this with https://wiki.openstreetmap.org/wiki/
DE:Key:opening_hours:covid19 - same format as far as the parser is concerned, 
but you are right that this isn't taken into account in KDE Itinerary yet. 
OTOH KDE Itinerary itself is pretty useless during a pandemic...

Regards,
Volker

Re: KOpeningHours in kdereview

[Volker Krause]

On Donnerstag, 10. Dezember 2020 21:03:30 CET Rolf Eike Beer wrote:
> > but meanwhile it's also being
> > evaluated for use in OSM validation tooling:
> > https://github.com/osm-fr/osmose-backend/issues/555. That has already
> > resulted in a number of contributions increasing the tolerance for
> > non-conforming expressions, which benefits all other use-cases as well.
> 
> I was thinking about doing something similar for OSM2go, which currently
> also runs on the N900 and needs gcc 4.2 for it. Is there interest to have a
> C++98 STL only version of the main parser? Or is it so tied to Qt classes
> that there is no chance in that?

The parser itself is flex/bison and isn't using Qt types much, and doing this 
in a STL-only way was already discussed in the context of the use in OSM 
validation tooling. That doesn't give you much though, the evaluation code 
heavily depends on Qt for date/time math, timezones, calendar system, locale, 
holidays, etc, there are no replacements for much of this in STL, let alone in 
C++98. Going back from C++17 to C++98 would also be a major effort I guess.

For the flex/bison code it might be possible to factor out these parts, as 
it's largely very basic C++ code anyway. You'd need to rebuild most of the 
logic around that though I'm afraid.

Probably needs a more detailed look at what you need exactly and what you have 
available in terms of libs and tools to see what's possible.

Regards,
Volker

KOpeningHours in kdereview

[Volker Krause]

Hi,

KOpeningHours is a library with C++ and QML API for parsing and evaluating OSM 
opening hours expressions. That might sound simple, and for basic cases like 
`Mo-Fr 09:00-17:00` it is, but it gets quite a bit more complex for more 
elaborate expressions that consider e.g. public holidays or seasonal changes.

https://invent.kde.org/libraries/kopeninghours

The most notable feature gap compared to the official specification is 
probably school holidays, we lack a collection of international data for that 
so far. That only occurs in about 2k out of the 1.8M opening hours expressions 
in the full OSM database, so that's not a massive problem in practice.

The API is prepared to handle the very similar OSM service time format ("point 
in time mode") as well, but evaluation for that hasn't been implemented yet.

The first users are KOSMIndoorMap and KDE Itinerary, for graying out elements 
on the map that aren't going to be available during a layover, and for showing 
a human-readable interpretation of the opening hours for a selected entity. 
You were at Akademy 2018 and got surprised by shops/restaurants suddenly being 
closed on Wednesday? That's exactly why you want this :)

PBI also has previously shown interest in supporting schema.org opening hours 
data, which KOpeningHours can consume as well. That was the original 
motivation to do this as a separate library, but meanwhile it's also being 
evaluated for use in OSM validation tooling: 
https://github.com/osm-fr/osmose-backend/issues/555. That has already resulted 
in a number of contributions 
increasing the tolerance for non-conforming expressions, which benefits all 
other use-cases as well.

Two command line demos and a QML example are included, if you want to try it 
I'd recommend to also get the latest KF5::Holidays to have all needed fixes 
and performance improvements.

My goal would be to have this join the release service for 21.04, so KDE 
Itinerary can properly depend on it.

Thanks,
Volker

Re: KOSMIndoorMap in kdereview

[Volker Krause]

On Freitag, 23. Oktober 2020 22:29:39 CEST Albert Astals Cid wrote:
> El divendres, 23 d’octubre de 2020, a les 16:56:37 CEST, Volker Krause va 
escriure:
> > On Freitag, 23. Oktober 2020 00:45:46 CEST Albert Astals Cid wrote:
> > > El dijous, 22 d’octubre de 2020, a les 17:25:32 CEST, Volker Krause va
> > 
> > escriure:
> > > > Hi,
> > > > 
> > > > KOSMIndoorMap is a QML component for showing multi-floor OSM indoor
> > > > maps
> > > > (as its very creative name might suggest). It's using maps.kde.org as
> > > > a
> > > > data source (same as Marble), and has been created to show interactive
> > > > maps of train stations for KDE Itinerary.
> > > > 
> > > > https://invent.kde.org/libraries/kosmindoormap
> > > > 
> > > > KOSMIndoorMap has been growing inside the KPublicTransport repo (due
> > > > to
> > > > some building blocks being available there alreay and me being lazy),
> > > > and
> > > > has now been split into its own repo. So technically this is coming
> > > > out
> > > > of a reviewed repo already rather than from playground, but better be
> > > > on
> > > > the safe side :)
> > > > 
> > > > The aim is having this (together with KPublicTransport and KDE
> > > > Itinerary)
> > > > join the release service for 20.12.
> > > 
> > > Is this fixable?
> > > 
> > > [libprotobuf WARNING google/protobuf/compiler/parser.cc:648] No syntax
> > > specified for the proto file: osmformat.proto. Please use 'syntax =
> > > "proto2";' or 'syntax = "proto3";' to specify a syntax version.
> > > (Defaulted
> > > to proto2 syntax.) [libprotobuf WARNING
> > > google/protobuf/compiler/parser.cc:648] No syntax specified for the
> > > proto
> > > file: fileformat.proto. Please use 'syntax = "proto2";' or 'syntax =
> > > "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
> > 
> > fixed, although that requires modifying the 3rdparty proto files
> > 
> > > and this?
> > > 
> > > style/mapcsslexer.l:65: warning, no es pot satisfer la regla
> > > style/mapcssparser.y:143.11-14: advertiment: valor sense usar: $2
> > > [-Wother]
> > > 
> > >   143 | | Ruleset Rule
> > >   
> > >   |   ^~~~
> > > 
> > > and this?
> > > 
> > > src/map/scene/scenegeometry.cpp: In function ‘double
> > > KOSMIndoorMap::SceneGeometry::polylineMidPointAngle(const QPolygonF&)’:
> > > src/map/scene/scenegeometry.cpp:75:24: warning: unused variable ‘r’
> > > [-Wunused-variable] 75 | const auto r = ((length + l) -
> > > lineLength / 2.0) / l;
> > 
> > both fixed
> > 
> > > Should ./bin/indoormap do anything? I have one empty combo and one combo
> > > that lets me change the style.
> > 
> > Good point, I've documented the test apps in the README now. Try
> > `indoormap -c 52.52512,13.36966` or alternatively `qmlscene
> > tests/indoormap.qml` to see a few more features (after updating to latest
> > master to make this work with your locale too, see below).
> > 
> > > You have one qsTr in the qml that it's not going to work, also a "TODO
> > > i18n?" that i would say yes?
> > 
> > Fixed, leftovers from before switching to ki18n.
> 
> Since i understand this is a library, you want to use i18nd on qml (you're
> using that on your c++ by using -DTRANSLATION_DOMAIN=)

Indeed, fixed.

> > > It has tests \o/ the tests don't pass /o\ https://pastebin.com/CFcdVJHh
> > 
> > Ouch, you actually found some quite serious breakage that I had entirely
> > missed since neither my local nor the CI locale is affected... This all
> > goes down to some string to floating point number conversion being done
> > locale- aware while they shouldn't be.
> 
> Glad to be of service :)
> 
> Another thing, do you want d-pointers to make keeping ABI easier or don't
> care at this point?

The one class of the C++ interface that is actually used externally at this 
point has a d-pointer already, everything else that is exported is for the QML 
plugins and unit tests in the same repo. This might change over time though, 
at which point more d-pointers would indeed become necessary.

This wont work for the low-level OSM primitives though (that's the points, 
lines and polygons making up the map geometry). Those exists in so large 
quantities that the additional allocation overhead becomes prohibitive.

The server-side tile generator is using Marble which has d-pointers on those 
types, last time I measured that about 10% of the total runtime was spent just 
on d-pointer destruction. Construction/allocation will likely cost at least as 
much as well, but that's harder to separate in the measurements from things 
that have to happen either way.

Regards,
Volker

> > Dirty fixes applied, once std::from_chars becomes available for floating
> > point types this can be addressed more cleanly.
> > 
> > We should run the CI with rotating/random locales :)
> > 
> > Thanks for the feedback!
> > Volker

Re: KOSMIndoorMap in kdereview

[Volker Krause]

On Freitag, 23. Oktober 2020 00:45:46 CEST Albert Astals Cid wrote:
> El dijous, 22 d’octubre de 2020, a les 17:25:32 CEST, Volker Krause va 
escriure:
> > Hi,
> > 
> > KOSMIndoorMap is a QML component for showing multi-floor OSM indoor maps
> > (as its very creative name might suggest). It's using maps.kde.org as a
> > data source (same as Marble), and has been created to show interactive
> > maps of train stations for KDE Itinerary.
> > 
> > https://invent.kde.org/libraries/kosmindoormap
> > 
> > KOSMIndoorMap has been growing inside the KPublicTransport repo (due to
> > some building blocks being available there alreay and me being lazy), and
> > has now been split into its own repo. So technically this is coming out
> > of a reviewed repo already rather than from playground, but better be on
> > the safe side :)
> > 
> > The aim is having this (together with KPublicTransport and KDE Itinerary)
> > join the release service for 20.12.
> 
> Is this fixable?
> 
> [libprotobuf WARNING google/protobuf/compiler/parser.cc:648] No syntax
> specified for the proto file: osmformat.proto. Please use 'syntax =
> "proto2";' or 'syntax = "proto3";' to specify a syntax version. (Defaulted
> to proto2 syntax.) [libprotobuf WARNING
> google/protobuf/compiler/parser.cc:648] No syntax specified for the proto
> file: fileformat.proto. Please use 'syntax = "proto2";' or 'syntax =
> "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)

fixed, although that requires modifying the 3rdparty proto files

> and this?
> 
> style/mapcsslexer.l:65: warning, no es pot satisfer la regla
> style/mapcssparser.y:143.11-14: advertiment: valor sense usar: $2 [-Wother]
>   143 | | Ruleset Rule
> 
>   |   ^~~~
> 
> and this?
> 
> src/map/scene/scenegeometry.cpp: In function ‘double
> KOSMIndoorMap::SceneGeometry::polylineMidPointAngle(const QPolygonF&)’:
> src/map/scene/scenegeometry.cpp:75:24: warning: unused variable ‘r’
> [-Wunused-variable] 75 | const auto r = ((length + l) -
> lineLength / 2.0) / l;

both fixed

> Should ./bin/indoormap do anything? I have one empty combo and one combo
> that lets me change the style.

Good point, I've documented the test apps in the README now. Try `indoormap -c 
52.52512,13.36966` or alternatively `qmlscene tests/indoormap.qml` to see a 
few more features (after updating to latest master to make this work with your 
locale too, see below).

> You have one qsTr in the qml that it's not going to work, also a "TODO
> i18n?" that i would say yes?

Fixed, leftovers from before switching to ki18n.

> It has tests \o/ the tests don't pass /o\ https://pastebin.com/CFcdVJHh

Ouch, you actually found some quite serious breakage that I had entirely 
missed since neither my local nor the CI locale is affected... This all goes 
down to some string to floating point number conversion being done locale-
aware while they shouldn't be.

Dirty fixes applied, once std::from_chars becomes available for floating point 
types this can be addressed more cleanly.

We should run the CI with rotating/random locales :) 

Thanks for the feedback!
Volker

Re: KOSMIndoorMap in kdereview

[Volker Krause]

On Donnerstag, 22. Oktober 2020 21:14:43 CEST Rolf Eike Beer wrote:
> Am Donnerstag, 22. Oktober 2020, 17:25:32 CEST schrieb Volker Krause:
> > Hi,
> > 
> > KOSMIndoorMap is a QML component for showing multi-floor OSM indoor maps
> > (as its very creative name might suggest). It's using maps.kde.org as a
> > data source (same as Marble), and has been created to show interactive
> > maps of train stations for KDE Itinerary.
> > 
> > https://invent.kde.org/libraries/kosmindoormap
> > 
> > KOSMIndoorMap has been growing inside the KPublicTransport repo (due to
> > some building blocks being available there alreay and me being lazy), and
> > has now been split into its own repo. So technically this is coming out
> > of a reviewed repo already rather than from playground, but better be on
> > the safe side :)
> > 
> > The aim is having this (together with KPublicTransport and KDE Itinerary)
> > join the release service for 20.12.
>
> The const version of DataSet::way() returns Way*, but the non-const version
> returns OSM::Way*. I guess the extra qualification is not needed.

fixed

> In OSM2go I use std::unordered_map to store the different types of objects
> which makes lookups much easier. YMMV depending if you want to optimize for
> lookup or memory size.

Since the vectors are sorted, lookup performance there hasn't been an issue so 
far. Lookup performance for tags OTOH has been (and to some extend still is) a 
much bigger issue.

> My recent work there is to get rid of the note, way, and relation prefixes
> or suffixes on function names and make a template from the remaining
> implementation so I don't have to implement the same things 3 times.
> 
> I have derived all 3 object types from a common base class, which allows me
> to simplify things like Element::url() by just calling obj->url() and let a
> virtual overload do the rest. Which is a good example: the final return in
> that function should be replaced by Q_UNREACHABLE(), too.

Right, a common base class and virtual methods would make that code more 
elegant, possibly even making the entire Element/UniqueElement classes 
unnecessary. However, that comes at the cost of an extra sizeof(void*) per 
instance. And given how many instances there are and how aggressively this has 
been optimized for memory size, that would be going in the wrong direction. 
I've actually thought about adding an additional type for the common case of 
tag-less nodes to get rid of the tag storage overhead in that case :)

While this is designed to handle a single (large and detailed) building only, 
it can actually handle an entire city as well by now, without any tiling. That 
should leave us enough room even in case of an exploding level of detail in 
large train stations, and for resource-constraint phones.

Q_UNREACHABLEs have been added.

> The nodes vectors in Element::outerPath() could benefit from a call to
> reserve().

appendNodesFromWay() (and via that also assemblePath()) do call reserve on 
those vectors internally.

> The coding style for the remark-if in XmlParser::parse() is inconsistent.
> Or, if compared to the rest of the file, it's the only consistent one in
> that function.

fixed

> Eike

Thanks for the feedback!

Volker

KOSMIndoorMap in kdereview

[Volker Krause]

Hi,

KOSMIndoorMap is a QML component for showing multi-floor OSM indoor maps (as 
its very creative name might suggest). It's using maps.kde.org as a data 
source (same as Marble), and has been created to show interactive maps of 
train stations for KDE Itinerary.

https://invent.kde.org/libraries/kosmindoormap

KOSMIndoorMap has been growing inside the KPublicTransport repo (due to some 
building blocks being available there alreay and me being lazy), and has now 
been split into its own repo. So technically this is coming out of a reviewed 
repo already rather than from playground, but better be on the safe side :)

The aim is having this (together with KPublicTransport and KDE Itinerary) join 
the release service for 20.12.

Thanks,
Volker

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

[Volker Krause]

On Saturday, 20 June 2020 08:20:18 CEST Ben Cooksley wrote:
> Hi all,
> 
> This weekend parts of our CI system shifted to using Qt 5.15, with all
> FreeBSD builds now being based on Qt 5.15. We also shifted all Linux
> builds of Plasma, and the latest Qt version build of Frameworks to Qt
> 5.15 as well (apologies for the massive amount of email this kicked
> up)
> 
> It has however exposed a series of SIC changes in Qt which will need
> to be adapted to. The list of affected projects appears to be as
> follows:
> - kalarm
> - kdesdk-kioslaves
> - kompare
> - subtitlecomposer

all fixed

> - kaffeine

This doesn't look like something caused by Qt 5.15, more like an issue with 
the FreeBSD DVB headers, builds on Linux.

> In addition, the following projects appear to have long standing build
> issues. It would be appreciated if they could please investigate and
> correct these:
> - kbibtex

fixed

> - atcore
> - kmymoney

MSVC-only, or rather GCC/clang being a bit too forgiving. 

atcore looks like an ambiguous default argument, removing that should fix it, 
but since this is a public interface I didn't want to just change this, being 
unable to estimate the impact.

kmymoney is using an exported class in two DLLs with the same export macro, 
that doesn't work. Needs more insights into the project to restructure that 
accordingly I think.

> - ring-kde

build errors seem to be in stuff downloaded by cmake!?

> Further, the following project appears to have a broken build due to
> SIC changes within another KDE project:
> - zanshin

fixed

Regards,
Volker

Re: Banning QNetworkAccessManager

[Volker Krause]

On Wednesday, 19 February 2020 10:04:11 CET Ben Cooksley wrote:
> On Wed, Feb 19, 2020 at 9:30 PM Volker Krause  wrote:
> > On Wednesday, 19 February 2020 08:05:01 CET Ben Cooksley wrote:
> > > On Mon, Feb 3, 2020 at 7:42 AM Volker Krause  wrote:
> > > > I agree on the problem of QNAM's default, see also
> > > > https://conf.kde.org/en/
> > > > akademy2019/public/events/135 on that subject.
> > > > 
> > > > On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
> > > > [...]
> > > > 
> > > > > Prior to now, i've taken the approach of advertising that
> > > > > QNetworkAccessManager is broken and needs a flag set within
> > > > > applications when used, however unfortunately this seems to have
> > > > > been
> > > > > an ineffective approach and cases of broken behaviour continue to
> > > > > appear (despite this brokeness being known about and advertised
> > > > > since
> > > > > back in the Qt 4.x series when this class was introduced)
> > > > > 
> > > > > Therefore, given the Qt Project is unlikely to change their position
> > > > 
> > > > > on this, I would like to propose the following:
> > > > The Qt Project is actually in favor of changing at least the
> > > > redirection
> > > > default to exactly what we want it to be.
> > > > https://codereview.qt-project.org/c/qt/qtbase/+/273175 has the change,
> > > > and
> > > > got approval both by Lars and one of the maintainers. It is merely
> > > > stuck
> > > > in dealing with the unit test fallout in Qt's CI that somebody has to
> > > > take care of. Doesn't immediately help us of course, but claiming Qt
> > > > is
> > > > unwilling to change this is simply wrong.
> > > > 
> > > > > 1) That effective immediately, QNetworkAccessManager and it's
> > > > > children
> > > > > classes be banned and prohibited within KDE software, to be enforced
> > > > > by server side hooks.
> > > > > 2) That we fork QNetworkAccessManager and the associated classes
> > > > > within the appropriate Framework (to be determined), where the
> > > > > defective behaviour can then be corrected.
> > > > 
> > > > While this might solve the redirection problem, it brings us yet
> > > > another
> > > > then unmaintained HTTP implementation next to the one in KIO, which is
> > > > a
> > > > far bigger problem long term. We need less of those, not more.
> > > > 
> > > > To address the problem of people not using the correct defaults, I did
> > > > propose a much less extreme approach in the above mentioned talk at
> > > > Akademy, namely having a KNetworkAccessManager as a sub-class of QNAM
> > > > in
> > > > a low-tier frameworks that essentially just enables redirects and
> > > > HSTS.
> > > > QNAM's implementation isn't the problem after all, the defaults are.
> > > > 
> > > > Commit hooks warning about QNAM usage might still be a good idea, but
> > > > as a
> > > > warning only. Hard blocking QNAM-using code would block at least three
> > > > repos I spend a lot of time on currently, none of which even talks to
> > > > KDE
> > > > servers.
> > > > 
> > > > If you need to take more drastic measures against code not doing this
> > > > correctly regardless, you can do that my dropping the server-side
> > > > workarounds. Yes, that would break the affected application possibly,
> > > > but
> > > > at least it would not cause massive collateral damage for the people
> > > > using this correctly.
> > > > 
> > > > It would also help to know where specifically we have that problem, so
> > > > we
> > > > can actually solve it, and so we can figure out why we failed to fix
> > > > this
> > > > there earlier.
> > > 
> > > Just bringing this up again - it seems we've not had much movement on
> > > this aside from the Wiki page.
> > > 
> > > Examining that Qt merge request, it not only is targeted at just Qt
> > > 6.x, it also hasn't had any movement since the start of October 2019 -
> > > 4 months ago.
> > > Given that we are going to be on Qt 5.x for some time, that merge
> > > requ

Re: Banning QNetworkAccessManager

[Volker Krause]

On Wednesday, 19 February 2020 08:05:01 CET Ben Cooksley wrote:
> On Mon, Feb 3, 2020 at 7:42 AM Volker Krause  wrote:
> > I agree on the problem of QNAM's default, see also
> > https://conf.kde.org/en/
> > akademy2019/public/events/135 on that subject.
> > 
> > On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
> > [...]
> > 
> > > Prior to now, i've taken the approach of advertising that
> > > QNetworkAccessManager is broken and needs a flag set within
> > > applications when used, however unfortunately this seems to have been
> > > an ineffective approach and cases of broken behaviour continue to
> > > appear (despite this brokeness being known about and advertised since
> > > back in the Qt 4.x series when this class was introduced)
> > > 
> > > Therefore, given the Qt Project is unlikely to change their position
> > 
> > > on this, I would like to propose the following:
> > The Qt Project is actually in favor of changing at least the redirection
> > default to exactly what we want it to be.
> > https://codereview.qt-project.org/c/qt/qtbase/+/273175 has the change, and
> > got approval both by Lars and one of the maintainers. It is merely stuck
> > in dealing with the unit test fallout in Qt's CI that somebody has to
> > take care of. Doesn't immediately help us of course, but claiming Qt is
> > unwilling to change this is simply wrong.
> > 
> > > 1) That effective immediately, QNetworkAccessManager and it's children
> > > classes be banned and prohibited within KDE software, to be enforced
> > > by server side hooks.
> > > 2) That we fork QNetworkAccessManager and the associated classes
> > > within the appropriate Framework (to be determined), where the
> > > defective behaviour can then be corrected.
> > 
> > While this might solve the redirection problem, it brings us yet another
> > then unmaintained HTTP implementation next to the one in KIO, which is a
> > far bigger problem long term. We need less of those, not more.
> > 
> > To address the problem of people not using the correct defaults, I did
> > propose a much less extreme approach in the above mentioned talk at
> > Akademy, namely having a KNetworkAccessManager as a sub-class of QNAM in
> > a low-tier frameworks that essentially just enables redirects and HSTS.
> > QNAM's implementation isn't the problem after all, the defaults are.
> > 
> > Commit hooks warning about QNAM usage might still be a good idea, but as a
> > warning only. Hard blocking QNAM-using code would block at least three
> > repos I spend a lot of time on currently, none of which even talks to KDE
> > servers.
> > 
> > If you need to take more drastic measures against code not doing this
> > correctly regardless, you can do that my dropping the server-side
> > workarounds. Yes, that would break the affected application possibly, but
> > at least it would not cause massive collateral damage for the people
> > using this correctly.
> > 
> > It would also help to know where specifically we have that problem, so we
> > can actually solve it, and so we can figure out why we failed to fix this
> > there earlier.
> 
> Just bringing this up again - it seems we've not had much movement on
> this aside from the Wiki page.
> 
> Examining that Qt merge request, it not only is targeted at just Qt
> 6.x, it also hasn't had any movement since the start of October 2019 -
> 4 months ago.
> Given that we are going to be on Qt 5.x for some time, that merge
> request can't be considered to be the 'fix' for this issue.

The targeting of Qt6 is due to this aiming at dev when that was still Qt 5.x, 
but you are right of course, somebody needs to do the work there to drive this 
to completion, no matter in which version it will actually land.

> We need a solution that will ensure software released today doesn't
> cause us pain in several years time, because as I illustrated in an
> earlier email to this thread, software has a habit of remaining in use
> for an extremely long amount of time (August 2014 being the release
> date of the Marble versions in question hitting that old URL).
> 
> The easiest path forward is to simply ban QNetworkAccessManager.

That might be the easiest path for you, but certainly not for me, given two of 
the modules I work on most atm are using QNAM (not even to talk to KDE 
infrastructure), and would suddenly no longer be allowed to be hosted here?

Also, I have yet to see a suggestion for a viable alternative to QNAM. The 
initially proposed fork would mean trading the possibility of broken redirect 
handling for an unmain

Re: Banning QNetworkAccessManager

[Volker Krause]

On Monday, 3 February 2020 10:49:10 CET David Edmundson wrote:
> I updated:
> 
> https://community.kde.org/Policies/API_to_Avoid
> 
> Which had no mention of this.

Thanks for taking care of this! 

I'd propose a slightly different approach than the per-request all-or-nothing 
attribute mentioned in the wiki though, using the redirection policy on QNAM, 
which prevents redirects to non-TLS connections:

nam->setRedirectPolicy(QNetworkRequest::NoLessSafeRedirectPolicy);

And while we are at it, let's also enable HSTS:

nam->setStrictTransportSecurityEnabled(true); 
nam->enableStrictTransportSecurityStore(true); 


Regards,
Volker

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

Re: Banning QNetworkAccessManager

[Volker Krause]

I agree on the problem of QNAM's default, see also https://conf.kde.org/en/
akademy2019/public/events/135 on that subject.

On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
[...]
> Prior to now, i've taken the approach of advertising that
> QNetworkAccessManager is broken and needs a flag set within
> applications when used, however unfortunately this seems to have been
> an ineffective approach and cases of broken behaviour continue to
> appear (despite this brokeness being known about and advertised since
> back in the Qt 4.x series when this class was introduced)
> 
> Therefore, given the Qt Project is unlikely to change their position
> on this, I would like to propose the following:

The Qt Project is actually in favor of changing at least the redirection 
default to exactly what we want it to be.
https://codereview.qt-project.org/c/qt/qtbase/+/273175 has the change, and got 
approval both by Lars and one of the maintainers. It is merely stuck in 
dealing with the unit test fallout in Qt's CI that somebody has to take care 
of. Doesn't immediately help us of course, but claiming Qt is unwilling to 
change this is simply wrong.

> 1) That effective immediately, QNetworkAccessManager and it's children
> classes be banned and prohibited within KDE software, to be enforced
> by server side hooks.
> 2) That we fork QNetworkAccessManager and the associated classes
> within the appropriate Framework (to be determined), where the
> defective behaviour can then be corrected.

While this might solve the redirection problem, it brings us yet another then 
unmaintained HTTP implementation next to the one in KIO, which is a far bigger 
problem long term. We need less of those, not more.

To address the problem of people not using the correct defaults, I did propose 
a much less extreme approach in the above mentioned talk at Akademy, namely 
having a KNetworkAccessManager as a sub-class of QNAM in a low-tier frameworks 
that essentially just enables redirects and HSTS. QNAM's implementation isn't 
the problem after all, the defaults are.

Commit hooks warning about QNAM usage might still be a good idea, but as a 
warning only. Hard blocking QNAM-using code would block at least three repos I 
spend a lot of time on currently, none of which even talks to KDE servers.

If you need to take more drastic measures against code not doing this 
correctly regardless, you can do that my dropping the server-side workarounds. 
Yes, that would break the affected application possibly, but at least it would 
not cause massive collateral damage for the people using this correctly.

It would also help to know where specifically we have that problem, so we can 
actually solve it, and so we can figure out why we failed to fix this there 
earlier.

Regards,
Volker


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

Re: KDE Itinerary in kdereview

[Volker Krause]

Thanks for the feedback so far!

This has now exceeded the 2 weeks period, the only unaddressed feedback 
(unless I missed something else) is the one from Sandro about having a release 
before being able to pass kdereview. Ben's input on this however seems to 
confirm my understanding that this is rather the other way around, and 
therefore not blocking passing review.

Unless there's any objection I'd therefore move this to extragear/pim within 
the next days, and then look into getting everything needed for this under the 
release service umbrella.

Thanks,
Volker

On Sunday, 8 December 2019 13:14:43 CET Volker Krause wrote:
> Hi,
> 
> KDE Itinerary has been moved to kdereview:
> 
> Code: https://invent.kde.org/kde/itinerary
> Workboard: https://phabricator.kde.org/project/board/280/query/all/
> 
> KDE Itinerary is a Kirigami-based mobile application for managing your
> itinerary as a timeline, including access to your travel documents, tickets
> and boarding passes, real-time updates for train connections, weather
> forecast along your trip, etc.
> 
> Its destination for now is probably extragear/pim, but becoming part of the
> release service eventually would be desirable.
> 
> There are binary factory nightly builds for Android and Flatpak for easy
> testing. It can import travel documents directly, but for the optimal
> experience this is best used together with the KMail Itinerary plug-in and a
> Nextcloud/DavDroid calendar or KDE Connect.
> 
> Thanks,
> Volker



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

Re: Exemptions to try KF "grow" vs. consistent experience (Re: Submitting Grantlee as a KF5 Framework)

[Volker Krause]

On Thursday, 26 December 2019 19:25:09 CET Albert Astals Cid wrote:
> El dimarts, 24 de desembre de 2019, a les 13:05:23 CET, Friedrich W. H. 
Kossebau va escriure:
> > Am Montag, 23. Dezember 2019, 09:57:57 CET schrieb Volker Krause:
> > > On Sunday, 22 December 2019 09:46:02 CET Dominik Haumann wrote:
> > > > Hi all,
> > > > 
> > > > in any case, maybe the discussed points should go to the KF6
> > > > workboard?
> > > > https://phabricator.kde.org/project/view/310/
> > > > 
> > > > I indeed believe that consistency in the KF5 world is an important
> > > > feature,
> > > > so Friedrich does have a point here. Other framework additions had to
> > > > adapt
> > > > as well (what comes to my mind is renaming of KQuickCharts or
> > > > KCalendarCore).
> > > 
> > > There is one important difference between KCalendarCore/KQuickCharts/etc
> > > and Grantlee/QKeychain/etc though. The former had no previous release
> > > promising a public API and therefore only KDE-internal users. The
> > > latter have such releases and guarantees, and a significant
> > > KDE-external user base. That's what makes me consider a transitional
> > > pragmatic exemption from certain conventions, if we assume it would
> > > help to grow our external user base, and thus the pool of potential
> > > contributors.
> > 
> > Having to make exemptions shows a principal design flaw though: if the
> > idea is to pull in more libraries into KF, incl. some with previous
> > releases & thus existing userbase hoping on longer-term stable ABI, the
> > same will also happen in the KF6 series. And even for the currently
> > discussed two libs Grantlee & QKeychain it means at least 1 1/2 years &
> > longer (assuming KF 6.0.0 is coming then, and see how long kdelibs4
> > survived) for being just "exemptions". It's rather that the "exemptions"
> > become part of the rules that way.
> Which kind of exceptions are we speaking about?
> 
> ABI stability? or?

The opposite actually :) It's about keeping existing API/ABI of frameworks 
with a significant (KDE external) user base when joining KF5, until the next 
major release, even if that means making compromises regarding e.g. our naming 
conventions.

Regards,
Volker


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

Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

[Volker Krause]

On Sunday, 22 December 2019 09:46:02 CET Dominik Haumann wrote:
> Hi all,
> 
> in any case, maybe the discussed points should go to the KF6 workboard?
> https://phabricator.kde.org/project/view/310/
> 
> I indeed believe that consistency in the KF5 world is an important feature,
> so Friedrich does have a point here. Other framework additions had to adapt
> as well (what comes to my mind is renaming of KQuickCharts or
> KCalendarCore).

There is one important difference between KCalendarCore/KQuickCharts/etc and 
Grantlee/QKeychain/etc though. The former had no previous release promising a 
public API and therefore only KDE-internal users. The latter have such 
releases and guarantees, and a significant KDE-external user base. That's what 
makes me consider a transitional pragmatic exemption from certain conventions, 
if we assume it would help to grow our external user base, and thus the pool 
of potential contributors.
 
> Whatever decision is made here, imho there should/must be the objective to
> get it fixed for KF6.

Absolutely.

Regards,
Volker

> Best regards
> Dominik
> 
> Friedrich W. H. Kossebau  schrieb am So., 22. Dez. 2019,
> 
> 00:55:
> > Am Samstag, 21. Dezember 2019, 23:32:10 CET schrieb Stephen Kelly:
> > > On 21/12/2019 19:12, Friedrich W. H. Kossebau wrote:
> > > > Am Samstag, 21. Dezember 2019, 13:03:17 CET schrieb Stephen Kelly:
> > > >> Great, Grantlee is now available at g...@git.kde.org:grantlee.git.
> > > >> 
> > > >> I've pushed a few commits to make it depend on ECM etc.
> > > >> 
> > > >> Once the review period is finished it can be part of KF5 releases.
> > > > 
> > > > There are quite some things which yet need to be done for now:
> > > > to be a true KF module there is a set of policies which needs to be
> > 
> > met,
> > 
> > > > see https://community.kde.org/Frameworks/Policies
> > > > 
> > > > 1) Framework directory structure:
> > > > moving stuff into src/, autotests/ & docs/
> > > > 
> > > > 2) Framework documentation:
> > > > current system needs adaption to both online (KApiDox) and
> > > > offline (ECMAddQCH) systems
> > > 
> > > Cool, I wonder if there's another multi-library framework for
> > > comparison?
> > 
> > With ECMAddQCH, Sonnet & KNewStuff create separate QCH files for their
> > multiple libs.
> > 
> > With KApiDox, IIRC it has the assumption 1 module <=> 1 documentation unit
> > (not involved there),
> > Olivier (cc:ed) should be able to hint you what is possible.
> > 
> > > > Another challenge would be moving into the KF5 namespace for the
> > 
> > library
> > 
> > > > artifacts (at least I would expect/recommend this to happen, for
> > > > consistent
> > > > user experience)
> > > > a) include dirs below subdir KF5/
> > > > b) CMake modules with KF5 prefix
> > > > c) CMake imported target in KF5 namespace
> > > 
> > > I don't support changing things like this in the KF5 timeframe.
> > 
> > IMHO not sharing the namespace "KF5" spoils the story of KDE Frameworks,
> > where
> > the namespace gives consistent developer experience and product messaging.
> > 
> > Having Grantlee being a special kid, with unregular CMake modules names
> > and
> > differently namespace imported CMake targets, makes things more complex.
> > 
> > Being consistent is what we so like about Qt, and KF should not stay
> > behind,
> > no?
> > 
> > Perhaps joining the "Release Service" (formerly known as "KDE
> > Applications")
> > is a better place then, it also contains a set of libraries already.
> > That would serve the purpose of having releases happening regularly.
> > 
> > Cheers
> > Friedrich



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

Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

[Volker Krause]

On Saturday, 21 December 2019 20:12:48 CET Friedrich W. H. Kossebau wrote:
> Am Samstag, 21. Dezember 2019, 13:03:17 CET schrieb Stephen Kelly:
> > Great, Grantlee is now available at g...@git.kde.org:grantlee.git.
> > 
> > I've pushed a few commits to make it depend on ECM etc.
> > 
> > Once the review period is finished it can be part of KF5 releases.
> 
> There are quite some things which yet need to be done for now:
> to be a true KF module there is a set of policies which needs to be met, see
> https://community.kde.org/Frameworks/Policies
> 
> 1) Framework directory structure:
>moving stuff into src/, autotests/ & docs/
> 2) Framework documentation:
>current system needs adaption to both online (KApiDox) and
>offline (ECMAddQCH) systems
> 
> I could do 1) if you like, and help with 2) on the ECMAddQCH part.
> 
> Another challenge would be moving into the KF5 namespace for the library
> artifacts (at least I would expect/recommend this to happen, for consistent
> user experience)
> a) include dirs below subdir KF5/
> b) CMake modules with KF5 prefix
> c) CMake imported target in KF5 namespace
> 
> Now, the question is if we want Grantlee to be backwards-compatible after
> the move into KDE Frameworks, or if some breakage is possible?
> 
> When it comes to CMake targets & modules, the first challenge is:
> 
> Grantlee5 supports components, "Templates" & "TextDocument". To allow people
> doing e.g.
> --- 8< ---
> find_package(Grantlee5 CONFIG COMPONENTS Templates)
> --- 8< ---
> So when Grantlee becomes a component in KF5 itself, so people would use for
> finding it
> --- 8< ---
> find_package(KF5 CONFIG COMPONENTS Grantlee)
> --- 8< ---
> these two, "Templates" & "TextDocument", would need to become subcomponents.
> Which though is a concept CMake does not support.
> 
> So what to do here? Split Grantlee into two separate libs, with separate
> CMake config files? Done by KF5NewStuff, where one repo provides 2 separate
> configs. Or just merge and do not allow making dep chain more narrow
> (Grantlee's TextDocument pulls in QtGui as dep, so fails if no devel
> package not present)?
> 
> 
> Then Grantlee's CMake module brings two namespaced imported targets:
> * Grantlee5::Templates
> * Grantlee5::TextDocument
> With Grantlee being part of KDE Frameworks, one would expect to have targets
> named like
> * KF5::GrantleeTemplates
> * KF5::GrantleeTextDocument
> or similar.
> 
> Just, seems CMake does not expect the use case of exporting targets with
> different names, there is only one property available to set the base name,
> cmp. current
> --- 8< ---
> set_property(TARGET Grantlee_Templates PROPERTY EXPORT_NAME Templates)
> --- 8< ---
> So when wanting to keep backward compatibility, we are stuck here with the
> old basenames.
> Do you know any simple trick to have a separate CMake config file with
> separate imported targets, which still refer to the same library executable?
> Never done myself, so no idea what could be done. Doing a separate target
> and exporting that one will fail possibly once trying to set OUTPUT_NAME
> property to the same,
> Perhaps one could do a manual cmake config file which has the old one as
> find_dependency and then defines an alias target on the imported target?

Backward compatibility with new frameworks coming in with an existing internal 
and external user base is a good question though, this also came up with 
QKeychain recently.

That is, do we break ABI/API as part of the inclusion into Frameworks, to make 
them fully comply with all Framework policies, or do we allow for exemptions 
for the current major release in this case? Ultimately it's a tradeoff between 
ease of migration for existing code bases (which aren't just our own, but also 
those of the users the new framework brings in), and consistency in 
Frameworks.

I'm undecided on this myself still:

* Consistency is an important part of the Frameworks product story (even if we 
aren't perfectly following this everywhere).

* Attracting external components and having them opt to move under the 
Frameworks umbrella is a sign that we are doing things right IMHO. So let's 
make this easy for people and avoid scaring off their users by forcing a 
larger migration on them when joining Frameworks.

* We are less than two years away from KF6, a time where people expect to have 
to do a larger migration anyway. Deferring some of the necessary changes to 
then might be a compromise that works for now.

Thoughts?

Thanks,
Volker

PS: @Steve: I missed the doxygen discussion on IRC earlier, customizing 
doxygen is possible via docs/Doxyfile.local, which just gets appended to the 
Doxyfile from kapidox IIUC, maybe that helps already?

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

Re: KDE Itinerary in kdereview

[Volker Krause]

On Friday, 20 December 2019 22:50:54 CET Sandro Knauß wrote:
> Hi,
> 
> > KDE Itinerary has been moved to kdereview:
> > 
> > Code: https://invent.kde.org/kde/itinerary
> > Workboard: https://phabricator.kde.org/project/board/280/query/all/
> > 
> > KDE Itinerary is a Kirigami-based mobile application for managing your
> > itinerary as a timeline, including access to your travel documents,
> > tickets
> > and boarding passes, real-time updates for train connections, weather
> > forecast along your trip, etc.
> > 
> > Its destination for now is probably extragear/pim, but becoming part of
> > the
> > release service eventually would be desirable.
> 
> I thought, that a release entering kdereview needs at least one release, but
> I haven't found any release tarballs nor tags. This is at least blocks us
> from getting it into Debian.

My understanding so far was that we are not supposed to do releases from 
playground? That impression is supported by playground projects usually not 
having CI coverage. So one of the main motivations for moving through 
kdereview now is to actually become able to do releases.

Regards,
Volker

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

Re: KDE Itinerary in kdereview

[Volker Krause]

On Monday, 9 December 2019 11:33:43 CET Jonathan Riddell wrote:
> Looking good
> 
> It's more common to name COPYING as COPYING.LIB when it is the LGPL
> 
> In the appdata file org.kde.itinerary.desktop  it's better to use
> an id without the .desktop on the end since that's unnecessary
> 
> And it's missing the launchpable tag
> 
> org.kde.$NAME.desktop recommended, see
> https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-l
> aunchable 
> 
> The wiki page should maybe be named after the app not the library
> https://community.kde.org/KDE_PIM/KItinerary

Thanks, all of the above should be fixed now.

Regards,
Volker

> On Sun, 8 Dec 2019 at 12:16, Volker Krause  wrote:
> > Hi,
> > 
> > KDE Itinerary has been moved to kdereview:
> > 
> > Code: https://invent.kde.org/kde/itinerary
> > Workboard: https://phabricator.kde.org/project/board/280/query/all/
> > 
> > KDE Itinerary is a Kirigami-based mobile application for managing your
> > itinerary as a timeline, including access to your travel documents,
> > tickets
> > and boarding passes, real-time updates for train connections, weather
> > forecast
> > along your trip, etc.
> > 
> > Its destination for now is probably extragear/pim, but becoming part of
> > the
> > release service eventually would be desirable.
> > 
> > There are binary factory nightly builds for Android and Flatpak for easy
> > testing. It can import travel documents directly, but for the optimal
> > experience this is best used together with the KMail Itinerary plug-in and
> > a
> > Nextcloud/DavDroid calendar or KDE Connect.
> > 
> > Thanks,
> > Volker



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

Re: KDE Itinerary in kdereview

[Volker Krause]

On Sunday, 8 December 2019 14:07:57 CET Christophe Giboudeaux wrote:
> Hey,
> 
> On dimanche 8 décembre 2019 13:14:43 CET Volker Krause wrote:
> > Hi,
> > 
> > KDE Itinerary has been moved to kdereview:
> > 
> > Code: https://invent.kde.org/kde/itinerary
> > Workboard: https://phabricator.kde.org/project/board/280/query/all/
> 
> COPYING.LIB contains the LGPL 2.1 license. The files in the repo are
> LGPL-2.0- or-later
> 
> src/extractors/irctc.js doesn't have a license header (compared to the other
> js files in this folder)

Both valid issues (and fixed), but in a different repo :)

The COPYING issue also existed in the itinerary repo, fixed there as well.

Regards,
Volker

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

KDE Itinerary in kdereview

[Volker Krause]

Hi,

KDE Itinerary has been moved to kdereview:

Code: https://invent.kde.org/kde/itinerary
Workboard: https://phabricator.kde.org/project/board/280/query/all/

KDE Itinerary is a Kirigami-based mobile application for managing your 
itinerary as a timeline, including access to your travel documents, tickets 
and boarding passes, real-time updates for train connections, weather forecast 
along your trip, etc.

Its destination for now is probably extragear/pim, but becoming part of the 
release service eventually would be desirable.

There are binary factory nightly builds for Android and Flatpak for easy 
testing. It can import travel documents directly, but for the optimal 
experience this is best used together with the KMail Itinerary plug-in and a 
Nextcloud/DavDroid calendar or KDE Connect.

Thanks,
Volker

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

Re: Submitting Grantlee as a KF5 Framework

[Volker Krause]

Hi,

very happy to see Grantlee "coming home" :)

Technically I think it's largely in line with Frameworks requirements already, 
and it has been reliably powering e.g. KMail's message viewer for years. 
Moving to a faster and, more importantly, predictable release cycle would help 
us a lot with upstreaming extensions and improvements though, and would allow 
us to get rid of some repeated code in applications.

Longer term I'd also hope we can add the support for QtGui types (icons, 
colors, palettes, etc) that is currently spread around application code, 
either as a plugin in the Grantlee repo directly, or as a tier 2 framework on 
top.

So, definitely a +1 from me!

Regards,
Volker

On Friday, 6 December 2019 22:36:09 CET Stephen Kelly wrote:
> Hello,
> 
> I have been developing Grantlee for over 10 years with contributions
> from a community of others mostly connected with KDE.
> 
>   https://github.com/steveire/grantlee
> 
> I have not been able to maintain a reasonable release cadence of
> Grantlee in the last few years (last release 3 years ago), so I'm
> submitting Grantlee to KDE Review with the aim of addition to KDE
> Frameworks.
> 
> Grantlee consists of two libraries,
> 
> * Grantlee::Templates is a text-template system based on Qt introspection
> * Grantlee::TextDocument is a builder design pattern implementation for
> processing QTextDocuments
> 
> Grantlee is already a dependency of several KDE applications, but it is
> treated as an external dependency. This change would make it a Tier 1
> KDE Framework.
> 
> $ apt-cache rdepends libgrantlee-templates5
> libgrantlee-templates5
> Reverse Depends:
>libgrantlee5-dev
>skrooge
>rocs
>libkf5pimcommon5abi3
>libkf5messageviewer5abi5
>libkf5messageviewer-plugins
>libkf5kaddressbookgrantlee5
>libkf5grantleetheme5
>libkf5grantleetheme-plugins
>libkf5calendarutils5abi1
>libkf5calendarutils-bin
>kdepim-addons
>kjots
>khelpcenter
>kdevelop52-libs
>kdevelop
> $ apt-cache rdepends libgrantlee-textdocument5
> libgrantlee-textdocument5
> Reverse Depends:
>libgrantlee5-dev
>libkf5pimtextedit5abi3
>libkf5messageviewer5abi5
>libkf5messagecomposer5abi2
>kjots
> 
> 
> My intention is to make one more release of Grantlee myself before
> turning it into a KDE Frameworks repository.
> 
> I don't think much needs to change in terms of the C++ code.  The
> namespace would remain Grantlee:: etc, so that releases made from KDE
> Frameworks will be binary compatible with previous Grantlee5 releases.
> 
> However, I've not been putting time into making releases (The last
> release was over 3 years ago).
> 
> This is a proposal to submit Grantlee as a KF5 repository. It should be
> a natural addition to the KF5 ecosystem. This move will mean:
> 
> * Grantlee will be released regularly as part of KF5
> * All KDE contributors will have the commit bit to make changes
> * My guilt about lack of releases will be reduced
> 
> Grantlee::Templates depends on QtQml for script bindings (can be
> disabled at build time).
> Grantlee::TextDocument depends only on QtGui.
> 
> 
> I'm not quite familiar with what needs to happen to complete this
> transition. It seems to me that something along these lines ought to do it:
> 
> * I make one last release of Grantlee myself
> * Set up a new KDE repository for me to push to
> * Integrate KF5 buildsystem into Grantlee (ECM for example)
> * Set up CI for that repository
> * Set up doxygen generation for the repository
> * Transfer grantlee.org to KDE sysadmin
> 
> Grantlee already has ki18n integration in the form of a library
> implementing Grantlee abstractions:
> 
>   https://cgit.kde.org/grantleetheme.git/about/
> 
> Initial reviews and comments welcome!
> 
> Thanks,
> 
> Stephen.


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

Re: Blacklisting of PIM from the CI system

[Volker Krause]

On Tuesday, 3 December 2019 22:13:43 CET Allen Winter wrote:
> On Tuesday, December 3, 2019 2:52:31 PM EST Volker Krause wrote:
> > The complexity of the dependency graph is also a problem for onboarding
> > new
> > people, and with kdelibs4support gone IMHO the largest technical dept
> > here.
> > It's being worked on, albeit slowly, currently we are losing ~1 module per
> > release I think.
> 
> Silly questions
> 
> Why do we need 50-60 repos to build kontact?
> why not 1 repo for kontact and all its stuff? (I miss kdepim)
> 
> do Krita or any of the other large applications have so many repositories
> devoted to them?
> 
> After all these years since the svn->git move I still understand why so many
> repostitories for Kontact. For frameworks it makes sense, but I don't get
> it for applications

50 repos for this is too much IMHO, I agree. There's reasons for not having 
this in a single one though, one being that various parts are used externally 
as well (former kdepimlibs basically). This is what we try to address with 
moving things to Frameworks. There's also things like Akonadi or Kleo being 
used externally though, that's much harder to Frameworkify.

And then there are a few obsolete reasons, like the refactoring done for 
Kontact Mobile 10 years ago, or for Kube.

Another aspect to look at is whether those repos have a well defined scope. 
Good examples are IMHO eventviews/incidenceeditor, bad ones are libkdepim/
kdepim-apps-libs/pimcommon/etc. The former hurt much less than the latter I 
think.

The strategy discussed at the PIM meetings for this is two-fold: continue with 
Frameworkification of the well-scoped and externally used modules, and try to 
dissolve the libraries with undefined scope by moving stuff to more 
appropriate places. Especially the latter isn't exactly a fun job, therefore 
this is progressing very slowly.

Going to a mono repo setup would make building easier for PIM contributors, 
but it would not solve the problem for new people to find their way through 
the various libraries with unclear scope, so IMHO this is a problem we have to 
address regardless of the repo layout.

Regards,
Volker

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

Re: Blacklisting of PIM from the CI system

[Volker Krause]

On Sunday, 1 December 2019 04:00:19 CET Ben Cooksley wrote:
> On Sun, Dec 1, 2019 at 10:17 AM Volker Krause  wrote:
> > On Saturday, 30 November 2019 19:14:38 CET Ben Cooksley wrote:
[...]
> > > Fixing the current set of failures will not prevent this blacklisting
> > > action from being carried out - as a recurring issue it needs a
> > > permanent solution.
> > 
> > What do you envision this permanent solution to look like?
> 
> It's hard to say.
> 
> Given the current problem, which is changes being actively made that
> break the build, the ideal solution would be the developers who are
> making these breakages to actively keep an eye on their jobs on the CI
> system.

That isn't an entirely fair statement IMHO, the changes triggering this were 
perfectly fine with either the latest Frameworks release or a recent enough 
master, just not the delayed master we had available on the CI at this point. 
Seeing this hit other master-tracking builds too (e.g. OpenSuse in #kontact 
this morning), I completely agree though this needs a better solution overall.

Tracking the latest release would be one approach, but from direct discussion 
I understand that's currently not a viable solution due to Plasma's needs. Not 
allowing changes for master compatibility (with the corresponding version 
#ifdefs) is also counter-productive though, as it prevents early testing of 
Frameworks changes (even if just locally). So the best I can think of is 
making sure this situation is widely enough understood, and we have a way to 
find out which exact revisions of Frameworks are deployed. Then we can maybe 
get to the point where we can defer such commits until a recent enough 
revision is available, which IIUC would usually take 48-72h.

> To avoid the issue with 'transient' failures due to new functions, etc
> being introduced to libraries then being used immediately in other
> projects, i'd suggest that the developers introduce a delay (30
> minutes should be sufficient) between the pushes to give the system a
> chance to build the updated libraries. 

Agreed, for many people that's already standard practice I think.

> In the long run it would be
> nice to shrink the size of the PIM dependency graph, either through
> consolidating repositories or reorganising the code to cut the number
> of dependencies, which would reduce the number of times you'd need to
> wait.

The complexity of the dependency graph is also a problem for onboarding new 
people, and with kdelibs4support gone IMHO the largest technical dept here. 
It's being worked on, albeit slowly, currently we are losing ~1 module per 
release I think.

Regards,
Volker

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

Re: Blacklisting of PIM from the CI system

[Volker Krause]

On Sunday, 1 December 2019 04:00:19 CET Ben Cooksley wrote:
> On Sun, Dec 1, 2019 at 10:17 AM Volker Krause  wrote:
> > sigh...
> > 
> > On Saturday, 30 November 2019 19:14:38 CET Ben Cooksley wrote:
> > [...]
> > 
> > > Which is where the problem with PIM comes in - because it currently
> > > has many repositories failing to build from source on all platforms
> > > those builds are enabled for (including Linux and FreeBSD).
> > 
> > looking at this right now, at least three errors seem transient (ie. a
> > manual rebuild "fixed" them), one I can't explain yet is this one:
> > 
> > https://build.kde.org/job/Applications/view/Everything/job/kpimtextedit/jo
> > b/ kf5-qt5%20SUSEQt5.12/39/console
> > 
> > This is about using new API in KF 5.65, but the use is guarded by a
> > corresponding version check #ifdef. Which KF5 is the CI building against,
> > latest release, latest master, or maybe something in between (the latter
> > would explain this)?
> 
> The CI system essentially uses the latest master of Frameworks - with
> the slight catch of it the build being up to a week out of date.
> The Frameworks build is updated by the "Dependency Build" jobs that
> run for each Product/Branch/Platform combination once a week.
> 
> The last time the Dependency Build job ran for the Applications
> kf5-qt5 SUSEQt5.12 combination was about 2 days ago.
> https://build.kde.org/job/Administration/job/Dependency%20Build%20Applicatio
> ns%20kf5-qt5%20SUSEQt5.12/40/console
> 
> Unfortunately this run failed due to breakage in 'pimcommon'.
> Before it failed, it did get the chance to build Sonnet so that is up
> to date as of the date of that build.

I suspect that's where the problem is. The "missing" commit from Sonnet is 
from Nov 26, the dependency build is from Nov 28, yet the kpimtextedit build 
still "sees" the old version.

The same problem also exists with kwidgetaddons and korganizer/knotes.

I looked in the code of those cases, and tested this locally. This builds 
against 5.64 and latest 5.65, when I switch frameworks to something in between 
I can reproduce the issues we are seeing on the CI here too. Not sure how to 
fix that in the code, I can't version-check for this...

> > > Given that the PIM project mailing list is emailed by the CI system,
> > > and that the changes in one case were pushed over 2 days ago, there is
> > > no excuse for this series of build failures.
> > 
> > I try to actively look at the CI state every 24h, however that sometimes
> > fails when I'm on the road or otherwise busy. I do see the email
> > notifications, but
> Thanks for doing so.
> 
> > given the high number of transient failures (usually due to unfortunately
> > timed dependency bumps), they are of limited use for me for raising an
> > alarm in cases of actual breakage.
> 
> *nod*
> 
> With regards to the dependency bumps, the best way to avoid these is
> to first bump version numbers, and then increase the dependency
> requirements in the projects in a second round of commits, pushed
> separately, once the version bump builds have finished. This is from
> my understanding how David does it for Frameworks and it works
> flawlessly.
> 
> This solution has been proposed in the past, but was rejected by the
> PIM team who insisted that it was the CI system that should instead
> sequence the builds correctly (something which is unscalable to
> implement, and from my understanding impossible with Gitlab CI)

I agree with that solution, and it's how I try to do dependency bumps when 
necessary.

(I'll reply to the ideas how to improve the situation going forward 
separately/later, I'm in a rush now, sorry).

Regards,
Volker

> > > In addition to all of the above, this round of updates was to lay the
> > > ground work for adding additional dependencies which are necessary for
> > > the builds of Digikam and SubtitleComposer to commence on the CI
> > > system for Windows. These failures by PIM have therefore indirectly
> > > harmed other KDE projects.
> > > 
> > > As this is not the first time that PIM has caused issues in this
> > > manner, I would therefore like to proceed with blacklisting PIM from
> > > the CI system. This would include prohibiting other projects from
> > > depending on any part of PIM, so those projects that have a required
> > > dependency on PIM would also have their builds removed by this.
> > 
> > Of course stuff tends to break more often when you look at 50+ actively
> > developed repos compared to a single barely alive one. And yes, I do very
> &g

Re: Blacklisting of PIM from the CI system

[Volker Krause]

sigh...

On Saturday, 30 November 2019 19:14:38 CET Ben Cooksley wrote:
[...]
> Which is where the problem with PIM comes in - because it currently
> has many repositories failing to build from source on all platforms
> those builds are enabled for (including Linux and FreeBSD).

looking at this right now, at least three errors seem transient (ie. a manual 
rebuild "fixed" them), one I can't explain yet is this one:

https://build.kde.org/job/Applications/view/Everything/job/kpimtextedit/job/
kf5-qt5%20SUSEQt5.12/39/console

This is about using new API in KF 5.65, but the use is guarded by a 
corresponding version check #ifdef. Which KF5 is the CI building against, 
latest release, latest master, or maybe something in between (the latter would 
explain this)?

I'll look through the rest as time permits.

> Given that the PIM project mailing list is emailed by the CI system,
> and that the changes in one case were pushed over 2 days ago, there is
> no excuse for this series of build failures.

I try to actively look at the CI state every 24h, however that sometimes fails 
when I'm on the road or otherwise busy. I do see the email notifications, but 
given the high number of transient failures (usually due to unfortunately 
timed dependency bumps), they are of limited use for me for raising an alarm 
in cases of actual breakage.

> In addition to all of the above, this round of updates was to lay the
> ground work for adding additional dependencies which are necessary for
> the builds of Digikam and SubtitleComposer to commence on the CI
> system for Windows. These failures by PIM have therefore indirectly
> harmed other KDE projects.
> 
> As this is not the first time that PIM has caused issues in this
> manner, I would therefore like to proceed with blacklisting PIM from
> the CI system. This would include prohibiting other projects from
> depending on any part of PIM, so those projects that have a required
> dependency on PIM would also have their builds removed by this.

Of course stuff tends to break more often when you look at 50+ actively 
developed repos compared to a single barely alive one. And yes, I do very well 
understand that this can be frustrating.

> Whilst I would prefer another solution to this, given that it is a
> recurring issue that makes maintenance of the CI system substantially
> harder, I see the removal of PIM from the equation as the only
> reasonable path forward.
> 
> Should the PIM developers wish to avoid this consequence for their
> actions, they will need to provide an action plan as to how this will
> be avoided in the future.

I cannot realistically promise more than what I am already doing on this (as 
outlined above), the combination of me not able to pay enough attention to the 
CI state and things blowing up in multiple repos on the same day is very rare 
though. If that's not enough, others need to help here as well.

> Fixing the current set of failures will not prevent this blacklisting
> action from being carried out - as a recurring issue it needs a
> permanent solution.

What do you envision this permanent solution to look like?

Regards,
Volker

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

Re: KF6 Sprint

[Volker Krause]

Hi,

we have a date and venue by now: November 22 - 24 at the MBition office in 
Berlin (Dovestraße 1, 10587 Berlin), that's right after the Qt Contributor 
Summit to reduce travel overhead a bit. Thanks to Eike and Agustin for making 
this possible!

Please subscribe to https://phabricator.kde.org/T11535 and indicate there if 
you are going to attend. And please encourage people not on the list yet that 
should be there to attend.

Help in organizing this is also still very much needed (e.g. finding 
accommodation and dealing with e.V. reimbursements), despite how this may look 
like, I'm just passing messages here ;-)

I'd also again encourage everyone to put topics and ideas for KF6 into the KF6 
workboard (https://phabricator.kde.org/project/board/310/query/all/), which 
will help to make the sprint as effective as possible.

Thanks,
Volker


On Sunday, 15 September 2019 13:14:28 CET Volker Krause wrote:
> Hi,
> 
> as you might have seen in David's summary of the KF6 BoF at Akademy
> (https://
> mail.kde.org/pipermail/kde-frameworks-devel/2019-September/093298.html),
> there's the idea to have a KF6 sprint, along the lines of the KF5 sprint we
> had in Randa a few years back, to determine what we actually want to
> achieve with KF6 beyond just porting to Qt6.
> 
> If you are interested please subscribe to https://phabricator.kde.org/T11535
> and indicate your interest to participate, as well as times that would work
> for you. I'm not just looking at the current KF5 contributors for this, but
> also those of you heavily using KF5.
> 
> If you are willing to help organize the sprint, please indicate so there
> too, help with that would be greatly appreciated (I'm not organizing this,
> I'm just writing this email because Albert asked me too ;-) ).
> 
> With Qt 6 planned for Nov 2020 we are probably looking at a 18-24 month time
> frame towards KF6, so it's time to get this going.
> 
> Regards,
> Volker



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

Re: ELF Dissector in kdereview

[Volker Krause]

I haven't recently tested it on 32bit ARM, I pushed a possible fix using a 
similar approach that has been applied for x86 already. If that doesn't help I 
need to find a 32bit ARM setup again here to properly debug it.

Regards,
Volker

On Tuesday, 29 October 2019 11:29:44 CET Jonathan Riddell wrote:
> I'm getting a build failure for this on 32-bit arm
> 
> https://build.neon.kde.org/job/bionic_unstable_neon-packaging_elf-dissector_
> bin_armhf/7/console
> 
> disassembler.cpp:149:34: error: ‘print_insn_little_arm’ was not
> declared in this scope
> 
> Is it expected to build on this architecture?  It builds fine on 64 bit arm.
> 
> 
> Jonathan
> 
> On Sun, 27 Oct 2019 at 09:27, Volker Krause  wrote:
> > Thanks again for the feedback, this has now been moved to extragear/sdk.
> > 
> > On Saturday, 28 September 2019 13:01:11 CET Volker Krause wrote:
> > > Hi,
> > > 
> > > ELF Dissector has been moved to kdereview for the usual review process.
> > > 
> > > https://phabricator.kde.org/source/elf-dissector/
> > > 
> > > ELF Dissector is a static analysis tool for ELF libraries and
> > 
> > executables,
> > 
> > > for doing things like inspecting forward and backward dependencies (on a
> > > library or symbol level), identifying load-time performance bottlenecks
> > > such as expensive static constructors or excessive relocations, or size
> > > profiling of ELF files.
> > > 
> > > ELF Dissector has been living in playground for more than 6 years
> > 
> > because I
> > 
> > > was sloppy following the right process. Since it's in active use by a
> > 
> > number
> > 
> > > of people, is actively maintained and remains relevant and useful I
> > > think
> > > it's time to finally rectify this :)
> > > 
> > > Regarding its final destination, extragear/sdk looks like the obvious
> > > candidate, as its such a niche tool that being part of the KDE
> > 
> > Application
> > 
> > > bundle is probably hard to argue. Once KDE Applications and the "release
> > > service" are sufficiently decoupled, I'd of course be more than happy to
> > > have it covered by the automatic release process.
> > > 
> > > Regarding distribution, there is one annoying aspect, its dependency on
> > > semi- public binutils API for accessing the C++ symbol demangling AST.
> > 
> > That
> > 
> > > works on conventional Linux distributions, but I failed to make it work
> > 
> > as
> > 
> > > a Flatpak due to that.
> > > 
> > > Regarding portability, this currently only builds on ELF-based systems,
> > > although theoretically this could be useful on a Windows host used for
> > > embedded Linux development too. It's not impossible to make this work
> > > eventually I think, but it's probably quite some work.
> > > 
> > > Thanks,
> > > Volker



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

Re: KPublicTransport in kdereview

[Volker Krause]

This has passed the two week mark, if there are no objections I'd move this to 
extragear/lib next week.

Thanks,
Volker

On Saturday, 12 October 2019 12:54:31 CET Volker Krause wrote:
> Hi,
> 
> KPublicTransport has been moved to kdereview:
> 
> https://phabricator.kde.org/source/kpublictransport/
> 
> KPublicTransport is a library for accessing real-time public transport
> information (location, departure and journey queries) via a C++ or QML API,
> aggregating results from Navitia.io as well as a few vendor-specific
> backends.
> 
> KPublicTransport originated inside KDE Itinerary but was split out at the
> beginning of this year based on demand from KTrip. In order to get both apps
> released eventually we need a release of KPublicTransport, therefore the
> promotion out of playground now.
> 
> While KPublicTransport aims to become a framework, it's not mature enough
> for committing to API stability yet I think, so the more appropriate
> destination for now would probably be extragear/lib I guess. Becoming part
> of the release service once that is decoupled from the Applications product
> would be very much appreciated though.
> 
> At this point this is would be classified as a Tier 1 Functional framework,
> I expect this to change though once we need translated strings, which will
> become necessary for offering a way for the user to select which backends
> to use.
> 
> Regards,
> Volker



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

Re: ELF Dissector in kdereview

[Volker Krause]

On Thursday, 17 October 2019 23:31:32 CEST Christophe Giboudeaux wrote:
> Hello,
> 
> Minor issue with the license file. COPYING.LIB contains the LGPL 2.1 license
> text while elf-dissector is LGPL-2.0-or-later
> 
> COPYING has a few differences compared to
> https://www.gnu.org/licenses/old-licenses/gpl-2.0-standalone.html. Does it
> come from treemap?

Thanks for checking this! COPYING.LIB has been fixed. COPYING has been synced 
to the one in KCacheGrind where the treemap code is taken from, but the 
differences seemed rather cosmetic.

Regards,
Volker

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

Re: ELF Dissector in kdereview

[Volker Krause]

On Saturday, 12 October 2019 13:56:12 CEST Friedrich W. H. Kossebau wrote:
> Am Samstag, 12. Oktober 2019, 12:46:19 CEST schrieb Volker Krause:
> > From the feedback everything should be addressed, apart from the 
following:
> ...
> * "hicolor" icons for the app icon are not yet added & installed
>   (proposal: copy over the breeze ones for now, like done for e.g.
> heaptrack)

indeed, fixed now.

Thanks,
Volker


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

Re: KPublicTransport in kdereview

[Volker Krause]

On Sunday, 13 October 2019 17:24:50 CEST Albert Astals Cid wrote:
> El dissabte, 12 d’octubre de 2019, a les 12:54:31 CEST, Volker Krause va 
escriure:
> > Hi,
> > 
> > KPublicTransport has been moved to kdereview:
> > 
> > https://phabricator.kde.org/source/kpublictransport/
> > 
> > KPublicTransport is a library for accessing real-time public transport
> > information (location, departure and journey queries) via a C++ or QML
> > API,
> > aggregating results from Navitia.io as well as a few vendor-specific
> > backends.
> > 
> > KPublicTransport originated inside KDE Itinerary but was split out at the
> > beginning of this year based on demand from KTrip. In order to get both
> > apps released eventually we need a release of KPublicTransport, therefore
> > the promotion out of playground now.
> > 
> > While KPublicTransport aims to become a framework, it's not mature enough
> > for committing to API stability yet I think, so the more appropriate
> > destination for now would probably be extragear/lib I guess. Becoming
> > part of the release service once that is decoupled from the Applications
> > product would be very much appreciated though.
> 
> Had a look, didn't find anything obviously wrong.
> 
> The only thing is that the public API returns const & to vectors, which
> we've historically not done since it ties you to having a vector internally
> forever, but i'm fine accepting that
> 
> Micro minor thing, clang tidy said
> 
> src/backends/abstractbackend.cpp:199:16: error: the const qualified variable
> 'headers' is copy-constructed from a const reference; consider making it a
> const reference
> [performance-unnecessary-copy-initialization,-warnings-as-errors] const
> auto headers = netReply->rawHeaderPairs();

Thanks for reviewing, this has been fixed.

Regards,
Volker

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

KPublicTransport in kdereview

[Volker Krause]

Hi,

KPublicTransport has been moved to kdereview:

https://phabricator.kde.org/source/kpublictransport/

KPublicTransport is a library for accessing real-time public transport 
information (location, departure and journey queries) via a C++ or QML API, 
aggregating results from Navitia.io as well as a few vendor-specific backends.

KPublicTransport originated inside KDE Itinerary but was split out at the 
beginning of this year based on demand from KTrip. In order to get both apps 
released eventually we need a release of KPublicTransport, therefore the 
promotion out of playground now.

While KPublicTransport aims to become a framework, it's not mature enough for 
committing to API stability yet I think, so the more appropriate destination 
for now would probably be extragear/lib I guess. Becoming part of the release 
service once that is decoupled from the Applications product would be very 
much appreciated though.

At this point this is would be classified as a Tier 1 Functional framework, I 
expect this to change though once we need translated strings, which will 
become necessary for offering a way for the user to select which backends to 
use.

Regards,
Volker



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

Re: ELF Dissector in kdereview

[Volker Krause]

Thanks for the feedback so far!

This has reached the two week mark, if there are no objections I'd move this 
to extragear/sdk next week.

>From the feedback everything should be addressed, apart from the following:
- blog: will be done for the release, last one on that subject is https://
volkerkrause.eu/2019/06/22/elf-dissector-aarch64-support.html
- differential view features: makes a lot of sense, not just for the ABI 
review use-case, but it's a significant amount of additional work that 
shouldn't block the review or a release.
- support for older Qt versions: I don't mind somebody adding that, but I 
don't have the bandwidth to maintain that myself. Again, IMHO not a review or 
release blocker.

Regards,
Volker

On Saturday, 28 September 2019 13:01:11 CEST Volker Krause wrote:
> Hi,
> 
> ELF Dissector has been moved to kdereview for the usual review process.
> 
> https://phabricator.kde.org/source/elf-dissector/
> 
> ELF Dissector is a static analysis tool for ELF libraries and executables,
> for doing things like inspecting forward and backward dependencies (on a
> library or symbol level), identifying load-time performance bottlenecks
> such as expensive static constructors or excessive relocations, or size
> profiling of ELF files.
> 
> ELF Dissector has been living in playground for more than 6 years because I
> was sloppy following the right process. Since it's in active use by a number
> of people, is actively maintained and remains relevant and useful I think
> it's time to finally rectify this :)
> 
> Regarding its final destination, extragear/sdk looks like the obvious
> candidate, as its such a niche tool that being part of the KDE Application
> bundle is probably hard to argue. Once KDE Applications and the "release
> service" are sufficiently decoupled, I'd of course be more than happy to
> have it covered by the automatic release process.
> 
> Regarding distribution, there is one annoying aspect, its dependency on
> semi- public binutils API for accessing the C++ symbol demangling AST. That
> works on conventional Linux distributions, but I failed to make it work as
> a Flatpak due to that.
> 
> Regarding portability, this currently only builds on ELF-based systems,
> although theoretically this could be useful on a Windows host used for
> embedded Linux development too. It's not impossible to make this work
> eventually I think, but it's probably quite some work.
> 
> Thanks,
> Volker



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

Re: Work Branches

[Volker Krause]

On Saturday, 5 October 2019 04:11:11 CEST Ben Cooksley wrote:
> Hi all,
> 
> Recently we had a discussion (which I think may have ended up spread
> over a couple of mailing lists in the end) concerning branches and the
> ability to force push to them.
> 
> Current policy forbids force pushing to branches except in very
> limited circumstances (essentially where it is the only option to fix
> a branch)
> 
> The discussion ended with two ways forward, but no 100% clear
> consensus on which way we want to go forward. The two proposed ways
> were:
> 1) Only protect 'master' and declared 'stable' branches.
> 2) Protect all branches, aside from a given prefix (proposed to be work/)
> 
> I'd like to clean this up and sort out the policy we want to have
> surrounding this so we can move forward.
> 
> From my perspective i'd rather we go with Option 2, as this will be
> the approach that will be easier to both implement and maintain in the
> long term and be the least likely to cause collaboration problems (as
> the branch naming conventions will be universal across all our
> repositories).
> 
> Thoughts?

+1, sounds good to me :)

Thanks,
Volker

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

Re: ELF Dissector in kdereview

[Volker Krause]

On Tuesday, 1 October 2019 14:06:57 CEST Jonathan Riddell wrote:
> The file src/3rdparty/treemap/treemap.cpp is GPL while the rest of the
> application is LGPL.  This makes the whole application copyable under only
> the terms of the GPL.  It would be good to have COPYING moved to
> COPYING.LIB and a GPL text put in COPYING.
> src/ui/org.kde.elf-dissector.appdata.xml should also be changed to be
> GPL-2.0-or-later

Thanks! Should be fixed now too.

Regards,
Volker

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

Re: ELF Dissector in kdereview

[Volker Krause]

On Tuesday, 1 October 2019 17:28:03 CEST Thiago Macieira wrote:
> On Tuesday, 1 October 2019 05:06:57 PDT Jonathan Riddell wrote:
> > -isystem
> > /usr/include/capstone/..
> 
> [...]
> 
> > /usr/include/c++/7/cstdlib:75:15: fatal error: stdlib.h: No such file or
> > directory
> 
> That -isystem is the mistake.

Yep, that would be my guess as well. I've pushed a possible fix for this.

Regards,
Volker

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

Re: ELF Dissector in kdereview

[Volker Krause]

Thanks for the feedback :)

On Sunday, 29 September 2019 12:51:03 CEST Albert Astals Cid wrote:
> El dissabte, 28 de setembre de 2019, a les 13:01:11 CEST, Volker Krause va 
escriure:
> > Hi,
> > 
> > ELF Dissector has been moved to kdereview for the usual review process.
> 
> It doesn't build for me, i need
> 
> -#include 
> +#include 
> 
> Because my include is in
>   /usr/include/capstone/capstone.h
> and
>   pkg-config --cflags capstone
> returns empty.

Fixed, their pkgconfig file differs based on version and used build system, we 
can handle both now.

> clang-tidy says
>   src/ui/mainwindow.cpp:120:29: error: std::move of the const variable
> 'fileName' has no effect; remove std::move() or make the variable non-const
> [performance-move-const-arg,-warnings-as-errors] m_currentFileName =
> std::move(fileName);
> So
> -const auto fileName =
> settings.value(QStringLiteral("Recent/PreviousFile")).toString(); +   
> auto fileName =
> settings.value(QStringLiteral("Recent/PreviousFile")).toString(); i guess?
> 
> 
>   src/lib/checks/ldbenchmark.cpp:161:20: error: Value stored to 'file'
> during its initialization is never read
> [clang-analyzer-deadcode.DeadStores,-warnings-as-errors] const auto file =
> m_fileSet->file(m_results.size() - 1 - i);

Both fixed.

>   src/lib/printers/relocationprinter.cpp:416:8: error: Excessive padding in
> 'struct RelocTypeRepository' (8 padding bytes, where 0 is optimal). Optimal
> fields order:
>   typeInfos,
>   machine,
>   typeInfosSize,
> consider reordering the fields or adding explicit padding members
> [clang-analyzer-optin.performance.Padding,-warnings-as-errors] (Annoying i
> know, but isn't elf-dissector a bit about this padding things too?)

Fixed. Kinda ironic, considering ELF Dissector was (to my knowledge) the first 
tool out there that could find such memory layout issues for more complex C++ 
types too (apart from virtual inheritance, the memory layout for that is ... 
interesting), way before clang got that warning (which of course is the much 
better place for this) :)

> Also you have a few deprecated Qt calls.

Seems mostly from the treemap copy, updated to the latest version.

Regards,
Volker


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

ELF Dissector in kdereview

[Volker Krause]

Hi,

ELF Dissector has been moved to kdereview for the usual review process.

https://phabricator.kde.org/source/elf-dissector/

ELF Dissector is a static analysis tool for ELF libraries and executables, for 
doing things like inspecting forward and backward dependencies (on a library 
or symbol level), identifying load-time performance bottlenecks such as 
expensive static constructors or excessive relocations, or size profiling of 
ELF files.

ELF Dissector has been living in playground for more than 6 years because I 
was sloppy following the right process. Since it's in active use by a number 
of people, is actively maintained and remains relevant and useful I think it's 
time to finally rectify this :)

Regarding its final destination, extragear/sdk looks like the obvious 
candidate, as its such a niche tool that being part of the KDE Application 
bundle is probably hard to argue. Once KDE Applications and the "release 
service" are sufficiently decoupled, I'd of course be more than happy to have 
it covered by the automatic release process.

Regarding distribution, there is one annoying aspect, its dependency on semi-
public binutils API for accessing the C++ symbol demangling AST. That works on 
conventional Linux distributions, but I failed to make it work as a Flatpak 
due to that.

Regarding portability, this currently only builds on ELF-based systems, 
although theoretically this could be useful on a Windows host used for 
embedded Linux development too. It's not impossible to make this work 
eventually I think, but it's probably quite some work.

Thanks,
Volker

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

KF6 Sprint

[Volker Krause]

Hi,

as you might have seen in David's summary of the KF6 BoF at Akademy (https://
mail.kde.org/pipermail/kde-frameworks-devel/2019-September/093298.html), 
there's the idea to have a KF6 sprint, along the lines of the KF5 sprint we 
had in Randa a few years back, to determine what we actually want to achieve 
with KF6 beyond just porting to Qt6.

If you are interested please subscribe to https://phabricator.kde.org/T11535 
and indicate your interest to participate, as well as times that would work 
for you. I'm not just looking at the current KF5 contributors for this, but 
also those of you heavily using KF5.

If you are willing to help organize the sprint, please indicate so there too, 
help with that would be greatly appreciated (I'm not organizing this, I'm just 
writing this email because Albert asked me too ;-) ).

With Qt 6 planned for Nov 2020 we are probably looking at a 18-24 month time 
frame towards KF6, so it's time to get this going.

Regards,
Volker

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

Re: binary compatibility and qwidget::event

[Volker Krause]

On Friday, 12 July 2019 11:24:35 CEST Harald Sitter wrote:
> But why was that BIC to begin with? Which of the "don'ts" did it violate?

IIUC re-implementing a virtual method from a base class (in absence of 
complications like multi-inheritance or co-variant return types) does not 
change the ABI (it changes vtable content, but not vtable layout).

It does however create cases where old binaries still call the old methods 
(see https://community.kde.org/Policies/
Binary_Compatibility_Issues_With_C%2B%2B#Adding_a_reimplemented_virtual_function).
 
That might not always be a relevant problem though.

In my understanding this is the same for the final -> !final case discussed in 
#plasma in this context. It does not impact the ABI at all (it does not even 
change vtable content), but some optimizations in old binaries might no longer 
reflect the new behavior.

Regards,
Volker

> On Fri, Jul 12, 2019 at 11:18 AM Kai Uwe Broulik  
wrote:
> > To avoid situations like [1] and [2]
> > 
> > [1]
> > https://cgit.kde.org/kiconthemes.git/commit/?id=1e9af6c54470e890597739f8f2
> > 189b0743a00b6f [2]
> > https://cgit.kde.org/kiconthemes.git/commit/?id=083bb8a80fd5941e6fcbaf1ec1
> > 2a08d8f8c881a5> 
> > Am 12.07.19 um 11:14 schrieb Harald Sitter:
> > > Hey
> > > 
> > > our binary compatibility page [1] states that one should
> > > 
> > > "reimplement event in QObject-derived classes, even if the body for
> > > the function is just calling the base class' implementation."
> > > 
> > > Does anyone know the reason this helps maintain BC?
> > > 
> > > [1]
> > > https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2
> > > B%2B
> > > 
> > > HS



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

Re: CI system maintainability

[Volker Krause]

On Friday, 29 March 2019 20:54:54 CET Ben Cooksley wrote:
> On Fri, Mar 29, 2019 at 6:45 AM Johannes Zarl-Zierl
> > I fear that a mandatory reviews would add too juch strain on smaller
> > teams. If there's just one person with an intimate knowledge of the
> > code-base, plus two co-developers, then who should do the reviews?
> > 
> > How about a distinction based on importance of a project instead? I.e.
> > mandatory reviews for frameworks and any app that wants to be included in
> > KDE apps releases. Non-mandatory reviews can then also come with a
> > "price" to pay: if CI errors are not dealt with in a timely manner, you
> > should be free to disable the CI for administrative reasons...
> While this does seem like a nice solution, unfortunately for many
> repositories it isn't a case of disabling CI coverage for it, but also
> CI coverage for everything that depends on it. In the case of
> KContacts, this would also impact on parts of Extragear and Calligra
> (who depending on their exact requirements would either lose a
> dependency being available, or lose all of their CI coverage).
> 
> This is why i've not pursued this as an option in the past, because
> it's not fair on other projects that don't have anything to do with
> another project aside from being a user of it's interfaces to lose
> their coverage, simply because the project they depend on is broken.

I agree that anything on the CI level would be merely a workaround for this at 
best. I'd rather suggest we address this at the source by turning the 
externally used modules into frameworks. We did that last year already for 
KHolidays and Syndication who were used by Plasma among others. KContacts, 
KCalCore and KMime should follow that next IMHO.

The next time window to do that relatively painlessly is coming up after the 
19.04 applications release I think, and all of those have been part of the 
KDE4-era kdepimlibs module that complied with KF5-like ABI guarantees, so the 
necessary work should be limited hopefully. Extra review of the public 
interfaces would certainly help with making this happen I think.

Regards,
Volker


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

Re: CI system maintainability

[Volker Krause]

On Friday, 29 March 2019 08:59:59 CET Kevin Ottens wrote:
> On Thursday, 28 March 2019 21:53:06 CET Alexander Neundorf wrote:
> > Having mandatory reviews for a central and complex component like akonadi
> > looks like a very good and obvious idea.
> 
> Yep.

Looking at the 18.12 -> 19.04 timeframe the majority of changes to Akonadi 
went through pre-commit review, even more so if you discard commits doing 
release work (version bumps etc) or similar maintenance not touching the 
actual logic.

And specifically the changes that caused us the most headaches due to 
introducing a nasty regression went through review.

Sure, nothing is perfect, but I don't think code review in Akonadi is the most 
pressing issue here.
 
> > OTOH if there is only one developer who is really expert for akonadi, this
> > makes it kind of unfeasible.
> 
> That's the chicken and egg problem we're in concerning KDEPIM. The developer
> story is frankly really harder than most software out there which makes it
> unlikely for people to pick it over something else for contributions.
> That's in part tied to your next point below and partly tied to
> documentation, on- boarding etc. The unwillingness to be slowed down is
> getting in the way of fixing that situation: to be a desirable project to
> contribute to you need to spend time advocating, documenting and taking
> newbies by the hand until they become regular contributors.
> 
> Yes it's tough, and TBH I'm guilty of not doing this more on my own
> projects. But on such a strategic piece of software like KDEPIM there's
> some responsibility in carrying those duties for the well being of the
> project.

How to address the issue of bus factor ~1 components in PIM is the real 
question here, I completely agree. But this is getting way off topic from 
Ben's original issue, and for the wide range of recipients. 

Also, I don't think overly generic statements on that help us much, so maybe 
let's discuss concrete steps for this at the sprint next week?

Regards,
Volker


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

Re: EBN Still Needed?

[Volker Krause]

On Thursday, 28 March 2019 09:23:21 CET Ben Cooksley wrote:
> On Thu, Mar 28, 2019 at 6:26 AM Volker Krause  wrote:
> > On Tuesday, 26 March 2019 21:15:31 CET Allen Winter wrote:
> > > I was notified today that the Krazy runs on the EBN have been stuck (due
> > > to
> > > a stale lockfile) for over 3 months.   Is this an indication that nobody
> > > looks at the EBN reports any longer?
> > > 
> > > I still maintain Krazy and am happy to make modifications, but I don't
> > > see
> > > the point unless someone actually reads and acts on the reports.
> > > 
> > > Note that clazy does replace Krazy on most everything (C++) so it could
> > > very well be that people are relying on Clazy instead of Krazy.
> > > 
> > > This is not about the API dox generation side of things, which of course
> > > we
> > > keep.
> > > 
> > > But has the EBN code and documentation checking service out lived its
> > > usefulness? Shut it down?
> > 
> > I think for the C++ checks it's indeed due to Clazy/clang-tidy
> > outperforming Krazy, both in terms of precision and in runtime
> > performance. And for code I'm working on I usually run these tools
> > locally indeed.
> > 
> > However Krazy is more than C++ checks, and EBN is more than Krazy. I do
> > think it's very valuable to have the infrastructure to do "global" scans
> > on all our repositories, see e.g. the work in D19996 for finding insecure
> > http: links anywhere (code, docs, website content, infrastructure config,
> > etc). Continuous checks in commit hooks or the CI will help us to catch
> > newly introduced issues there, but it wont help in getting this fixed
> > everywhere in the existing repos.
> 
> Couldn't the CI runs produce as part of their output reports which
> would contain historical issues as well as checking to see if the
> state had regressed?
> (Ideally this would be from a state of no issues)

For the repositories checked by the CI this will actually automatically happen 
with the proposed approach in D19996, as that injects the test via ECM.

This will run the "passive" check only and is quite fast (essentially just a 
regular expression). There's also a more elaborate "active" check that 
verifies DNS and TLS for all found URLs, that takes considerably longer to run 
and bothers external servers, so probably not something we want to execute 
continuously. The active check also benefits from (low frequency) re-runs, as 
its failures can be caused by external services finally upgrading to support 
TLS, or going away entirely, even if we have no changes on our side.

Regarding starting from a no issue state, we are unfortunately far away from 
that, despite aggressively excluding things like the license headers. I do 
agree though that enabling this as a unit test via ECM, or in another way on 
the CI for that matter, should not happen before the amount of remaining 
issues is more manageable. I certainly don't want to knowingly switch 200+ 
modules to yellow on the CI ;-)

One aspect I'm not sure yet how to handle best in the CI context are non-code 
repos. We have found a number of http issues in there too, repo metadata is 
one such example, and I'm sure website content would benefit from this check 
too.

If the infrastructure for supporting this is called "CI" or "EBN" doesn't 
really matter to me, I just wanted to point out possible use-cases that go 
somewhat beyond classical build and code checks :)

Regards,
Volker



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

Re: CI system maintainability

[Volker Krause]

On Thursday, 28 March 2019 16:11:12 CET Friedrich W. H. Kossebau wrote:
> Am Donnerstag, 28. März 2019, 14:33:59 CET schrieb laurent Montel:
> > For example I works all days on kde (pim or other) when I wake up, or at
> > noon after my lunch or the evening, I will not wait several days for a
> > review because nobody has time to do it.
> > 
> > (For example I make ~ 15 commits by days on pim/ruqola/framework, I don't
> > want to wait several days/weeks until someone wants to review my patchs)
> 
> Something might be lost in translation here, do you think, because you work
> daily on code of KDE projects, and other people (so potential reviewers) do
> not, this is an argument to do instant pushes of unreviewed commits?
> 
> While I understand one can get impatient if not getting instant review of
> changes one would like to depend on with further changes (I know this well
> :) ), still this seems a flawed argument at least for
> part-time-contributors based KDE projects, where the people one co-operates
> with only have time now and then, like once per week. It could be seen
> unfair & ignorant to them if one simply ignores their opinion, because one
> has more time reserved/ available.

I don't think any of that was meant here. The scenario that Laurent has in 
mind I think, and that I'm facing too, is that putting up a few dozen patches 
a week in a single repository for review and then having to wait for the 
review timeout because there's nobody else working on it is not even remotely 
practical, let alone with the current toolset of arc/phab.

> Not sure where this is from, but often I have seen an unwritten policy
> applied where people for a patch uploaded for review after one week of no
> response add a ping and then wait another week, before finally pushing the
> change. To me this seems a fair and reasonable policy, only ignores people
> who are on vacation for some more weeks or otherwise inactive, but I have
> not seen that ever been a real issue.

This works fine if you have less than a handful of patches in a single repo, 
and people actually review things. And we make plenty of use of that:
https://phabricator.kde.org/people/revisions/196/
https://phabricator.kde.org/people/revisions/208/

In fact I was just criticized last weekend at the privacy sprint for sending 
too many reviews ;-)

Regards,
Volker

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

Re: CI system maintainability

[Volker Krause]

On Thursday, 28 March 2019 16:32:34 CET Luca Beltrame wrote:
> In data giovedì 28 marzo 2019 15:15:23 CET, Nate Graham ha scritto:
> > In this case, it seems like the problem is that there are certain
> > individuals or teams that are pushing risky, breaking changes without code
> > review, and then ignoring failures in the CI. I think we might do well to
> > try to answer the question of why that's happening before we create a new
> > rule aimed at stopping it.

That "risky breaking change" was a 5 line fix for a Qt 5.13 build issue that 
had been successfully deployed to multiple repos before. The failure was also 
not ignored but noticed and fixed within about an hour, just not in all 
affected branches.

> Well put. Review or not review, clearly something in the process has failed,
> and I suspect "friction" rather than actual bad-faith ignorance of the CI
> results.
> 
> So, perhaps to force myself out of the bikeshedding (mea culpa) on reviews,
> I'll steal Friedrich's points from another mail and put them here
> synthetically:
> 
> - Why are the CI mails ignored / filtered? Too many, hard to parse,
> difficult to interpret?
> - What can be done to have people look at them and make sure they don't
> overlook breakage?
> 
> At least for the second point, as I mentioned earlier in the thread,
> probably having the committer being mailed in case of failure (GitLab does
> this IIRC) might be better than just on the mailing list. The second
> approach is what we use in openSUSE, where I usually don't subscribe to
> failure notifications (almost 300 packages is overkill) but a bot starts
> pestering me with mails the moment build failures go unfixed (granted, the
> time scale is different).
> 
> For the first, I'd like people more involved in the development to say their
> word.

See my earlier mail in this thread on how this slipped through for me.

Regards,
Volker


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

Re: CI system maintainability

[Volker Krause]

On Thursday, 28 March 2019 09:50:47 CET Kevin Ottens wrote:
> Hello,
> 
> On Thursday, 28 March 2019 09:41:29 CET Luca Beltrame wrote:
> > In data giovedì 28 marzo 2019 09:29:22 CET, Kevin Ottens ha scritto:
> > > at your screen or pair with you" in the past. Clearly this compromise
> > > gets
> > > somewhat exploited and that's especially bad in the case of a fragile
> > > and
> > > central component like KDE PIM.
> > 
> > I'm not sure I agree. I can't speak for seasoned developers, but I've
> > found
> > myself in a situation (more than once) where the fix is trivial (compile
> > error, missing ";", etc) and being forced to go through review would (IMO)
> > unnecessarily raise friction.
> 
> I don't fully disagree with this (although I'd have stories on nefarious
> typos even for what was supposed to be a "trivial fix"). But it becomes a
> question of trade-off, IOW "how hurtful to the project mandatory reviews?"
> vs "how hurtful to the project a central component being very regularly
> broken?".
> 
> I'd argue we're loosing more with the current state of PIM than we'd loose
> with mandatory reviews.

Review all relevant changes is nice in theory, but for this to work you need 
at least two people spending comparable amount of time on this. I wish we had 
that luxury in KDE PIM.

It works to some extend for Akonadi between Dan and David, I don't see it 
working for Laurent on KMail or for me on KItinerary, there's simply not 
enough review bandwidth there.

Also, when looking at such drastic changes we should keep in mind the amount 
of changes that go in without trouble. There's always the risk of breakage 
when we change stuff with the best intentions of improving things, we need to 
deal with that no matter how many people review a change (see the nasty 
transaction lock regression in 18.12.x Akonadi).

What failed in this specific case is not the lack of review IMHO, I'm not sure 
I would have spotted the issue from the diff. It's also not that nobody cared, 
or that people ignored the issue. The underlying problem was fixed within 62 
minutes of its occurrence according to the Git log, it was however forgotten 
to push this to the 19.04 branch.

This resulted in a single build failure in the stable build for kcontacts, 
which I (and I guess others too) did not immediately act on. That does not 
mean it's being ignored, but for a change I did not do myself the overwhelming 
majority of failures is transient (as either the author fixes it upon being 
notified, or it's a dependency issue that will resolve itself with the next 
build).

That single build failure resulted in the dependent builds failing, which 
again I did not immediately act on as the error message made me believe it's 
the a dependency issue that will resolve itself. Combined with the fact that 
this is in the stable branch, which is less active than master, I had indeed 
not realized we have a persistent issue here that nobody else felt responsible 
for until I saw this email. At that point Laurent had already fixed it btw, 
which was a matter of a simple cherry-pick from master. If I missed other 
earlier communication about this somehow, I apologize of course.

So, yes, things went wrong and it's a valid question how to improve this going 
forward. But rather than questioning the usefulness of the CI or the entire 
development workflow, how about just simply pinging the people who feel 
responsible for the affected repos? It's not like we miss every single build 
issue after all. I simply might not always manage to keep the state of 120+ 
repos in various configurations in my head, and which of those needs most 
urgent attention (I for example broke half of binary factory's Android builds 
with a kpackage change recently, despite review, and yet have to find the time 
for a proper fix for that).

Regards,
Volker


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

Re: EBN Still Needed?

[Volker Krause]

On Tuesday, 26 March 2019 21:15:31 CET Allen Winter wrote:
> I was notified today that the Krazy runs on the EBN have been stuck (due to
> a stale lockfile) for over 3 months.   Is this an indication that nobody
> looks at the EBN reports any longer?
> 
> I still maintain Krazy and am happy to make modifications, but I don't see
> the point unless someone actually reads and acts on the reports.
> 
> Note that clazy does replace Krazy on most everything (C++) so it could
> very well be that people are relying on Clazy instead of Krazy.
> 
> This is not about the API dox generation side of things, which of course we
> keep.
> 
> But has the EBN code and documentation checking service out lived its
> usefulness? Shut it down?

I think for the C++ checks it's indeed due to Clazy/clang-tidy outperforming 
Krazy, both in terms of precision and in runtime performance. And for code I'm 
working on I usually run these tools locally indeed.

However Krazy is more than C++ checks, and EBN is more than Krazy. I do think 
it's very valuable to have the infrastructure to do "global" scans on all our 
repositories, see e.g. the work in D19996 for finding insecure http: links 
anywhere (code, docs, website content, infrastructure config, etc). Continuous 
checks in commit hooks or the CI will help us to catch newly introduced issues 
there, but it wont help in getting this fixed everywhere in the existing 
repos.

License compatibility/maitenance is another topic where global C++ independent 
scans are useful (and where krazy already has checks), e.g. to identify and 
fix the remaining GPLv2 only material (which is incompatible with GPLv3+ and 
Apache 2 licensed work).

Regards,
Volker

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

Re: Installing qml caches

[Volker Krause]

On Friday, 1 June 2018 13:10:57 CEST Alexander Volkov wrote:
> Hi all,
> 
> It would be nice to install .qmlc files in addition to .qml files to
> reduce start-up time of applications.
> They are generated with qmlcachegen. For Qt 5.11:
> qmlcachegen -o example.qmlc qxample.qml
> 
> Currently qml files are usually installed the following way:
> install(DIRECTORY qml/ DESTINATION ${KDE_INSTALL_QMLDIR}/org/kde/kcm)
> 
> So this could be changed to something like
> ecm_install_qml(qml org/kde/kcm)
> 
> I wonder whether someone already working on this or want to implement
> such a function?
> If not, I'll try to do it myself.

Qt 5.11 actually has something like this, but only covering QML files compiled 
in via qrc, see qtquick_compiler_add_resources() (I needed a very recent 5.11 
branch build though for this to work, post 5.11.1).

I have no performance measurements yet, but at least the package size goes up 
contrary to what one might expect, as the compiled binary is 2-3x larger than 
the (non-minified) QML source code. That space would be needed by the qmlc 
files anyway in the end though, so overall disk space cost goes down a bit 
once deployed.

With the QML sources no longer included you end up with a non-starting 
application after updating Qt though.

So, interesting for APKs etc where you fully control Qt, but probably not for 
distros.

Regards,
Volker

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

Re: Installing qml caches

[Volker Krause]

On Monday, 4 June 2018 03:26:34 CEST Aleix Pol wrote:
> On Fri, Jun 1, 2018 at 1:10 PM, Alexander Volkov  
wrote:
> > Hi all,
> > 
> > It would be nice to install .qmlc files in addition to .qml files to
> > reduce
> > start-up time of applications.
> > They are generated with qmlcachegen. For Qt 5.11:
> > qmlcachegen -o example.qmlc qxample.qml
> > 
> > Currently qml files are usually installed the following way:
> > install(DIRECTORY qml/ DESTINATION ${KDE_INSTALL_QMLDIR}/org/kde/kcm)
> > 
> > So this could be changed to something like
> > ecm_install_qml(qml org/kde/kcm)
> > 
> > I wonder whether someone already working on this or want to implement such
> > a function?
> > If not, I'll try to do it myself.
> > 
> > Cheers,
> > Alexander.
> 
> I'm not sure this makes sense, as far as I know it's not a
> binary-compatible format, so distros would have to recompile every
> application with qmlc files upon Qt update.

It might indeed not be useful for distros, but it looks like an interesting 
option to reduce the package size (as AFAIK we don't need to ship the qml 
files anymore then) and improve the first start performance for our APKs for 
example. Probably not the change with the highest impact/gain atm, but 
nevertheless worth exploring IMHO.

Regards,
Volker


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

Re: KUserFeedback in/on its way to KDE Review

[Volker Krause]

No objections? :) 

It's been three weeks now, can this proceed to extragear/libs?

On Saturday, 24 June 2017 11:37:49 CEST Volker Krause wrote:
> Hi,
> 
> I've asked for KUserFeedback to be moved to KDE Review, aiming for
> extragear/ libs initially, with a possible future option to continue on to
> frameworks.
> 
> KUserFeedback is a framework for gathering user feedback using application
> telemetry and targeted surveys while providing decent transparency and
> control to the user.
> 
> For more details see the previous announcement on this list here: https://
> marc.info/?l=kde-core-devel=149294623025111=2 Since then we also got a
> QML API and a few more data sources, and KUserFeedback has been shipped
> with the recent GammaRay 2.8 release.
> 
> Please review :)
> 
> Thanks!
> Volker



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

KUserFeedback in/on its way to KDE Review

[Volker Krause]

Hi,

I've asked for KUserFeedback to be moved to KDE Review, aiming for extragear/
libs initially, with a possible future option to continue on to frameworks.

KUserFeedback is a framework for gathering user feedback using application 
telemetry and targeted surveys while providing decent transparency and control 
to the user.

For more details see the previous announcement on this list here: https://
marc.info/?l=kde-core-devel=149294623025111=2 Since then we also got a QML 
API and a few more data sources, and KUserFeedback has been shipped with the 
recent GammaRay 2.8 release.

Please review :)

Thanks!
Volker

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

Re: Application usage statistics and targeted user surveys

[Volker Krause]

On Monday, 12 June 2017 01:56:21 CEST Aleix Pol wrote:
> On Sat, Jun 10, 2017 at 10:22 AM, Volker Krause <vkra...@kde.org> wrote:
> > On Tuesday, 6 June 2017 15:01:57 CEST Aleix Pol wrote:
> >> On Thu, May 25, 2017 at 4:42 PM, Volker Krause <vkra...@kde.org> wrote:
> >> > On Wednesday, 24 May 2017 17:38:22 CEST Aleix Pol wrote:
> >> >> On Tue, May 23, 2017 at 6:31 PM, Aleix Pol <aleix...@kde.org> wrote:
> >> >> Hey Volker, I figured out this one. Never mind.
> >> >> 
> >> >> I've done a proof of concept integrating it in Discover, here's 2
> >> >> patches:
> >> >> https://phabricator.kde.org/D5960
> >> >> https://phabricator.kde.org/D5961
> >> > 
> >> > There's still two aspects missing in the integration:
> >> > - configure Provider to actually submit (see productIdentifier,
> >> > feedbackServer and submissionInterval properties)
> >> > - probably add some data sources (in the current form you only get an
> >> > indication on how many users you have, and untargeted surveys, nothing
> >> > more)
> >> > 
> >> > The second point will need some more QML wrapper API. I'll look into
> >> > adding a QML plugin to KUserFeedback directly for this.
> >> > 
> >> >> Now to proceed I'd like to give a try to whole system including the
> >> >> server. Do you have documented how to set it up anywhere? Would make
> >> >> it easier.
> >> > 
> >> > INSTALL contains the deployment documentation, both for the full setup
> >> > with
> >> > authentication on an Apache server, and locally for unsecured testing
> >> > using
> >> > the built-in PHP server.
> >> > 
> >> > I've also got a playground server on my own infrastructure now that I
> >> > can
> >> > provide accounts for. And Jan has published his ongoing work on
> >> > creating a
> >> > Docker image for the server here:
> >> > https://github.com/KDAB/kuserfeedbackdocker
> >> > 
> >> > Regards,
> >> > Volker
> >> 
> >> Hi Volker,
> >> More noob feedback:
> >> I set up a local system I could tinkle with using your colleague's
> >> docker. Worked quite well. But, I was getting an issue, possibly fixed
> >> by this patch:
> >> https://phabricator.kde.org/D6117
> > 
> > This looks good, I'll try to get that path unit-tested to make sure this
> > works with sqlite too. However, you should not actually hit this path in
> > the first place, which is probably also why you are not seeing any data.
> > 
> >> Now I get to see things being sent on the UserFeedbackConsole
> >> application, but I only see timestamps. I added debug information to
> >> see what is being sent and (after updating the discover patch above)
> >> and I see all sort of data, being delivered. Is it being lost in the
> >> internets? Or am I not looking into it correctly? If I export the
> >> product using UserFeedbackConsole I also only get timestamps :(.
> > 
> > Do you see the empty columns for the other data in UserFeedbackConsole, or
> > do you only see the Timestamp column? In the former case the data is
> > either not transmitted, or rejected by the server for some reason, we'd
> > need to look at the JSON payload sent to the server in that case. In the
> > other case, you probably need to set up a product schema first with
> > UserFeedbackConsole (easiest via Schema -> Source Templates in the Schema
> > view).
> 
> Here's what I'm seeing: https://imgur.com/a/BmH2B
> I've seen the schema view, I haven't pushed it much. I see I can add
> stuff but I'm not sure what it's for. I expected the system to
> integrate all data offered, but maybe I need to set the expectations
> on the server side?

Yes, exactly, that's what the schema does. Easiest way to get started is 
probably to just import the orwell example schema there, that contains all 
existing data sources, or you just create sources from their corresponding 
templates.

That is, in the schema view chose schema -> import schema... or schema -> 
source template >  When you are done, select schema -> save schema to 
write the changes to the server. Afterwards you should see a lot more columns 
and more charts in the analytics view.

User documentation is still fairly limited on this, but there is a start of a 
user manual describing the data model, that should help to explain most of the 
options you ha

Re: Application usage statistics and targeted user surveys

[Volker Krause]

On Tuesday, 6 June 2017 15:01:57 CEST Aleix Pol wrote:
> On Thu, May 25, 2017 at 4:42 PM, Volker Krause <vkra...@kde.org> wrote:
> > On Wednesday, 24 May 2017 17:38:22 CEST Aleix Pol wrote:
> >> On Tue, May 23, 2017 at 6:31 PM, Aleix Pol <aleix...@kde.org> wrote:
> >> Hey Volker, I figured out this one. Never mind.
> >> 
> >> I've done a proof of concept integrating it in Discover, here's 2
> >> patches:
> >> https://phabricator.kde.org/D5960
> >> https://phabricator.kde.org/D5961
> > 
> > There's still two aspects missing in the integration:
> > - configure Provider to actually submit (see productIdentifier,
> > feedbackServer and submissionInterval properties)
> > - probably add some data sources (in the current form you only get an
> > indication on how many users you have, and untargeted surveys, nothing
> > more)
> > 
> > The second point will need some more QML wrapper API. I'll look into
> > adding a QML plugin to KUserFeedback directly for this.
> > 
> >> Now to proceed I'd like to give a try to whole system including the
> >> server. Do you have documented how to set it up anywhere? Would make
> >> it easier.
> > 
> > INSTALL contains the deployment documentation, both for the full setup
> > with
> > authentication on an Apache server, and locally for unsecured testing
> > using
> > the built-in PHP server.
> > 
> > I've also got a playground server on my own infrastructure now that I can
> > provide accounts for. And Jan has published his ongoing work on creating a
> > Docker image for the server here:
> > https://github.com/KDAB/kuserfeedbackdocker
> > 
> > Regards,
> > Volker
> 
> Hi Volker,
> More noob feedback:
> I set up a local system I could tinkle with using your colleague's
> docker. Worked quite well. But, I was getting an issue, possibly fixed
> by this patch:
> https://phabricator.kde.org/D6117

This looks good, I'll try to get that path unit-tested to make sure this works 
with sqlite too. However, you should not actually hit this path in the first 
place, which is probably also why you are not seeing any data.

> Now I get to see things being sent on the UserFeedbackConsole
> application, but I only see timestamps. I added debug information to
> see what is being sent and (after updating the discover patch above)
> and I see all sort of data, being delivered. Is it being lost in the
> internets? Or am I not looking into it correctly? If I export the
> product using UserFeedbackConsole I also only get timestamps :(.

Do you see the empty columns for the other data in UserFeedbackConsole, or do 
you only see the Timestamp column? In the former case the data is either not 
transmitted, or rejected by the server for some reason, we'd need to look at 
the JSON payload sent to the server in that case. In the other case, you 
probably need to set up a product schema first with UserFeedbackConsole 
(easiest via Schema -> Source Templates in the Schema view).

I'll also try your Discover patches here to see if I can reproduce this, the 
QML bindings haven't gotten any real use yet, quite possible some stuff 
doesn't work there correctly yet.

Regards,
Volker

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

Re: Application usage statistics and targeted user surveys

[Volker Krause]

On Thursday, 8 June 2017 01:36:44 CEST Aleix Pol wrote:
> On Thu, Jun 8, 2017 at 12:27 AM, Albert Astals Cid <aa...@kde.org> wrote:
> > El dissabte, 3 de juny de 2017, a les 11:49:00 CEST, Volker Krause va
> > 
> > escriure:
> >> On Thursday, 25 May 2017 12:33:49 CEST Volker Krause wrote:
> >> > On Tuesday, 23 May 2017 18:31:35 CEST Aleix Pol wrote:
> >> > > I would have looked into fixing it, but I'm not sure I understand why
> >> > > there's all the RPATH logic in place, so I'd prefer to hear from you
> >> > > first.
> >> > 
> >> > I have removed the remains of the pre-ECM rpath handling. This also
> >> > changed
> >> > binary output directories on Linux to follow KDE standards, so you
> >> > might
> >> > want to do a clean build to avoid issues with outdated binaries in the
> >> > build dir.
> >> > 
> >> > > A good next step would also be to get it running on build.kde.org, so
> >> > > we can identify these issues.
> >> > 
> >> > Indeed, I've requested CI coverage now.
> >> 
> >> Looks like in order to get CI coverage we need to move to kdereview
> >> (which
> >> is fine, I think it's ready for that), but that requires to know where
> >> this
> >> should end up afterwards.
> >> 
> >> I guess the candidates are extragear/libs or frameworks? frameworks seems
> >> conceptually like the right place, but putting something there that is
> >> still fairly new and has seen little field testing seems sub-optimal.
> >> Opinions?> 
> > To me it seems a few releases from extragear would make sense before
> > moving to frameworks and promise full API/ABI compatibility.

Sounds sensible to me, let's do that.

> > OTOH when moving from extreagear to frameworks we may have to rename
> > library (to have the KF5 suffix) which would break also API (at least at
> > the cmake level).
> > 
> > How do people feel having libs in extreager having the KF5 "cmake naming"
> > in the understanding that we're stabilizing them to be part of frameworks
> > eventually?
> 
> IMO it's a bit weird and unsettling. But then, we're already doing it
> for many pim libraries (not in extragear but in applications, still
> not part of KF5).

But isn't the rename the least of our problems if we start in extragear/libs 
exactly to be able to still do ABI, API and behavior changes until we are 
happy with things for frameworks?

I'll try to get all currently pending API changes in ASAP, and then get it 
moved to kdereview within this month.

Regards,
Volker


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

Re: Application usage statistics and targeted user surveys

[Volker Krause]

On Thursday, 25 May 2017 12:33:49 CEST Volker Krause wrote:
> On Tuesday, 23 May 2017 18:31:35 CEST Aleix Pol wrote:
> > I would have looked into fixing it, but I'm not sure I understand why
> > there's all the RPATH logic in place, so I'd prefer to hear from you
> > first.
> 
> I have removed the remains of the pre-ECM rpath handling. This also changed
> binary output directories on Linux to follow KDE standards, so you might
> want to do a clean build to avoid issues with outdated binaries in the
> build dir.
> > A good next step would also be to get it running on build.kde.org, so
> > we can identify these issues.
> 
> Indeed, I've requested CI coverage now.

Looks like in order to get CI coverage we need to move to kdereview (which is 
fine, I think it's ready for that), but that requires to know where this 
should end up afterwards. 

I guess the candidates are extragear/libs or frameworks? frameworks seems 
conceptually like the right place, but putting something there that is still 
fairly new and has seen little field testing seems sub-optimal. Opinions?

Regards,
Volker


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

Re: Application usage statistics and targeted user surveys

[Volker Krause]

On Wednesday, 24 May 2017 17:38:22 CEST Aleix Pol wrote:
> On Tue, May 23, 2017 at 6:31 PM, Aleix Pol  wrote:
> Hey Volker, I figured out this one. Never mind.
> 
> I've done a proof of concept integrating it in Discover, here's 2 patches:
> https://phabricator.kde.org/D5960
> https://phabricator.kde.org/D5961

There's still two aspects missing in the integration:
- configure Provider to actually submit (see productIdentifier, feedbackServer 
and submissionInterval properties)
- probably add some data sources (in the current form you only get an 
indication on how many users you have, and untargeted surveys, nothing more)

The second point will need some more QML wrapper API. I'll look into adding a 
QML plugin to KUserFeedback directly for this.

> Now to proceed I'd like to give a try to whole system including the
> server. Do you have documented how to set it up anywhere? Would make
> it easier.

INSTALL contains the deployment documentation, both for the full setup with 
authentication on an Apache server, and locally for unsecured testing using 
the built-in PHP server.

I've also got a playground server on my own infrastructure now that I can 
provide accounts for. And Jan has published his ongoing work on creating a 
Docker image for the server here: https://github.com/KDAB/kuserfeedbackdocker

Regards,
Volker


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

Re: Application usage statistics and targeted user surveys

[Volker Krause]

On Tuesday, 23 May 2017 18:31:35 CEST Aleix Pol wrote:
> On Sun, Apr 23, 2017 at 12:52 PM, Volker Krause <vkra...@kde.org> wrote:
> Hi volker,
> I've been looking into how it works, I wanted to test the tests/orwell
> application but I keep getting this error:
> ./bin/orwell: symbol lookup error: ./bin/orwell: undefined symbol:
> _ZN12UserFeedback18CompilerInfoSourceC1Ev
> 
> I'm seeing a similar error when running autotests:
> * Start testing of DataSourceTest *
> Config: Using QtTest library 5.9.0, Qt 5.9.0
> (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC
> 6.3.1 20170306)
> PASS   : DataSourceTest::initTestCase()
> PASS   : DataSourceTest::testPlatformInfoSource()
> PASS   : DataSourceTest::testScreenInfoSource()
> PASS   : DataSourceTest::testPropertyRatioSource()
> PASS   : DataSourceTest::testMultiPropertyRatioSource()
> PASS   : DataSourceTest::testApplicationVersionSource()
> PASS   : DataSourceTest::testQtVersionSource()
> PASS   : DataSourceTest::testStartCountSource()
> PASS   : DataSourceTest::testUsageTimeSource()
> PASS   : DataSourceTest::testCpuInfoSource()
> PASS   : DataSourceTest::testLocaleInfoSource()
> ./bin/datasourcetest: symbol lookup error: ./bin/datasourcetest:
> undefined symbol: _ZN12UserFeedback16OpenGLInfoSourceC1Ev
> 
> I would have looked into fixing it, but I'm not sure I understand why
> there's all the RPATH logic in place, so I'd prefer to hear from you
> first.

I have removed the remains of the pre-ECM rpath handling. This also changed 
binary output directories on Linux to follow KDE standards, so you might want 
to do a clean build to avoid issues with outdated binaries in the build dir.

> A good next step would also be to get it running on build.kde.org, so
> we can identify these issues.

Indeed, I've requested CI coverage now.

Regards,
Volker


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

Re: Application usage statistics and targeted user surveys

[Volker Krause]

On Friday, 12 May 2017 00:05:59 CEST Albert Astals Cid wrote:
> El dimarts, 2 de maig de 2017, a les 19:58:05 CEST, Volker Krause va 
escriure:
> > On Tuesday, 2 May 2017 00:07:43 CEST Albert Astals Cid wrote:
> > > El diumenge, 23 d’abril de 2017, a les 12:52:57 CEST, Volker Krause va
> > > Should submissionInterval and encouragementInterval also be a property
> > > in
> > > Provider?
> > 
> > I only added properties needed for a QML configuration user interface so
> > far, but if someone wants to do the entire setup in QML it probably makes
> > sense to expose the entire API indeed.
> 
> +1 i think we should start thinking more in "which are the qproperties that
> make sense to expose" instead of the "what are the ones that i actually
> need".
> 
> Though i guess adding new qproporties is abi and api compatible it's always
> nice if someone that has other needs doesn't need to add the qproperty at a
> later stage.

Done, and Aleix added properties for SurveyInfo, so we are getting closer to 
full QML usability, with Discover being the guinea pig for that.

> > > I see you protected the data on the server with a user/password.
> > 
> > It's protecting both read access on the data and write access on product
> > configuration and survey campaigns, yes. It would probably make sense to
> > separate those two interfaces, and thus also enabling different access
> > control for data analysis and product/campaign management.
> 
> +1, i'd like at least a "read" and an "admin" privilege separation, if i
> understand we plan to run this as a "KDE-wide service".

That's implemented now.

> > > If the data is really anonymous do we really need user/password ?
> > 
> > Good point, I would also argue that for building trust in such a system
> > the
> > data must be public. However, there are two reasons that still made me
> > protect it:
> > (1) if it's world-readable the fact that it is essentially world-writable
> > (see above problem with submitting wrong data) makes this easily
> > exploitable for spreading links to illegal content, same as e.g. our
> > pastebin was abused.
> 
> Apply the same solution we made for pastebin? i.e. i think you need an
> identity account now?

Right, which should now be doable with the option of having read-only access 
to the data.

Regards,
Volker


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

Re: Application usage statistics and targeted user surveys

[Volker Krause]

Thanks for the review!

On Tuesday, 2 May 2017 00:07:43 CEST Albert Astals Cid wrote:
> El diumenge, 23 d’abril de 2017, a les 12:52:57 CEST, Volker Krause va
> > Wanting this for GammaRay I attempted to implement a generic framework for
> > this, with the goal to make this fully transparent, and give the user full
> > control over what data is shared, and how often they want to participate
> > in
> > surveys, ie. make this solid enough on the privacy side that even I would
> > enable it myself. You'll find the code in Git (kde:kuserfeedback).
> 
> Why the weird values in StatisticsCollectionMode ?

Extensibility, so we can add more modes later if needed, while still keeping 
the order based on how much data is submitted.

> Should submissionInterval and encouragementInterval also be a property in
> Provider?

I only added properties needed for a QML configuration user interface so far, 
but if someone wants to do the entire setup in QML it probably makes sense to 
expose the entire API indeed.

(What data you want to share (statisticsCollectionMode) and how often you want 
to be bothered by surveys (surveyInterval) are the only two values meant for 
user configuration, the rest is supposed to be configured by the application 
developer.)

> Also would be nice to specify the default values for submissionInterval,
> encouragementInterval, surveyInterval

done

> Do I gather correctly thta as an app developer the only things I'm actually
> interested in are Provider and FeedbackConfigWidget/Dialog? Would be nice to
> have some docu saying so

Those are the main integration points, yes. You'll also need to add data 
sources for Provider to actually report telemetry though, either a built-in 
one, or implementing a custom one based on AbstractDataSource.

Added a high-level integration overview to Mainpage.dox.

> > Feature-wise it so far contains:
> > - a set of built-in data sources (app version, Qt version, platform,
> > application usage time, screen setup, etc) that applications can choose to
> > enable
> > - generic data sources for tracking the time ratio a Q_PROPERTY has a
> > specific value, allowing to track e.g. which application view is used how
> > much - the ability to add custom/application-specific data sources
> > - reference widgets for customizing what data you want to share, and
> > showing exactly what that means, in human readable translated text and if
> > you insists also all the way down to the raw JSON sent to the server.
> > - survey targeting using simple C++/JS-like expressions that can access
> > all
> > the data sources (ie. you can target e.g. only users with high DPI multi-
> > screen setups)
> > - configurable encouragement of users to contribute (ie. after X starts
> > and/or Y hours of usage, repeated after Z months, suggest the user to
> > participate if they aren't already doing so).
> > - a management and analytic tool that allows you to manage products and
> > survey campaigns, and view recorded data using configurable aggregations
> > - the entire thing works without unique user ids. Fingerprinting can still
> > be an issue on too small user sets and/or when using too much detail in
> > the
> > data. - by default all of this is opt-in of course, although technically
> > the API doesn't prevent applications to change this
> > - it can deal with multiple products, each product can have different data
> > sources and survey campaigns
> 
> Haven't read much of the code yet, so I'll ask some stuff.
> 
> Is there a way for the user to see (locally) the data he has sent to the
> servers?

The default configuration dialog shows you a list of what would be sent at the 
time of looking at it, but there is no local logging of the submitted data at 
this point.

> Is there a way for the user to remove the data he has sent to the servers?
> Guess not since otherwise we would be able to do a 1:1 mapping

No. But it's not impossible to achieve I think, without giving up the "no 
unique user identification" requirement. The server could generate a unique 
random key for each submitted record and send that back to the client. The 
client would store these and if desired can request deletion for the 
corresponding records.

Both good points, how important do you think they are for acceptance of this?

> Do we have some way in the server to protect us from people trying to inject
> "fake/wrong" data?

No. And that could indeed be a problem. We can do some sanity checking, but if 
someone insists on vandalizing this you can easily make this entirely useless 
by submitting tons of plausible/"valid" data. You can block IP addresses/
ranges on the web server level, but that is rather crude and manual, but 
that's as f

Re: Application usage statistics and targeted user surveys

[Volker Krause]

On Tuesday 25 April 2017 12:54:42 Aleix Pol wrote:
> On Sun, Apr 23, 2017 at 12:52 PM, Volker Krause <vkra...@kde.org> wrote:
> > Hi,
> > 
> > we have talked about the above topics a couple of times in the past, from
> > what I remember usually agreeing it would be nice to have some more
> > statistical information about our users, so we know what our applications
> > are used for, and to measure impact of changes. Similarly, it would be
> > nice to be able to actually ask our users questions without statistical
> > bias by using out-of-band channels like blogs or social media. This can
> > be obviously addressed by adding this into application code, but that
> > raises some valid privacy concerns.
> > 
> > Wanting this for GammaRay I attempted to implement a generic framework for
> > this, with the goal to make this fully transparent, and give the user full
> > control over what data is shared, and how often they want to participate
> > in
> > surveys, ie. make this solid enough on the privacy side that even I would
> > enable it myself. You'll find the code in Git (kde:kuserfeedback).
> > 
> > Feature-wise it so far contains:
> > - a set of built-in data sources (app version, Qt version, platform,
> > application usage time, screen setup, etc) that applications can choose to
> > enable
> > - generic data sources for tracking the time ratio a Q_PROPERTY has a
> > specific value, allowing to track e.g. which application view is used how
> > much - the ability to add custom/application-specific data sources
> > - reference widgets for customizing what data you want to share, and
> > showing exactly what that means, in human readable translated text and if
> > you insists also all the way down to the raw JSON sent to the server.
> > - survey targeting using simple C++/JS-like expressions that can access
> > all
> > the data sources (ie. you can target e.g. only users with high DPI multi-
> > screen setups)
> > - configurable encouragement of users to contribute (ie. after X starts
> > and/or Y hours of usage, repeated after Z months, suggest the user to
> > participate if they aren't already doing so).
> > - a management and analytic tool that allows you to manage products and
> > survey campaigns, and view recorded data using configurable aggregations
> > - the entire thing works without unique user ids. Fingerprinting can still
> > be an issue on too small user sets and/or when using too much detail in
> > the data. - by default all of this is opt-in of course, although
> > technically the API doesn't prevent applications to change this
> > - it can deal with multiple products, each product can have different data
> > sources and survey campaigns
> > 
> > Technically, this consists of the following parts:
> > - a library that goes into the target application, backward compatible all
> > the way to Qt4.8/MSVC2010 (needed for my GammaRay use-case), depending
> > only on QtGui
> > - a library with the reference widgets, also with extended backward
> > compatibility
> > - the server, written in PHP5 and supporting sqlite/mysql/postgresql. Not
> > the most fun technology, but that stuff is available almost anywhere, and
> > easy to deploy and maintain
> > - the management tool, recent Qt5/recent C++, using QtCharts for the data
> > analysis
> > - a command line tool for data import/export, useful for eg. automated
> > backups
> > 
> > All of this is LGPLv2+ licensed.
> > 
> > Feedback obviously very welcome, in particular around privacy concerns, or
> > reasons that would make you enable/disable such a feature.
> > 
> > Regards,
> > Volker
> 
> Hi Volker,
> This is really cool and necessary! I'd really like to see it adopted
> in our applications, hoping Krita can be the first of many. ;)
> 
> WRT the code, it depends needs Qt4, we can live with it, but isn't it
> a bit weird that we have several ECM files forked in it? :/ is it
> really that tough of a depenendency? (if so, maybe we should rethink
> the whole KF5 approach x'D)

I'll fix that, that was just me being lazy as my Qt4 and Windows development 
environments didn't have ECM :)

For GammaRay this isn't an issue anyway, as we ship all required dependencies 
(parts of ECM and KF5, and some other stuff), for easier deployment on 
embedded targets, and due to the Qt4 backward compatibility requirement. We'd 
probably do the same with the application side part of the feedback library.

Regards,
Volker

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

Re: Application usage statistics and targeted user surveys

[Volker Krause]

On Sunday, 23 April 2017 14:41:05 CEST Boudewijn Rempt wrote:
> Did I just miss it -- or didn't you tell us where we can find the library?
> Curiously enough, there's a gsoc proposal this year for krita that has
> pretty much this as its goal...

Interesting :) I wasn't aware of that, I only knew about the statistics Kexi 
collects. Sounds like very similar data as what I'm looking for for GammaRay 
too, ie. which features/tools/views are used how often.

The already built-in way of tracking that kind of data is as normalized ratios 
(ie. usage time percentage). Absolute counts would also be possible, but are 
somewhat more prone to fingerprinting. At the PIM sprint two weeks ago adding 
application-side downsampling was proposed as a countermeasure (but has yet to 
be implemented).

There are some ideas for making collecting this kind of data easier by adding 
code for e.g. counting QAction triggers, or monitoring QItemSelectionModels, 
next to the existing property monitoring code. But it probably makes sense to 
look at a few potential users first to see how the data is represented there.

Regarding system information (which you basically can get for free once you 
have the infrastructure in place anyway), I'd guess details on the OpenGL 
stack and the available input devices might be most relevant for Krita, adding 
the former is at least already on my todo list.

Regards,
Volker

> On Sun, 23 Apr 2017, Volker Krause wrote:
> > Hi,
> > 
> > we have talked about the above topics a couple of times in the past, from
> > what I remember usually agreeing it would be nice to have some more
> > statistical information about our users, so we know what our applications
> > are used for, and to measure impact of changes. Similarly, it would be
> > nice to be able to actually ask our users questions without statistical
> > bias by using out-of-band channels like blogs or social media. This can
> > be obviously addressed by adding this into application code, but that
> > raises some valid privacy concerns.
> > 
> > Wanting this for GammaRay I attempted to implement a generic framework for
> > this, with the goal to make this fully transparent, and give the user full
> > control over what data is shared, and how often they want to participate
> > in
> > surveys, ie. make this solid enough on the privacy side that even I would
> > enable it myself. You'll find the code in Git (kde:kuserfeedback).
> > 
> > Feature-wise it so far contains:
> > - a set of built-in data sources (app version, Qt version, platform,
> > application usage time, screen setup, etc) that applications can choose to
> > enable
> > - generic data sources for tracking the time ratio a Q_PROPERTY has a
> > specific value, allowing to track e.g. which application view is used how
> > much - the ability to add custom/application-specific data sources
> > - reference widgets for customizing what data you want to share, and
> > showing exactly what that means, in human readable translated text and if
> > you insists also all the way down to the raw JSON sent to the server.
> > - survey targeting using simple C++/JS-like expressions that can access
> > all
> > the data sources (ie. you can target e.g. only users with high DPI multi-
> > screen setups)
> > - configurable encouragement of users to contribute (ie. after X starts
> > and/or Y hours of usage, repeated after Z months, suggest the user to
> > participate if they aren't already doing so).
> > - a management and analytic tool that allows you to manage products and
> > survey campaigns, and view recorded data using configurable aggregations
> > - the entire thing works without unique user ids. Fingerprinting can still
> > be an issue on too small user sets and/or when using too much detail in
> > the data. - by default all of this is opt-in of course, although
> > technically the API doesn't prevent applications to change this
> > - it can deal with multiple products, each product can have different data
> > sources and survey campaigns
> > 
> > Technically, this consists of the following parts:
> > - a library that goes into the target application, backward compatible all
> > the way to Qt4.8/MSVC2010 (needed for my GammaRay use-case), depending
> > only on QtGui
> > - a library with the reference widgets, also with extended backward
> > compatibility
> > - the server, written in PHP5 and supporting sqlite/mysql/postgresql. Not
> > the most fun technology, but that stuff is available almost anywhere, and
> > easy to deploy and maintain
> > - the management tool, recent Qt5/recent C++, using QtCharts for the data
> > analysis
> > - a command line tool for data import/export, useful for eg. automated
> > backups
> > 
> > All of this is LGPLv2+ licensed.
> > 
> > Feedback obviously very welcome, in particular around privacy concerns, or
> > reasons that would make you enable/disable such a feature.
> > 
> > Regards,
> > Volker



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

Application usage statistics and targeted user surveys

[Volker Krause]

Hi,

we have talked about the above topics a couple of times in the past, from what 
I remember usually agreeing it would be nice to have some more statistical 
information about our users, so we know what our applications are used for, 
and to measure impact of changes. Similarly, it would be nice to be able to 
actually ask our users questions without statistical bias by using out-of-band 
channels like blogs or social media. This can be obviously addressed by adding 
this into application code, but that raises some valid privacy concerns.

Wanting this for GammaRay I attempted to implement a generic framework for 
this, with the goal to make this fully transparent, and give the user full 
control over what data is shared, and how often they want to participate in 
surveys, ie. make this solid enough on the privacy side that even I would 
enable it myself. You'll find the code in Git (kde:kuserfeedback).

Feature-wise it so far contains:
- a set of built-in data sources (app version, Qt version, platform, 
application usage time, screen setup, etc) that applications can choose to 
enable
- generic data sources for tracking the time ratio a Q_PROPERTY has a specific 
value, allowing to track e.g. which application view is used how much
- the ability to add custom/application-specific data sources
- reference widgets for customizing what data you want to share, and showing 
exactly what that means, in human readable translated text and if you insists 
also all the way down to the raw JSON sent to the server.
- survey targeting using simple C++/JS-like expressions that can access all 
the data sources (ie. you can target e.g. only users with high DPI multi-
screen setups)
- configurable encouragement of users to contribute (ie. after X starts and/or 
Y hours of usage, repeated after Z months, suggest the user to participate if 
they aren't already doing so).
- a management and analytic tool that allows you to manage products and survey 
campaigns, and view recorded data using configurable aggregations
- the entire thing works without unique user ids. Fingerprinting can still be 
an issue on too small user sets and/or when using too much detail in the data.
- by default all of this is opt-in of course, although technically the API 
doesn't prevent applications to change this
- it can deal with multiple products, each product can have different data 
sources and survey campaigns

Technically, this consists of the following parts:
- a library that goes into the target application, backward compatible all the 
way to Qt4.8/MSVC2010 (needed for my GammaRay use-case), depending only on 
QtGui
- a library with the reference widgets, also with extended backward 
compatibility
- the server, written in PHP5 and supporting sqlite/mysql/postgresql. Not the 
most fun technology, but that stuff is available almost anywhere, and easy to 
deploy and maintain
- the management tool, recent Qt5/recent C++, using QtCharts for the data 
analysis
- a command line tool for data import/export, useful for eg. automated backups

All of this is LGPLv2+ licensed.

Feedback obviously very welcome, in particular around privacy concerns, or 
reasons that would make you enable/disable such a feature.

Regards,
Volker


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

Re: RFC: Enabling -DECM_ENABLE_SANITIZERS='address' in jenkins

[Volker Krause]

On Thursday 10 September 2015 22:36:10 Albert Astals Cid wrote:
> We have this nice ECM module that gives us the option to compile with ASAN.
> 
> I'd like to propose that we enable it by default in jenkins.
> 
> This way we get all the autotests run with ASAN and potentially catch more
> bugs/regressions.
> 
> Comments?

Good idea, definitely worth trying IMHO. There were a few test issues in pim 
code recently where this would have been useful.

regards,
Volker

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

Re: Triggering rebuild after changing a *.json file

[Volker Krause]

On Sunday 23 November 2014 04:36:30 Milian Wolff wrote:
 in my quest for better *.json support in KF5 based applications, I noticed
 that we currently do not rebuild properly on changes to the *.desktop or
 *.json files.

indeed, turns out I have the same problem in GammaRay.

 For KDevelop, I'm thus playing around with something like this currently:
 
 ~~~+
 function(kdevplatform_add_plugin plugin)
 set(options )
 set(oneValueArgs JSON)
 set(multiValueArgs SOURCES)
 cmake_parse_arguments(KDEV_ADD_PLUGIN ${options} ${oneValueArgs}
 ${multiValueArgs} ${ARGN})
 
 string(REGEX REPLACE \\.cmake$  json_out ${KDEV_ADD_PLUGIN_JSON})
 configure_file(${KDEV_ADD_PLUGIN_JSON}
 ${CMAKE_CURRENT_BINARY_DIR}/${json_out})
 
 # ensure we recompile the corresponding object files when the json file
 changes
 set(dependent_sources )
 foreach(header ${KDEV_ADD_PLUGIN_SOURCES})
 file(STRINGS ${header} match REGEX K_PLUGIN_FACTORY_WITH_JSON)
 if(match)
 list(APPEND dependent_sources ${header})
 endif()
 endforeach()
 if(NOT dependent_sources)
 # fallback to all sources - better safe than sorry...
 set(dependent_sources ${KDEV_ADD_PLUGIN_SOURCES})
 endif()
 set_property(SOURCE ${dependent_sources} APPEND PROPERTY OBJECT_DEPENDS
 ${CMAKE_CURRENT_BINARY_DIR}/${json_out})
 
 add_library(${plugin} MODULE ${KDEV_ADD_PLUGIN_SOURCES})
 set_property(TARGET ${plugin} APPEND PROPERTY AUTOGEN_TARGET_DEPENDS
 ${CMAKE_CURRENT_BINARY_DIR}/${json_out})
 endfunction()
 ~~~+
 
 
 To be used like this:
 
 kdevplatform_add_plugin(kdevgit JSON kdevgit.json.cmake SOURCES
 ${kdevgit_PART_SRCS})
 
 This does trigger a rebuild, but the strings are still not updated properly.
 I'm quite confused actually, does anyone know where the code comes from
 that is embedded into the *.o that uses Q_PLUGIN_METADATA? I suspect CMake
 AUTOGEN? But where does that put its generated binary JSON representation?
 How can I make sure that it gets updated properly when the source file
 changes?

moc puts it into the .moc file, so adding a dependency from the .o to the 
.json doesn't help, we'd need that on the .moc file. Indeed ideally something 
that CMake's automoc would add already.

 To reproduce this, you can just change any *.desktop file that is piped
 through desktop_to_json. The change will be picked up by CMake and a
 reconfigure is triggered, which is pretty slow as well. But nothing is
 rebuilt. With the macro above, I trigger the build but still, the *.o file
 that uses K_PLUGIN_FACTORY_WITH_JSON is still containing the old
 strings... I'm at loss - can someone help me please?

The following little tool might be useful while debugging this, so you can 
check the embedded JSON data without running the host application: 
http://www.kdab.com/~volker/akademy/2014/qplugininfo/

regards,
Volker

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

Re: Qt Developer Days 2013 CfP

[Volker Krause]

On Wednesday 24 July 2013 18:00:43 Laszlo Papp wrote:
 May I ask if you have rumors for free tickets to KDE?

I don't know anything about that yet, but speakers will of course have free 
entry. One more reason to submit a talk ;-)

regards,
Volker

 On Wed, Jul 24, 2013 at 7:54 AM, Kevin Ottens er...@kde.org wrote:
  Hello all,
  
  As you might know, the Qt DevDays 2013 Call for Papers has been out for a
  little while now. It looks like there's not many proposals sent by KDE
  people... I think it would be nice if KDE was well represented there, and
  that
  includes having as many good talks as possible.
  
  You're likely doing something interesting (and I can judge that from the
  nice
  talks at Akademy 2013 and the emails I see floating around), so don't
  wait,
  submit something now!
  http://www.qtdeveloperdays.com/call-for-papers-2013
  
  Note that it says the deadline is tomorrow on the 25th, but I hear rumors
  of a
  small extension. ;-)
  
  Regards.
  --
  Kévin Ottens, http://ervin.ipsquad.net
  
  KDAB - proud supporter of KDE, http://www.kdab.com

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

Supported Compilers / C++11 Support in KF5

[Volker Krause]

Hi,

during one of the KF5 BoFs at Akademy we discussed which compilers we want to 
support for KF5 (for KDE PIM: s/KF5/Akonadi =1.11/). The conclusion was to do 
what Qt does (http://qt-project.org/doc/qt-5.0/qtdoc/platform-details.html) 
but ignore the older optional platforms (some of which are broken in Qt itself 
anyway). This means:
- GCC = 4.5
- MSVC = 2010
- Clang

Yes, this does exclude platforms that are not accepting GPLv3 GCCs and have 
not yet switched to Clang. Since all of them at least plan to do that AFAIK, 
if they haven't done so anyway, this should not be a big issue.

It's probably worth documenting this somewhere, but I couldn't find a list of 
what we currently officially support. Suggestions?


As a result of this we can use some C++11 features unconditionally (ie. 
without the #ifdef/macro hacks Qt is using). Most prominently this includes:
- auto
- rvalue refs (without rvalue refs for *this)
- lambda
- override

See http://article.gmane.org/gmane.comp.kde.devel.frameworks/3652 for the 
detailed list of supported features.


Are there any objections to this? Any compiler/platform/feature combination we 
missed that you think could be problematic?

regards,
Volker

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

Re: Supported Compilers / C++11 Support in KF5

[Volker Krause]

On Sunday 21 July 2013 13:52:06 Rolf Eike Beer wrote:
 Volker Krause wrote:
  - GCC = 4.5
  
  - override
 
 Explicit virtual overrides require g++ 4.7:
 
 http://gcc.gnu.org/projects/cxx0x.html

you are right, it's also what all other sources referenced in 
http://article.gmane.org/gmane.comp.kde.devel.frameworks/3652 say, no idea how 
that slipped in then, sorry.

 This is trivially to work around by a CMake time check and then just define
 override to empty.

sure, for KF5 this is not really a problem since Qt provides corresponding 
macros already. I was hoping for real unconditional usage though, since 
Akonadi will need to stay backward-compatible with Qt4 for a while longer, and 
I wanted to avoid to have to basically copy qcompilerdetection.h for that. Not 
to mention that override looks much nicer than Q_DECL_OVERRIDE ;)

regards,
Volker


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

Re: Review Request 110330: Make Prompt on access kwalletd setting apply in more situations

[Volker Krause]

 On May 7, 2013, 8:15 p.m., Àlex Fiestas wrote:
  I'd like to enable this by default, most people I know from the community 
  thinks alike.
  
  Code wise it makes sense.
 
 Eike Hein wrote:
 For clarification: Do you mean enable (= prompt, already the default) or 
 disable (be silent)?
 
 Àlex Fiestas wrote:
 Silent.
 
 App identification on wallet are as secure as nothing, so we better have 
 nothing and with that a better user experience.

Yes, please!


- Volker


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110330/#review32224
---


On May 6, 2013, 5:28 p.m., Eike Hein wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/110330/
 ---
 
 (Updated May 6, 2013, 5:28 p.m.)
 
 
 Review request for KDE Runtime and Harald Sitter.
 
 
 Description
 ---
 
 kwalletd has a Prompt when an application accesses an open wallet config 
 option. If this option is enabled (it is by default) any such access attempt 
 opens a dialog box asking the user to approve or deny the attempt, and 
 optionally remember the decision for the future. This patch moves the 
 evaluation of this config option into the codepath taken by any app 
 authorization check, in effect turning it into a Prompt when an application 
 accesses a wallet setting.
 
 The purpose is to allow distributions such as Kubuntu and Netrunner which 
 want to make KWallet mostly invisible during routine operations to disable 
 this setting by default and so avoid the user being prompted to grant 
 applications wallet access rights in more situations. (It should be pointed 
 out that application identity is apparently based on KAboutData information 
 anyway, and so the security of this system is dubious to begin with.)
 
 
 In the interest of keeping the delta between upstream and downstream as small 
 as possible I'd say it makes sense to pick this up.
 
 
 This diff is to be applied after the diff in: 
 https://git.reviewboard.kde.org/r/110328/
 
 A patch rewording the checkbox label in kwalletmanager has been posted for 
 review here: https://git.reviewboard.kde.org/r/110331/
 
 
 Diffs
 -
 
   kwalletd/kwalletd.cpp fa9fc11 
 
 Diff: http://git.reviewboard.kde.org/r/110330/diff/
 
 
 Testing
 ---
 
 Test package for Kubuntu by Harald Sitter, operation verified at runtime.
 
 
 Thanks,
 
 Eike Hein
 

Re: RFC: Moving KWallet Password dialog into Plasma

[Volker Krause]

On Friday 20 July 2012 17:58:04 Martin Gräßlin wrote:
 Hi all,

 the problems around review request #105628 and getting KWallet's Password
 dialog properly raised above the window it is asking the password for just
 triggered a thought process.

 The main problem here is that $service ask for a password through
 $otherservice. This utterly fails because the $service is not linked
 directly to a window which the window manager would need to properly stack
 the window.

 Now if we think about it in most cases $service is actually a system
 service which can be considered belonging to the workspace. E.g. checking
 for mail, logging into your telepathy account and so on.

 Providing a password safe and asking for the master password is also a
 system service and should belong into the workspace.

 So here my idea: let's move the password dialog into the desktop shell. Have
 it as a so-called persistent notification popping out of the panel and be
 shown on top of all other windows till the user either dismisses it or
 enters the password.

 I think this would solve most of our current issues. There would be one
 place where the dialog is shown to ask for the password, it is visually
 clear that it's a system service which asks for the password and not some
 random malware and if several applications want to open the wallet this
 problem is also nicely solved by e.g. saying Mail Dispatcher Agent and
 Telepathy need to unlock the wallet.

 So what do you think?

I very much like your idea :)

It fixes exactly the problem we have with Akonadi (KRunner/Plasma Clock
starting Akonadi, which in turn syncs with some remote service needing a
password), and for which we haven't been able to find a real solution so far.

I also agree with your security assessment of this, once I can execute code as
your user, KWallet doesn't really protect much anymore, no matter where the
password dialog is running. But that's also not what it was designed to
protect, that's rather someone getting access to your files (different user on
the same system, stolen hard disk, etc). And that's not compromised by moving
the password dialog into a different process.

Integration with system passwords would of course be nice, but is IMHO
completely orthogonal to this.

When looking at KWallet security and usability, there's another aspect that
came up in discussions during Akademy: The Do you want to allow application
foo access your wallet? dialog. It might give the impression that only
certain trusted applications can access the wallet, which is totally
misleading. The application name can trivially be faked, and the allow/deny
always decision is simply stored in a plain text config file.

I assume the intention of this was rather to give users the choice to not
store data of well-known/well-behaving applications in the wallet (maybe due
to security concerns). Kinda makes sense, but might be better solvable by a
corresponding option on the application level (like web browsers do for
example, and I think most Akonadi agents as well), instead of bothering me
with yet another dialog when first using KWallet. This also avoids the false
sense of security.

Regards,
Volker



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

Re: KDELibsNightly.cmake

[Volker Krause]

On Sunday 20 May 2012 21:28:51 Alexander Neundorf wrote:
 On Sunday 20 May 2012, Rolf Eike Beer wrote:
  Am Sonntag, 20. Mai 2012, 12:55:54 schrieb Volker Krause:
   On Sunday 20 May 2012 10:08:11 Andreas Pakulat wrote:
Anyway, I guess the guys ultimately knowning how this is done for
kdelibs are Alex or Volker...
 
 techbase doesn't seem to answer today.
 This script should be fine, it supports git too.
 If not, we can fix this, but AFAIK it should be working with git.
 
 This is like the minimal generic ctest script for running a nightly build.
 It handles all the generic stuff like the bootstrapping problem, setting the
 directories, finding make, etc.
 
 In some not-KDE project I use it everyday (with svn) and it works without
 problems.
 
 I was working quite active on this until Akademy last year, but since then
 I've been completely busy with cmake/KDE frameworks.
 
 You may want to have a look at cdash@home, which is an extension to cdash to
 schedule builds, so clients have to do less:
 http://www.kitware.com/products/html/TheCDashHomeCloud.html
 
   I'm not using those scripts either. My nightly build just calls ctest
   directly, similar to what you have done. Instead of the -D shortcut I
   use
   -M/- T though, to also enable the coverage upload and valgrinded test
   run
   steps.
  
  CTest on what? An already build tree? How do you get the build results
  then? Or which CTest script do you use? Would you mind updating that
  techbase page on how that works?
 
 I'm not sure what Volker does really produces Nightly build results and
 not just a snapshot of the current build tree. It also does not solve the
 bootstrap problem.

Right, I did the bootstrapping manually back then (the build pre-dates the 
script IIRC). So, it's just a cron job running cmake and ctest on an existing 
checkout.

regards,
Volker


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

Re: KDELibsNightly.cmake

[Volker Krause]

On Sunday 20 May 2012 10:08:11 Andreas Pakulat wrote:
 Hi,
 
 On Sat, May 19, 2012 at 8:07 PM, Rolf Eike Beer k...@opensource.sf-
tec.dewrote:
  Am Donnerstag, 17. Mai 2012, 13:30:24 schrieb Andreas Pakulat:
   Hi,
   
   I think this techbase article is pretty much up-to-date. I guess the
   KDElibsNighly.cmake file should simply be deleted.
   http://techbase.kde.org/Development/CMake/DashboardBuilds
  
  This points to quality/nightly-support/KDE/KDELibsNightly.cmake:
  
  # The VCS of KDE is svn, also specify the repository
  set(KDE_CTEST_VCS svn)
  set(KDE_CTEST_VCS_REPOSITORY svn://
  anonsvn.kde.org/home/kde/trunk/KDE/kdelibs)
 
 Ooops :| Should do my homework better I guess. I've meanwhile tried
 kdevplatform (since I don't have kdelibs here) and for that one all thats
 necessary today is running ctest -D Experimental or ctest -D Nightly to run
 the tests and upload the results (and also build IIRC).
 
 Anyway, I guess the guys ultimately knowning how this is done for kdelibs
 are Alex or Volker...

I'm not using those scripts either. My nightly build just calls ctest 
directly, similar to what you have done. Instead of the -D shortcut I use -M/-
T though, to also enable the coverage upload and valgrinded test run steps.

regards,
Volker

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

Re: Setting up a Quality Team within KDE

[Volker Krause]

On Monday 16 April 2012 08:02:51 Andras Mantia wrote:
 On Thursday, April 12, 2012 10:49:10 PM Alexander Neundorf wrote:
  Yes, how good squish works for you depends on at least two things:
 We also use Squish, and it found bugs and regressions in our code.
 Still, there is a big problem with it: the test needs to be maintained
 constantly. If they are not, thing will quickly escalade to the wrong
 direction, ie. you will end up with test cases that just fail and are
 hard to adapt.
 The difference between maintaining unit tests and squish tests is that
 squish tests the code through the UI and it is very easy to change the
 UI in a way it breaks the tests, unless the test case is well set up
 (which means it is not just record and save).

I don't think UI is necessarily easier to change than internal API, the key 
difference is that you'll get a compile error for the unit test, while you 
wont notice a broken Squish test immediately. Therefore it's IMHO essential to 
have continuous or at least nightly runs of the Squish tests, fixing them 
while you still know what you changed is usually quick and easy.

  * how well you set up your squish scripts, object map, etc. If done ad
  hoc,  you end up in an unmaintainable mess. If done carefully, it
  works.
 
 Exactly. :)
 
  * and of course, what you actually test. We don't really test that
  dialogs  etc. still look the same, we use squish to drive our
  software, see that it doesn't crash while doing that, that the
  expected actions work properly, and the produced output data is
  correct. We actually try to do things directly in many cases to stay
  independent from GUI details, i.e. we call slots and check Qt
  properties directly from the python scripts.
 
 This is something we might not agree, as the point of squish is to test
 the app through the UI. If you test through slots, in most cases you
 might write unit tests as well.
 
 I thing Squish tests would improve KDE's code, but this will need a
 dedicated team (which we want to set up, i know :) ). The point is, that
 Squish is not magic, you will need to think, design, write code, just
 not in C++, but in Python for example.

While a dedicated team can help to get this started, I think it has to be the 
developers job to keep the tests working when they break as a result of 
changing code (which is exactly how it works with unit tests right now). 
Otherwise there's the risk of ending up with rotting tests which are useless.

regards,
Volker


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

Re: GammaRay - Introspection/Debugging Tool for Qt Applications

[Volker Krause]

On Wednesday 02 November 2011 11:10:17 Bart Cerneels wrote:
 On Sun, Oct 30, 2011 at 13:21, Volker Krause vkra...@kde.org wrote:
  Hi!
  
  During the Qt Dev Days in Munich last week we (KDAB) released a new Free
  Software introspection/debugging tool for Qt applications, called
  GammaRay:
  https://github.com/KDAB/GammaRay
  
  It hooks itself into a Qt application (at start-up or at runtime) using a
  variety of methods (ranging from assembler hacks to (ab)using Qt plug-ins)
  and uses the Qt meta object system for introspecting object, properties,
  signals, slots, signal/slot connections, etc. Nothing really new until
  here, tools like Qt Inspector or KSpy can do this already. On top of that
  GammaRay adds a bunch of higher level tools though, for example:
  
  - QWidget layout overlay, similar to designer
  - Inspecting a QGraphicsScene and various details of QGraphicsItems
  (visualizing shapes, bounding rects, transformation origins, etc)
  - Looking at the full (proxy) model hierarchy and all intermediate results
  in there
  - a live updating QStateMachine visualization
  - attaching of QScriptEngineDebugger and QWebInspector to the
  corresponding
  objects in the application
  - a QTextDocument document object model viewer
  
  Additionally, GammaRay has a plug-in interface for adding new tools, say a
  KJob tracker.
  
  GammaRay works on Linux, Mac and Windows (MSVC only so far), it needs to
  be
  compiled against the same Qt version used by the application you are about
  to debug though. There's also a Qt Creator plug-in for it
  (https://github.com/KDAB/KDAB-Creator).
  
  Some screenshots can be found here: http://www.kdab.com/gammaray
  
  GammaRay was originally developed in support for the Kontact Touch
  project,
  back when there wasn't a QML debugger yet. The proxy model debugger also
  proved quite helpful on KMail, maybe it can help some of you as well :)
  
  Needless to say that contributions are very much welcome.
  
  regards
  Volker
 
 I've asked this at the devdays but want to spread the idea amongst the
 larger KDE comunity:
 Can this tool, or it's technologies, be use to make inline translation
 of a running application possible? Would greatly simplify the process
 (and more fun!) and get better results since the string changes will
 be immediately visible, preventing wrong context assumptions and to
 long strings.

I think GammaRay's core (injecting and accessing the object tree) would be a 
good start for such an inline translation tool. Actually, you can use GammaRay 
already to edit a lot of user visible strings by changing properties etc., 
just not fully inline in the UI.

However, I see one big challenge with this approach: The strings we access 
there are already fully assembled, so no placeholders etc. are available 
anymore. For a real translation tool we would need to be able to query the 
corresponding unprocessed source string as well (and trigger a re-processing 
of it after translation, for live updates).

regards
Volker


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

Re: GammaRay - Introspection/Debugging Tool for Qt Applications

[Volker Krause]

On Wednesday 02 November 2011 20:39:02 Peter Kümmel wrote:
 What is the status of windll? It doesn't work here.
 Only a prove of principle?

I can't test myself, but the GammaRay Windows team (Andreas Holzammer, Nicolas
Arnaud-Cormos and Patrick Spendrin, most of whom you probably know from KDE
Windows already) tells me it works with MSVC 2008/2010 on x86 32/64bit debug
builds and sometimes 32bit release builds. At least it does in the 1.0 branch,
there might be recent breakage in master of course.

 Why do you not use QProcess to start the process in launch?
 If you aren't already busy on windll I could have a look at it.

 And is this list the right list to discuss GammaRay, especially
 when it comes to win32?

We don't have a dedicated list (yet), for Windows-specific issues it might be
best to talk to the guys listed above directly (note that Andy (who did most
of the work) just left for a 4 week Internet-free vacation, and Nicolas is
probably not subscribed here).

I'm not aware of any of them currently working on that injector, your help is
of course very much welcome :)

regards
Volker



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

Re: GammaRay - Introspection/Debugging Tool for Qt Applications

[Volker Krause]

On Monday 31 October 2011 22:36:08 Peter Kümmel wrote:
 On 30.10.2011 13:21, Volker Krause wrote:
  Hi!
 
  During the Qt Dev Days in Munich last week we (KDAB) released a new Free
  Software introspection/debugging tool for Qt applications, called
  GammaRay:
  https://github.com/KDAB/GammaRay
 
  It hooks itself into a Qt application (at start-up or at runtime) using a
  variety of methods (ranging from assembler hacks to (ab)using Qt plug-ins)
  and uses the Qt meta object system for introspecting object, properties,
  signals, slots, signal/slot connections, etc. Nothing really new until
  here, tools like Qt Inspector or KSpy can do this already. On top of that
  GammaRay adds a bunch of higher level tools though, for example:
 
  - QWidget layout overlay, similar to designer
  - Inspecting a QGraphicsScene and various details of QGraphicsItems
  (visualizing shapes, bounding rects, transformation origins, etc)
  - Looking at the full (proxy) model hierarchy and all intermediate results
  in there
  - a live updating QStateMachine visualization
  - attaching of QScriptEngineDebugger and QWebInspector to the
  corresponding
  objects in the application
  - a QTextDocument document object model viewer
 
  Additionally, GammaRay has a plug-in interface for adding new tools, say a
  KJob tracker.
 
  GammaRay works on Linux, Mac and Windows (MSVC only so far), it needs to
  be
  compiled against the same Qt version used by the application you are about
  to debug though. There's also a Qt Creator plug-in for it
  (https://github.com/KDAB/KDAB-Creator).
 
  Some screenshots can be found here: http://www.kdab.com/gammaray
 
  GammaRay was originally developed in support for the Kontact Touch
  project,
  back when there wasn't a QML debugger yet. The proxy model debugger also
  proved quite helpful on KMail, maybe it can help some of you as well :)
 
  Needless to say that contributions are very much welcome.
 
  regards
  Volker

 Congratulation for this very nice tool!

 I've also tried to attach to console apps without success.
 Then I realized that you use the hijacked process to show
 the GammaRay mainwindow which is not possible in a
 QCoreApplication executable.

 So I wonder how difficult it would be to run GammaRay in a
 different process? Then an IPC mechanism is needed for all
 the information. Would this be fast enough? Do you plan
 to add this in future?

I'd love to have that, for console apps, remote debugging on an embedded
system, and for less interference with the debugged process :)

You can probably get a large amount of the features by having some kind of
network transparent QAbstractItemModel adapter. But some feature need direct
memory access, like rendering of a second QGraphicsScene view, unless you want
to send pixmaps over IPC.

 Is there a single point where all the information of
 the target process goes through or is it all over the place?
 I assume at least each plugin pulls information by itself.

Most of it goes through probe.cpp and the object models provided by it,
however all the plug-ins access raw QObject pointers they retrieve from those
models (and thus are bound to the same process).

 And how much does the current code depend on x86/64?
 Would it be hard to support PPC?

There are two injectors that are very architecture specific (windll on
Windows/MSVC and preload on Mac), they assume a specific layout in memory
and rewrite assembly code to intercept function calls.
All other injectors should be architecture independent (preload on Linux,
gdb on any Unix and style everywhere), but I don't think they have been
tested yet on non-x86 either.
Probably something I should document in the wiki...

regards
Volker




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

GammaRay - Introspection/Debugging Tool for Qt Applications

[Volker Krause]

Hi!

During the Qt Dev Days in Munich last week we (KDAB) released a new Free 
Software introspection/debugging tool for Qt applications, called GammaRay: 
https://github.com/KDAB/GammaRay

It hooks itself into a Qt application (at start-up or at runtime) using a 
variety of methods (ranging from assembler hacks to (ab)using Qt plug-ins) and 
uses the Qt meta object system for introspecting object, properties, signals, 
slots, signal/slot connections, etc. Nothing really new until here, tools like 
Qt Inspector or KSpy can do this already. On top of that GammaRay adds a bunch 
of higher level tools though, for example:

- QWidget layout overlay, similar to designer
- Inspecting a QGraphicsScene and various details of QGraphicsItems 
(visualizing shapes, bounding rects, transformation origins, etc)
- Looking at the full (proxy) model hierarchy and all intermediate results in 
there
- a live updating QStateMachine visualization
- attaching of QScriptEngineDebugger and QWebInspector to the corresponding 
objects in the application
- a QTextDocument document object model viewer

Additionally, GammaRay has a plug-in interface for adding new tools, say a 
KJob tracker.

GammaRay works on Linux, Mac and Windows (MSVC only so far), it needs to be 
compiled against the same Qt version used by the application you are about to 
debug though. There's also a Qt Creator plug-in for it 
(https://github.com/KDAB/KDAB-Creator).

Some screenshots can be found here: http://www.kdab.com/gammaray

GammaRay was originally developed in support for the Kontact Touch project, 
back when there wasn't a QML debugger yet. The proxy model debugger also 
proved quite helpful on KMail, maybe it can help some of you as well :)

Needless to say that contributions are very much welcome.

regards
Volker


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

Re: Who relies on Soprano::Model::statement[s]Added|Removed signals?

[Volker Krause]

On Friday 30 September 2011 13:36:22 Sebastian Trüg wrote:
 Hi lists,

 with frameworks in the building and Nepomuk probably going that
 direction already for 4.8 I would like to clean up a bit. One of these
 cleanup tasks targets the Soprano::Model statement signals. So far these
 were the only way to get informed about changes in Nepomuk - with a very
 bad impact on performance and bad usability.
 With 4.7 we already introduced a preliminary version of the
 Nepomuk::ResourceWatcher[1] which is now in charge of informing clients
 about changes.
 I would like to anyone using the old API to change to the new
 ResourceWatcher as soon as possible because I would like to disable the
 old signals soon. They simply entail to many problems and clutter the API.

kdepim uses those signals in the following places:
- libmessagelist (kdepim/messagelist)
- kmail
- Nepomuk tag resource (kdepim-runtime/resources/nepomuktag)

regards
Volker

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

Review Request: Support GnuPG2 in KNewstuff3

[Volker Krause]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102439/
---

Review request for kdelibs.


Summary
---

So far knewstuff has gpg hardcoded as the executable name for GnuPG. This 
patch also allows the use of gpg2 instead, if the gpg executable is not 
present (both are compatible as far as we are concerned here). Since kdepim* 
requires GnuPG2, you are most likely using gpg2 already anyway, via backward 
compatibility forwards. On MeeGo however this is not available and packages for 
GnuPG1 and 2 are not installable at the same time.


Diffs
-

  knewstuff/knewstuff3/core/security.cpp 5654787 

Diff: http://git.reviewboard.kde.org/r/102439/diff


Testing
---


Thanks,

Volker