Re: Changing dependencies for a project

[Heiko Becker]

On Wednesday, 10 July 2024 01:51:16 CEST, David Jarvie wrote:

On Tuesday, 9 July 2024 23:47:30 BST Albert Astals Cid wrote:

El dimarts, 9 de juliol del 2024, a les 22:12:40 (CEST), David Jarvie va

escriure: ...


If I'd created a merge request, it would presumably have just sat there 
unmergeable because of the missing CI dependency. How does a new dependency 
get added to the CI?



I've changed everything I can find in the KAlarm repository
relating to the dependencies, so is there something else I need to do to
set up the new dependencies?


You can a) file a sysadmin ticket or b) create a MR for 
https://invent.kde.org/sysadmin/ci-images/ adding the dependency to the 
images.


It seems, judging from a quick look, that vlc is missing for the qt6 
variants because it pulls in qt5.


Regards,
Heiko

Re: KDE Gear projects with failing CI (master) (2 July 2024)

[Heiko Becker]

On Wednesday, 3 July 2024 14:29:05 CEST, christ...@cullmann.io wrote:

On 2024-07-03 12:59, Ben Cooksley wrote:

On Wed, Jul 3, 2024 at 9:21 AM Albert Astals Cid 
wrote:


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


Probably related to changes in Breeze to use RCC/QRC instead of
installing icons on disk?


Hmm, that would be rather strange, per default still all icons
are installed, the lib is just there in addition.


Yep. 
https://invent.kde.org/frameworks/breeze-icons/-/commit/3e2ad6c1a86f08ac9e1106b13b6ff5d458d313ed 
broke it. I forgot what minimum size flatpaks want, but we may want a 
larger size again.


Regards,
Heiko

Re: Should we stop distributing source tarballs?

[Heiko Becker]

On Friday, 5 April 2024 12:04:28 CEST, Albert Vaca Cintora wrote:

It seems a lot of people feel conservative in favor of tarballs, so
maybe I aimed too far. At least I think the discussion brought some
interesting points that we can explore further. Some I identified:

- The tarballs should contain no changes with respect to git, or
minimal changes obviously justifiable in a diff.


Like I wrote earlier in this thread, this should hold true already since 
the translations are synced to git.



- Tarballs should only be generated in a reproducible manner using
scripts. Ideally by the CI only.
- We should start to sign tarballs in the CI.


The scripts already exists for the bundles and users of releasme. Letting 
the CI create tarballs seems indeed like a good way to reduce possibilities 
of human tampering.
With regard to signing: At first I thought that it means something that the 
person responsible for the release is also signing the tarballs. But maybe 
there could even be two signatures in the future, one by CI and one by the 
release person (although that would probably mean a few challenges for the 
tooling).



- We should start to sign commits and tags. Git recently made this
super easy by allowing signing with the ssh keys that we all are
already using to push things, so no excuses for not enabling this.


We already sign commits for the 3 release bundles and users of relaseme.

But I'm surprised about the total absence of social aspects of the xz 
incidence during this discussion.
Admittedly we fall back to community maintenance if a maintainer becomes 
unavailable, so the exact xz scenario doesn't seem likely. But there are 
probably a few projects on the fringes. Do we have safeguards in place if a 
nefarious person tries to steps up as maintainer? Can we do something to 
help projects, which are struggling?


Regards,
Heiko

Re: Should we stop distributing source tarballs?

[Heiko Becker]

On Thursday, 4 April 2024 13:26:57 CEST, Sune Vuorela wrote:

On 2024-04-04, Ben Cooksley  wrote:

I do also think it is nice if we get someone else to verify that the
tarball we ship actually matches the tag. I think some people in
distributions have already started looking into verifying that.



Hopefully they'll be gentle with tooling that does this?


I have only seen 'starting to look into it', not actually yet figuring
out what to do with it.

But as an approximation, I would expect

'does the tarball content match the tag?'
'can we easily and automatically explain the difference?'
'does it use autotools?'
'can autogenerated docs and stuff be moved to build time instead?'

and other such things that might flag it differently and probably for
manual inspections.

I think we have stopped injecting translations at tarball creation time
and our tarballs should actually match the git tags?


Yes, that would be my expectation as well, tarballs should be identical to 
a checked out tag (minus the .git dir).

Re: Should we stop distributing source tarballs?

[Heiko Becker]

On Thursday, 4 April 2024 13:07:42 CEST, Ben Cooksley wrote:

[snip]
As an additional aside - we don't currently GPG sign our Git tags, so there
is nothing validating that the person who made the release is actually the
person whose name is on it.
With GPG signatures we can at least validate who owns the key.


We *do* sign the tags for KF, Plasma and Gear. And IIRC releasme defaults 
to signing tags as well.


Regards,
Heiko

Re: AppStream Metadata with our releases

[Heiko Becker]

On Tuesday, 26 March 2024 17:39:25 CET, Volker Krause wrote:

On Dienstag, 26. März 2024 08:59:29 CET Heiko Becker wrote:

On Monday, 25 March 2024 23:23:01 CET, Albert Astals Cid wrote: ...
Sorry about that! I try to keep both branches in sync usually, if there is 
anything I can do/do differently to not impact your work I'm 
happy to do that 
of course.


No worries, I didn't mean this as an accusation. Just a hint for future 
(possible mass) additions.



Otherwise I'd just miss the opportunity to trigger a CI build for
everything again shortly before the release, but I'd guess that's easy to
get over.


Albert seems to have an alternative way using API (?) for the weekly build 
status reports, I guess that could be reused/combined somehow?


Indeed, we would just loose the conveniently timed rebuild, which seems 
acceptable and no problem at all with rather active projects.


Regards,
Heiko

Re: AppStream Metadata with our releases

[Heiko Becker]

On Monday, 25 March 2024 23:23:01 CET, Albert Astals Cid wrote:
El dissabte, 23 de març de 2024, a les 21:06:46 (CET), Julius Künzel va 
escriure:

22.03.2024 17:22:33 Albert Astals Cid : ...


It is some extra work (not a lot, but some).

You're asking for the workflow of creating to be releases to be changed by 
creating the entry in the file earlier, that alone is a bit of work, but it 
has several other consequences:


 * https://apps.kde.org/okular/ shows releases from the appstream file (i 
think) meaning that the code should learn to ignore releases in the future. 
Arguably we would need also now, but given the data is added 
just a few days 
before the actual release i think users can understand "this release will 
happen soon)" compared to a thing one month in the future


 * What happens if we have to change the release date or release version 
number (hasn't happened in a good while, but wouldn't be a bad thing to 
prepare for it). We would need to update the string or date of an existing 
entry, as far as I know we don't have tooling for that (because we only add 
the data to the file when we're almost sure abiyt it).


In addition I'm a litte bit wary of conflicts when cherry-picking the 
appstream changes between branches, which the script does after 
incrementing the version. I saw at least conflicts in itinerary's releases 
notes and e.g. kdeconnect's or okular's windows releases in the past, which 
isn't that much of a problem but it could become one with the 245 modules 
of gear (to be fair not all have appstream metadata (yet)).


Otherwise I'd just miss the opportunity to trigger a CI build for 
everything again shortly before the release, but I'd guess that's easy to 
get over.


Regards,
Heiko

Re: KDE Gear projects with failing CI (release/24.02) (20 February 2024)

[Heiko Becker]

On Tuesday, 20 February 2024 22:30:56 CET, Albert Astals Cid wrote:
Please work on fixing them, otherwise i will remove the failing CI jobs on 
their 4th failing week, it is very important that CI is passing 
for multiple 
reasons.


Good News: 11 failing repositories from previous report got fixed

Bad news: 3 repositories are still failing and 6 new repositories started 
failing


[...]


korganizer - 1st week
 * https://invent.kde.org/pim/korganizer/-/pipelines/611898
  * Linux build has linking problem


A rebuild of kontactinterface has fixed this.

Re: KDE Gear projects with failing CI (release/24.02) (20 February 2024)

[Heiko Becker]

On Tuesday, 20 February 2024 22:30:56 CET, Albert Astals Cid wrote:
Please work on fixing them, otherwise i will remove the failing CI jobs on 
their 4th failing week, it is very important that CI is passing 
for multiple 
reasons.


Good News: 11 failing repositories from previous report got fixed

Bad news: 3 repositories are still failing and 6 new repositories started 
failing


[...]


kmag - 2nd week
 * https://invent.kde.org/accessibility/kmag/-/pipelines/611893  
  * flatpak fails in icon-not-found


Ah, forgot to cherry-pick to release/24.02, but did that now.


klickety - 1st week
 * https://invent.kde.org/games/klickety/-/pipelines/611894
  * appstream test fails in FreeBSD


This needs 
https://github.com/ximion/appstream/commit/d3085b7d1492766f5d7bb5de210c2b11c2e1ead9 
added to FreeBSD's appstream package  (or a new appstream release).

Re: KDE Gear projects with failing CI (release/24.02) (6 February 2024)

[Heiko Becker]

On Tuesday, 6 February 2024 22:24:22 CET, Albert Astals Cid wrote:
Bad news: 3 repositories are still failing and 11 new repositories started 
failing



kdialog - NEW
 * https://invent.kde.org/utilities/kdialog/-/pipelines/601189
  * flatpak fails in icon-not-found


kmag - NEW
 * https://invent.kde.org/accessibility/kmag/-/pipelines/601207  
  * flatpak fails in icon-not-found



kbackup - NEW
 * https://invent.kde.org/utilities/kbackup/-/pipelines/601223
  * flatpak fails in icon-not-found


kirigami-gallery - NEW
 * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/601366
  * flatpak fails in icon-not-found


All of the above are fixed now.

KDE Gear 24.02 bug fix releases and next Gear releases

[Heiko Becker]

Hi everyone,

the question of the next Gear release (after 24.02) came up in #kde-devel 
yesterday evening. Due to this, it also occured to me that we haven't 
scheduled any bug fix releases for 24.02 itself. Which is a bit connected 
to the first question, because I guess we don't want too many stable 
branches at the same time (as in more than 1 really).


I mostly see three options, but of course please chime if you think of 
something else:



a) Continue with the usual dates, eg. 24.04 and 24.08. (or omitting 24.04 
and continue with 24.08 right away)


b) Continue with the usual interval, so 24.06, 24.10 and so on

c) Slightly change the interval to come back to the proven schedule with 
its nice numbers divisible by 4, so something like, 24.05 and 24.08.



Personally, I'd favour b) or c). I think a) is either too short or too 
long. Not sure how b) would interact with holiday schedules, exams or 
distro releases though.


Regards,
Heiko

Re: QML: a packagers nightmare. Assistance please.

[Heiko Becker]

On Wednesday, 8 November 2023 12:48:32 CET, David Redondo wrote:
So the situation right now is that plasma-workspace build 
depends on KWin and 
KWin has a runtime dependency on plasma-workspace. 
I think it's not a full cycle since installing plasma-workspace 
does not need 
anything from KWin but maybe it can cause problems for distributions?


At least no problem here, our package can deal with a build-runtime cycle.

Suggestion to drop kopete from KDE Gear

[Heiko Becker]

Hello,

I wanted to keep kopete at least buildable against recent version of its 
dependencies by removing some obsolete parts. But it occured to me that if 
I were to continue with that, there wouldn't be much left. It suffers from 
the same problems with dead or (at least dying) protocols I wrote down for 
ktp [1], so I'll just add some relevant things affecting kopete:


- Contrary to ktp it doesn't use pidgin for ICQ/AIM, but a custom 
implementation, the result is the same. AIM ceased to exist and ICQ changed 
its protocol (and thus kopete silently fails to with the latter).
- XMPP/Jabber allows to connect, but joining a room crashes kopete, which 
matches a bug report from 2019 [2]

- winpopup was apparently discontinued after Windows XP
- qq: I'm hesistant to give them my phone number to manually register an 
account (the link behind the register button times out). Pidgin removed 
support for this in 2011, which is roughly the same time a non-porting 
commit touched the code and there is a bug report that it indeed doesn't 
work [3]


I didn't have/find an instance to test Bonjour and my distro doesn't 
provide a package for libmeanwhile, so no testing of these.


In addition, it has a very long list of (partly very old) bugs [4] (no idea 
how many, bugzilla stops after 500), and my impression from testing a few 
is that many of them are easily reproduceably today.


As much as I used kopete for chatting back in the day, I seriously think 
it's broken enough to stop shipping it with Gear, if nobody surprisingly 
steps up and does at least some basic maintenance.


If you know anybody who's still around and cares for kopete, please feel 
free to bring this mail to their attention.


Regards,
Heiko

[1] https://mail.kde.org/pipermail/release-team/2023-June/013080.html
[2] https://bugs.kde.org/show_bug.cgi?id=412228
[3] https://bugs.kde.org/show_bug.cgi?id=460744
[4] 
https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED_status=CONFIRMED_status=ASSIGNED_status=REOPENED_id=2429758=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id=kopete_format=advanced

Re: KDE Gear projects with failing CI (master)

[Heiko Becker]

On Tuesday, 4 July 2023 22:47:12 CEST, Albert Astals Cid wrote:
Please work on fixing them, otherwise i will eventually remove 
the failing CI 
jobs, it is very important that CI is passing for multiple reasons.



= MISC FAILURES (4 repos) = 


kontrast:
 * https://invent.kde.org/accessibility/kontrast/-/pipelines/429082
  * Several building issues


Fixed this (minus the general Android issue).

Re: version numbers towards kf6

[Heiko Becker]

On Monday, 26 June 2023 17:32:18 CEST, Jos van den Oever wrote:

On 26/06/2023 17.27, Heiko Becker wrote:

On Monday, 26 June 2023 14:06:04 CEST, Jos van den Oever wrote: ...


So that the user can see that they are running a snapshot and 
not an official release and to make it easy to report the 
correct version/snapshot in bug reports. Getting users to test 
and submit useful bug reports is the goal of these snapshot 
builds.


I don't think it's possible to override PROJECT_VERSION, which for obvious 
reasons is an upstream choice and may influence other things like 
soversion.


But I think you can use the qt6 keyword to tag bug reports.

Re: version numbers towards kf6

[Heiko Becker]

On Monday, 26 June 2023 14:06:04 CEST, Jos van den Oever wrote:

On 26/06/2023 13.15, Heiko Becker wrote:

On Monday, 26 June 2023 11:13:56 CEST, Jos van den Oever wrote:
The new versions of frameworks, plasma and gear presumably 
all start with '6'. Following Fedora versioning for snapshots 
[0] gives this:


 6^20230627git5328c27e3


Like Jonathan said, versioning of snapshots is a downstream 
thing. But if I understand the ^ operator correctly, doesn't 
sort 6^20230.. *after* 6.0?


Indeed, it should be 6~20230627git5328c27e3 or 6.0.0~20230627git5328c27e3.

And no, new versions of Gear won't start with '6'. They follow 
a different versioning scheme and some projects will probably 
switch to Qt6/KF6 with 22.12, some with 23.04 or later.


I guess you mean 23.12 and 24.04. Time flies.


Yeah, indeed.


What is the best way to override the version numbers of KF6?
  cmake -DPROJECT_VERSION_MAJOR=6 ?
Since there is no suffix support this would falsely indicate 
that it's already version 6 instead of a snapshot working 
towards it.


Why do you want to override it it?

Re: version numbers towards kf6

[Heiko Becker]

On Monday, 26 June 2023 11:13:56 CEST, Jos van den Oever wrote:
The new versions of frameworks, plasma and gear presumably all 
start with '6'. Following Fedora versioning for snapshots [0] 
gives this:


 6^20230627git5328c27e3


Like Jonathan said, versioning of snapshots is a downstream thing. But if I 
understand the ^ operator correctly, doesn't sort 6^20230.. *after* 6.0?


And no, new versions of Gear won't start with '6'. They follow a different 
versioning scheme and some projects will probably switch to Qt6/KF6 with 
22.12, some with 23.04 or later.


Regards,
Heiko

Re: Proposal to deprecate KFloppy

[Heiko Becker]

On Friday, 28 April 2023 15:16:29 CEST, Nate Graham wrote:
Does it work for *anyone* with a modern distro? If not, then I 
think archiving it makes sense. Time marches on. :)


If it does work for *someone* with a modern distro then at the 
very least the UI needs to detect when it will be broken and 
tell this to the user in advance to prevent frustration.


I think it depends on the floppy kernel module, which should provide the 
device nodes Jonathan seems to be missing. AFAIK this kernel module isn't 
needed for "modern" floppy drives connected via USB though, but only for 
the ancient internal ones. That being said, the kernel module is orphaned.


My personal opionion is that that's enough to stop releasing it (after 
23.04.3). I also removed it from my distro downstream in 2015 and nobody 
ever even mentioned it.


Regards,
Heiko


On 4/28/23 06:49, Jonathan Riddell wrote:
KFloppy is an old tool to format your floppy diskettes.  We 
packaged KFloppy for the Snap store but it doesn't work, 
neither does it work for the apt packages.  The code depends on 
features of Linux that do not seem to exist any more, expecting 
/dev/fd0 and other nodes in /dev.  It also depends on having 
tools like fdformat around which are not packages for Ubuntu 
any more.  I tested it with an external USB floppy drive.  The 
most recent maintainer seems to be Wolfgang Bauer.  Can we 
agree to archive it and stop releases?

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

[Heiko Becker]

Hi,

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/8d15e66f1ed87a52377111735e24888b7f924a49


Regards,
Heiko

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

[Heiko Becker]

Hi,

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/8d15e66f1ed87a52377111735e24888b7f924a49


Regards,
Heiko

Re: Bringing Cantata under the KDE umbrella?

[Heiko Becker]

On Tuesday, 21 February 2023 16:23:54 CET, Sandro Knauß wrote:
I really would love to see Cantata to be in KDE. At least try 
if it gets some 
momentum. But still you are doing the Qt6 port, so without any new features 
just in maintenance mode I see value in it.



features like cached lyrics, lastfm, wikipedia, serverside playlists
software written to export lyrics so that they are present when you
switch to info-mode


Oh all those features can be interesting for other music players, too! So 
maybe together with the other music players in KDE we can form an API and 
library and we only have one place to write it ;)


That would indeed be a very welcome thing!

Regards,
Heiko

Re: Bringing Cantata under the KDE umbrella?

[Heiko Becker]

On Tuesday, 21 February 2023 07:04:03 CET, Harald Sitter wrote:

On Mon, Feb 20, 2023 at 1:18 PM Aleix Pol  wrote:
On Mon, Feb 20, 2023 at 12:28 AM Heiko Becker 
 wrote: ...


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


I just read a bit through the list of incubating/incubated projects and 
there are quite a few projects where the team size is exactly 1: 
TellySkout, Haruna, Homebrew, Mycroft, Snorenotify, BabeQt, KDiff3, Ikona, 
Kup, TotalReqall, GitKlient, libpercentualcolor (if the information on the 
wiki page is accurate of course).



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


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


Most likely I'm influenced by my usecase, which mostly revolves around 
having a huge collection of music and listening to it, but I don't think 
juk is a good match for that. Its just seems to aim a simple player. Elisa 
is a bit better in that regard, and certainly looks fancy, but it still 
elides to much information or doesn't allow me to show it in the first 
place. And both are missing features Cantata has and I like to use. With 
all respect for the two players and their authors, but writing an MPD 
abstraction (which I suspect would not be anywhere near trivial) for them 
*and* improve them is just a too big task, sorry. (And I'm not sure, given 
my perceived scope of juk, if it even would be welcomed).


That being said, abstractions and reuse would be nice. I can name at least 
three places where e.g. cover fetching is broken and not having to fix it 
in three places and maybe even three ways would be nice. Lyrics are a 
similar topic.


Regards,
Heiko

Re: Bringing Cantata under the KDE umbrella?

[Heiko Becker]

On Sunday, 19 February 2023 23:36:22 CET, Albert Astals Cid wrote:


My only 2 concerns are:

 * Is anyone going to work on it? I guess you?
 * Can we have an agreement by the original author so we can take over the 
trademark?


I got an answer from him:

"You are more than welcome for fork Cantata, move to KDE, and use the name, 
its all fine with me :) Glad someone wants to look after it."


Regards,
Heiko

Re: Bringing Cantata under the KDE umbrella?

[Heiko Becker]

On Monday, 20 February 2023 13:18:02 CET, Aleix Pol wrote:

On Mon, Feb 20, 2023 at 12:28 AM Heiko Becker  wrote:
Part of the incubation process is to gather what's the team working on it.
https://community.kde.org/Incubator/Projects/DescriptionTemplate

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


The original author just switched to LMS, which apparently suited his 
usecase better. Considering the responses in this thread and the 165 forks 
on github, I think it's not really too bold to assume there's still 
interest in Cantata though.


If the team size is a critical problem, I could just do this on my personal 
github, see if its gets any traction and attracts helping hands and revisit 
this discussion at some point in the future.


Regards,
Heiko

Re: Bringing Cantata under the KDE umbrella?

[Heiko Becker]

On Sunday, 19 February 2023 23:36:22 CET, Albert Astals Cid wrote:
El diumenge, 19 de febrer de 2023, a les 16:29:24 (CET), Heiko Becker va 
escriure:
Cantata is a Qt based MPD client, which was archived by its 
original author

[1]. I started some porting to Qt6 but I wondered (and was asked in
#kde-devel today) if it would make sense to move it to KDE's
infrastructure? Despite being archived, it still works quite 
nicely. And ...


My only 2 concerns are:

 * Is anyone going to work on it? I guess you?


Yes.

 * Can we have an agreement by the original author so we can take over the 
trademark?


I mailed him about it and will share the reply here.

Regards,
Heiko

Bringing Cantata under the KDE umbrella?

[Heiko Becker]

Hi,

Cantata is a Qt based MPD client, which was archived by its original author 
[1]. I started some porting to Qt6 but I wondered (and was asked in 
#kde-devel today) if it would make sense to move it to KDE's 
infrastructure? Despite being archived, it still works quite nicely. And 
while there are already a few music players on invent, there is none with 
support for MPD. 

Would anybody object to bringing it under the KDE umbrella? 


Regards,
Heiko

[1] https://github.com/CDrummond/cantata/

Re: Request to relicense all CC0-1.0 code to MIT (or similar permissive license)

[Heiko Becker]

On Sunday, 22 January 2023 18:01:35 CET, Albert Astals Cid wrote:
El diumenge, 22 de gener de 2023, a les 14:12:32 (CET), Neal Gompa va 
escriure:

During a review for flatpak-kcm for inclusion in Fedora, I discovered
that KDE currently licenses its CI scripts under the CC0 (SPDX:
CC0-1.0) license.


You mean .gitlab-ci.yml files ?

Just scrub those from the tarball if those are causing you problems since 
those are in no way needed for the build. 

If scrubing them from the released tarballs is a problem for 
some reason you 
could even try to propose changes to our packaging scripts that 
remove those 
from the release tarballs, if they are not super intrusive i 
guess that they 
could be accepted by the release folk.


Also, and I'm not a lawyer, nor do I want to be one, but can yaml files 
basically just declaratively listing dependencies really be considered 
code? 


Cheers,
Heiko

Re: New releases for bugfixes

[Heiko Becker]

On Thursday, 8 September 2022 13:59:43 CEST, Ahmad Samir wrote:

From the git-archive manual page:

«git archive behaves differently when given a tree ID versus 
when given a commit ID or tag ID. In the first case the current 
time is used as the modification time of each file in the 
archive. In the latter case the commit time as recorded in the 
referenced commit object is used instead. Additionally the 
commit ID is stored in a global extended pax header if the tar 
format is used; it can be extracted using git get-tar-commit-id. 
In ZIP files it is stored as a file comment.»


Before anybody tries that *now*, at least for Gear the tarballs are 
currently created with git archive --remote=kde:$repo $branch ..

So they currently won't have that information.

Regards,
Heiko

Re: Missing product versions in Bugzilla

[Heiko Becker]

On Sunday, 24 July 2022 01:15:09 CEST, Nate Graham wrote:
IIRC, the release team takes care of updating product-versions 
of apps on Bugzilla using a script. CCing them.


Yes, we do. At least for projects passing their version number to project() 
in CMakeLists.txt [1] and if the project name matches the product name in 
bugzilla or has an bugzilla entry in repo-metadata.git, e.g. something like 
[2].


Unfortunately Laurent sometime increases the versions for all PIM repos 
prematurely, as in before we release the tarballs to the public, which 
means the script  adds yy.mm.expected_version + 1 in these cases. Which 
should account for most of the missing versions below. There are more 
versions missing for kmail because the capability and information to do the 
kmail2 <-> kmail was only contributed by Sandro at some point in the past.



On 7/23/22 16:10, Glen Ditchfield wrote:
I've noticed an assortment of 
missing versions for different products:



|kontact | 5.20.1 5.17.2 5.16.2   |

|kmail2  | 5.20.1 5.18.3 5.18.2 5.18.1 5.18.0 |

|| 5.17.3 5.17.2 5.17.1 5.17.0|

|korganizer  | 5.20.1 5.17.2 5.16.2   | ...


I added these versions manually.

Regards,
Heiko

[1] 
https://community.kde.org/Guidelines_and_HOWTOs/Application_Versioning#Bugzilla_versions
[2] 
https://invent.kde.org/sysadmin/repo-metadata/-/commit/bfbd371087b756e6d069e32e6753dfaf810e0bbd

Re: Request to bump QT_MIN_VERSION to 5.15.2 for whole Plasma

[Heiko Becker]

Hello,

On Sunday, 26 June 2022 13:52:23 CEST, Ömer Fadıl USTA wrote:

Right now plasma projects' minimum depends on KF >5.90 and after KF5.86 its
REQUIRED_QT_VERSION is 5.15.2
thus keeping QT_MIN_VERSION as 5.15.0 is meaningless and it also causes
problems such as in this merge :
https://invent.kde.org/utilities/konsole/-/merge_requests/689

So I am suggesting to bump all plasma project's QT_MIN_VERSION to 5.15.2
I will be glad to get some replies and want to hear what are your opinions
about this


that doesn't unreasonable, but konsole isn't released as part of Plasma (it 
gets released with KDE Gear) and if it's actually about Plasma this request 
should probably go to plasma-de...@kde.org


Regards,
Heiko

Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3

[Heiko Becker]

On Sunday, 6 March 2022 19:32:57 CET, Neal Gompa wrote:

This whole thing has been a terrible mess and it's extremely
frustrating. It's caused problems for the development of the last
couple of Fedora releases, too.


Can we scale back the language please? I get that you're not happy, but 
calling the work of volunteers a terrible mess most likely won't motivate 
them any further and it isn't respectful at all.


Furthermore, wearing my packager hat, I really disagree. I'm quite happy 
that 
I don't have to hunt Qt patches myself.


Regards,
Heiko

KDE Gear 21.12 release branches created

[Heiko Becker]

Please make sure you commit anything you want to end up in the 21.12 
releases to them.


We're already past the dependency freeze, so no new dependencies or 
increasing of dependency versions in the stable branches.


The feature freeze, tagging and release of the beta (21.11.80) is in four 
days,11 November.


Next interesting dates:
 November 25: 21.12 RC (21.11.90) Tagging and Release
 December  2: 21.12 Tagging
 December  9: 21.12 Release

Complete Schedule:
https://community.kde.org/Schedules/KDE_Gear_21.12_Schedule

Regards,
Heiko

Re: Is Krename buglist ABANDONED?

[Heiko Becker]

Hi,

On Thursday, 29 July 2021 00:01:15 CEST, Rafael Linux User wrote:

Someone wrote this is fhe right e-mail to ask about it and to take some
actions about the issue.

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


it's just that time is a scarce resource and while krename works fine for 
my purposes the codebase is not tiny and still has some cruft in need of 
modernisation. For example, the bug you're likely referring to, is probably 
best solved by porting to QXmlStream{Reader/Writer}, which already exists 
locally but still needs some finishing touches and autotests.


That being said, any contribution to improve things would be welcome.

Cheers,
Heiko

KDE 21.08 dependency freeze in

[Heiko Becker]

Dependency freeze for KDE Gear 21.08 is in six days (July 8, 23:59 UTC), 
please make sure to update all the needed dependencies before that date.


Next interesting dates:
 July 15: 21.08 Freeze and Beta (21.07.80) tag & release
 ...
 August 12: 21.08.0 Release

More at:
https://community.kde.org/Schedules/KDE_Gear_21.08_Schedule

Regards,
Heiko

Re: KDE's Official Standlaone application packages are missing translations for some basic buttons

[Heiko Becker]

On Wednesday, 16 June 2021 11:55:32 CEST, Luigi Toscano wrote:

Generally speaking:
1) It only affects DIALOGUES' basic buttons like "OK", 
"Cancel", "Help" and so

on.
2) It affects all languages.
3) It happens only on KDE's official, standalone builds. 
Packages provided by

Linux distros are unaffected.


I've checked the Kate appdata and the Kate win64 binaries from 
binary-factory

and they don't include the Qt translations (they ships all the other
translations). So maybe just a configuration issue on the CI?


While there is a craft blueprint for qttranslations, the kate blueprint 
doesn't depend on it (nor does any other blueprint). But then I'm not 
overly familiar with craft...


Regards,
Heiko

21.04 release service schedule

[Heiko Becker]

Hello everyone,

the release team agreed on a schedule for the upcoming release service 
21.04:


https://community.kde.org/Schedules/release_service/21.04_Release_Schedule

Dependency freeze is in 5 weeks and feature freeze one after that. Get your 
stuff ready!


Cheers,
Heiko

D29303: Make KI18N_INSTALL() compatible to KDE_INSTALL_DIRS_NO_DEPRECATED

[Heiko Becker]

heikobecker added a comment.


  In D29303#677015 , @dfaure wrote:
  
  > So this is basically the same as https://phabricator.kde.org/D29136 except 
that D29136  gives priority to the 
non-deprecated variable. Any reason against going with D29136 
 after all?
  
  
  Not from me.

REPOSITORY
  R249 KI18n

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

To: kossebau, ilic, heikobecker
Cc: dfaure, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29299: Make KI18N_INSTALL() not rely on only LOCALE_INSTALL_DIR

[Heiko Becker]

heikobecker added a comment.


  How do we move this or https://phabricator.kde.org/D29136 forward? @ilic As a 
maintainer, do you have an opinion?

REPOSITORY
  R249 KI18n

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

To: kossebau, ilic, heikobecker, #frameworks, aacid, ltoscano
Cc: pino, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29136: Use non-deprecated KDEInstallDir

[Heiko Becker]

heikobecker reclaimed this revision.

REPOSITORY
  R249 KI18n

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

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

D29136: Use non-deprecated KDEInstallDir

[Heiko Becker]

heikobecker abandoned this revision.
heikobecker added a comment.


  Abandoned in favour of https://phabricator.kde.org/D29136

REPOSITORY
  R249 KI18n

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

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

D29299: Make KI18N_INSTALL() not rely on only LOCALE_INSTALL_DIR

[Heiko Becker]

heikobecker added a comment.


  Fixes the problem I had with marble, which prompted the creation of 
https://phabricator.kde.org/D29136. Passing the destination as an parameter 
seems indeed like a better way, so +1 from me.

REPOSITORY
  R249 KI18n

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

To: kossebau, ilic, heikobecker
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29136: Use non-deprecated KDEInstallDir

[Heiko Becker]

heikobecker added a comment.


  > Where would you see "that the macro already used KDEInstallDirs before"? 
When it comes to "LOCALE_INSTALL_DIR", that is set to a default is not set when 
calling the macro. Ideally would be documented though. (my first approach would 
be to also allow a soft dependency here on KDEInstallDirs, checking whether 
KDE_INSTALL_LOCALEDIR is defined and picking its value), similar with 
CMAKE_INSTALL_LOCALEDIR to support GnuInstallDirs automatically).
  
  As you indicate, if one calls ki18_install() in a project which includes 
KDEInstallDirs before that call (and KDE_INSTALL_DIRS_NO_DEPRECATED isn't set) 
the value of LOCALE_INSTALL_DIR is used instead of the default "share/locale". 
I extended the same to check K_I_LOCALEDIR (line 99+). Isn't that the soft 
dependency you suggested (minus the GnuInstallDirs part, obviously?)

REPOSITORY
  R249 KI18n

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

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

D29136: Use non-deprecated KDEInstallDir

[Heiko Becker]

heikobecker added a comment.


  In D29136#660270 , @kossebau wrote:
  
  > using kdeinstalldirs variables needs to ensure that KDEInstallDirs has been 
included before, also introduces ahard  dependency on ECM for any users of 
KI18n. While 99% of apps using KI18n might do this, by design idea of KDE 
Frameworks KI18n as tier1 should not pull in another dependency, even ECM (so 
someone using plain cmake & GnuInstallDirs should be still able to use tier1 
stuff). This needs some more pondering then...
  
  
  Isn't that a mere theoretical concern? At least when building ki18n yourself, 
you need ECM anyway, which is easy to install and almost infinitesimal small in 
size compared to Qt. And btw, where is the "should not pull in another 
dependency, even ECM" documentend? I only know of "Tier 1 Frameworks can depend 
only on Qt official frameworks or other system libraries" [1], which admittedly 
already creates a discrepancy with the ECM (build) requirement of ki18n itself.
  
  I'd also note that the macro already used KDEInstallDirs before, apparently 
without anybody complaining about it, even though I don't want to cargo cult 
this. Furthermore I'm not sure how to solve the bug I encountered differently, 
other than making marble stop using KDE_INSTALL_DIRS_NO_DEPRECATED (or using 
GnuInstallDirs, which possibly might break existing things).
  
  [1] https://community.kde.org/Frameworks/Policies

REPOSITORY
  R249 KI18n

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

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

D29136: Use non-deprecated KDEInstallDir

[Heiko Becker]

heikobecker updated this revision to Diff 81035.
heikobecker added a comment.


  Added missing parentheses

REPOSITORY
  R249 KI18n

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29136?vs=81033=81035

BRANCH
  master

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

AFFECTED FILES
  cmake/KF5I18nMacros.cmake.in

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

D29136: Use non-deprecated KDEInstallDir

[Heiko Becker]

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

REVISION SUMMARY
  I noticed that when installeding marble, which sets
  KDE_INSTALL_DIRS_NO_DEPRECATED, which then invalidates a possibly
  custom location set via KDEInstallIDirs, causing translations to
  land in a surprising locations.

TEST PLAN
  Marble's translations land in the desired location

REPOSITORY
  R249 KI18n

BRANCH
  master

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

AFFECTED FILES
  cmake/KF5I18nMacros.cmake.in

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

D28108: Handle busybox's sed like GNU sed

[Heiko Becker]

This revision was automatically updated to reflect the committed changes.
Closed by commit R266:0855a40a1131: Handle busyboxs sed like GNU sed 
(authored by heikobecker).

REPOSITORY
  R266 Breeze Icons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28108?vs=77864=77880

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

AFFECTED FILES
  generate-24px-versions.sh

To: heikobecker, #frameworks, apol
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D28108: Handle busybox's sed like GNU sed

[Heiko Becker]

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

REVISION SUMMARY
  Otherwise it uses the POSIX-style and fails with "sed: : No such file
  or directory".

TEST PLAN
  Built fine with busybox's sed

REPOSITORY
  R266 Breeze Icons

BRANCH
  master

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

AFFECTED FILES
  generate-24px-versions.sh

To: heikobecker, #frameworks
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D25795: Rename kf5quickcharts_example to kquickcharts_example

[Heiko Becker]

heikobecker closed this revision.
heikobecker added a comment.


  In D25795#612749 , @ahiemstra 
wrote:
  
  > @heikobecker This patch has been open for a long time... Do you have commit 
access or do you need someone to commit it for you?
  
  
  I have and I already committed it: 
https://cgit.kde.org/kquickcharts.git/commit/?id=e3ae6f929ebc5cb5f7cc4086bb98a21f382b2119
 No idea why this wasn't closed automatically.

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

To: heikobecker, #frameworks, ahiemstra, davidedmundson

D25794: ArraySourceTest: Use QTEST_GUILESS_MAIN

[Heiko Becker]

heikobecker added a comment.


  In D25794#612748 , @ahiemstra 
wrote:
  
  > @heikobecker This patch has been open for a long time... Do you have commit 
access or do you need someone to commit it for you?
  
  
  I have and I already committed it: 
https://cgit.kde.org/kquickcharts.git/commit/?id=d9d724b013024d3c332cc3bf9da02ff211637ebb
 No idea why this wasn't closed automatically.

BRANCH
  master

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

To: heikobecker, #frameworks, ahiemstra, davidedmundson

D25794: ArraySourceTest: Use QTEST_GUILESS_MAIN

[Heiko Becker]

heikobecker closed this revision.

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

To: heikobecker, #frameworks, ahiemstra, davidedmundson

D25795: Rename kf5quickcharts_example to kquickcharts_example

[Heiko Becker]

heikobecker created this revision.
heikobecker added reviewers: Frameworks, ahiemstra.
heikobecker requested review of this revision.

REVISION SUMMARY
  Matching the project name.

TEST PLAN
  exmaple is installed under the new name, runs fine

BRANCH
  master

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

AFFECTED FILES
  examples/charts/CMakeLists.txt

To: heikobecker, #frameworks, ahiemstra

D25794: ArraySourceTest: Use QTEST_GUILESS_MAIN

[Heiko Becker]

heikobecker created this revision.
heikobecker added reviewers: Frameworks, ahiemstra.
heikobecker requested review of this revision.

REVISION SUMMARY
  Allows the test to run without a display server.

TEST PLAN
  Builds, test still passes

BRANCH
  master

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

AFFECTED FILES
  autotests/ArraySourceTest.cpp

To: heikobecker, #frameworks, ahiemstra

Re: QT_DEPRECATED_BEFORE/KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x060000 considered harmful

[Heiko Becker]

On Friday, 25 October 2019 21:15:19 CEST, Friedrich W. H. Kossebau wrote:

Am Donnerstag, 24. Oktober 2019, 18:52:34 CEST schrieb laurent Montel:

Who told you that it will keep broken ?
If we show that it doesn't build we will fix it.
I don't see the problem. ...


The problem I see is availability of resources of people. And forcing them 
into caring for deprecated API. This should be an opt-in for those happy to 
work on deprecations once they appear.


It's especially annoying for packagers when testing new Qt versions. It's 
just wasted time to backport patches for that with no real benefit at all. 
I remember adding 30 patches (mostly to PIM packages) with one Qt update 
just to keep stuff compileable and 5.14 needs a few of these again. So 
please don't use -DQT_DISABLE_DEPRECATED_BEFORE=0x06 at least with 
releases. It's as bad as an idea like using -Werror with released code.


I see that some of these were added/moved behind an "if (EXISTS 
"${CMAKE_SOURCE_DIR}/.git")" so this mail might become obsolete, hopefully.


Cheers,
Heiko

D21695: Add FindTaglib.cmake

[Heiko Becker]

heikobecker added a comment.


  I'm not entirely sure about taglib-config on Windows and Android (can't test 
there), but similar to pkg-config I omitted the special casing. Tried to test 
this by moving taglib-config out of the way on Linux and a taglib install in 
default locations, which worked fine.

REPOSITORY
  R240 Extra CMake Modules

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

To: heikobecker, kde-buildsystem, kde-frameworks-devel
Cc: LeGast00n, bencreasy, michaelh, ngraham, bruns

D21695: Add FindTaglib.cmake

[Heiko Becker]

heikobecker created this revision.
heikobecker added reviewers: kde-buildsystem, kde-frameworks-devel.
Herald added projects: Frameworks, Build System.
heikobecker requested review of this revision.

REVISION SUMMARY
  The old one from KDELibs4 times is used by several projects from
  Frameworks, KDE Applications and Extragear.
  Modernized according the current cmake coding style but it also
  keeps compatibility with the old find module for now and should be
  a drop-in replacement.

TEST PLAN
  Removed the bundled FindTaglib.cmake from kfilemetadata, kio-extras,
  juk, amarok and rename and built them successfully.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

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

AFFECTED FILES
  find-modules/FindTaglib.cmake

To: heikobecker, kde-buildsystem, kde-frameworks-devel
Cc: LeGast00n, bencreasy, michaelh, ngraham, bruns

D17650: Install kioslave as kioslave5 on Windows

[Heiko Becker]

heikobecker added a comment.


  > no, it is only used in kio internally by klauncher to start io slaves.
  
  at least kinit disagrees:
  
src/klauncher/klauncher.cpp:1021
arg_list.prepend(QLatin1String("kioslave"));

REPOSITORY
  R241 KIO

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

To: habacker, #frameworks, lbeltrame, vonreth
Cc: bcooksley, heikobecker, ngraham, lbeltrame, kde-frameworks-devel, michaelh, 
bruns

D17650: Install kioslave as kioslave5 on Windows

[Heiko Becker]

heikobecker added a comment.


  In D17650#379396 , @habacker wrote:
  
  > I think this is unrelated - this request is to fix an issue with an 
available package on a distribution, so can anyone accept this ?
  
  
  I'd argue that the problem is with your distribution. Everybody still 
shipping qt4 is on its own anyway, seeing that it's not possible to upstream 
patches (and there are quite a few needed to keep it building) as the git repo 
is locked down. And I'm pretty sure this patch breaks at least one other 
framework. Additionally there might be future maintenance costs, so I see no 
reason to flog a dead horse and penalize everybody else for it.

REPOSITORY
  R241 KIO

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

To: habacker, #frameworks, lbeltrame, vonreth
Cc: heikobecker, ngraham, lbeltrame, kde-frameworks-devel, michaelh, bruns

D17479: Fix build without phonon

[Heiko Becker]

This revision was automatically updated to reflect the committed changes.
Closed by commit R305:78a1dcc794f5: Fix build without Phonon (authored by 
heikobecker).

REPOSITORY
  R305 KNotifyConfig

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D17479?vs=47283=47288

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

AFFECTED FILES
  src/CMakeLists.txt

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

D17479: Fix build without phonon

[Heiko Becker]

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

REVISION SUMMARY
  f6d55baf5aa88eaab6b2f96c025064f081d13cea 
 
replaced ${PHONON_LIBS} with
  Phonon's imported target. This breaks in the case when Phonon isn't
  found or disabled via -DCMAKE_DISABLE_FIND_PACKAGES_Phonon4Qt5=TRUE
  because the imported target isn't known. It worked previously because
  was ${PHONON_LIBS} just empty when Phonon wasn't available.

TEST PLAN
  Building without phonon works now and and it still builds
  with phonon available and successfully links to it.

REPOSITORY
  R305 KNotifyConfig

BRANCH
  master

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

AFFECTED FILES
  src/CMakeLists.txt

To: heikobecker
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D16183: KCrash: fix crash (ironic heh) when used in an app without QCoreApplication

[Heiko Becker]

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


  I can confirm that the crash doesn't occur anymore.

REPOSITORY
  R285 KCrash

BRANCH
  master

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

To: dfaure, heikobecker, aacid, sitter
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D15251: Fix autotests with -DBUILD_QCH:BOOL=TRUE

[Heiko Becker]

heikobecker added a comment.


  In D15251#322168 , @kossebau wrote:
  
  > ...as well as request to finally enable BUILD_QCH on CI, so this is covered.
  
  
  I wondered why that's not the case. I, for one, would welcome it.

REPOSITORY
  R249 KI18n

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

To: heikobecker, kossebau, habacker
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D15251: Fix autotests with -DBUILD_QCH:BOOL=TRUE

[Heiko Becker]

This revision was automatically updated to reflect the committed changes.
Closed by commit R249:7b2936a6d673: Fix autotests with -DBUILD_QCH:BOOL=TRUE 
(authored by heikobecker).

REPOSITORY
  R249 KI18n

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D15251?vs=40932=41194

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

AFFECTED FILES
  CMakeLists.txt

To: heikobecker, kossebau, habacker
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D15251: Fix autotests with -DBUILD_QCH:BOOL=TRUE

[Heiko Becker]

heikobecker added reviewers: kossebau, habacker.

REPOSITORY
  R249 KI18n

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

To: heikobecker, kossebau, habacker
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D15251: Fix autotests with -DBUILD_QCH:BOOL=TRUE

[Heiko Becker]

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

REVISION SUMMARY
  After 507415c54bd111fbb35716bd9809119d990f9a16 
 
KF5I18nQchTargets.cmake
  needs similar adjustments.

TEST PLAN
  The test passes again, KF5I18nQchTargets is still installed

REPOSITORY
  R249 KI18n

BRANCH
  master

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

AFFECTED FILES
  CMakeLists.txt

To: heikobecker
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D14008: Use QTEST_GUILESS_MAIN

[Heiko Becker]

This revision was automatically updated to reflect the committed changes.
Closed by commit R235:3a82a775b1c3: Use QTEST_GUILESS_MAIN (authored by 
heikobecker).

REPOSITORY
  R235 Attica

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D14008?vs=37463=39143

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

AFFECTED FILES
  autotests/configtest.cpp
  autotests/providertest.cpp

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

D14008: Use QTEST_GUILESS_MAIN

[Heiko Becker]

heikobecker added a comment.


  Ping?

REPOSITORY
  R235 Attica

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

To: heikobecker
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D14541: ECMOptionalAddSubdirectory: Provide a bit more detail

[Heiko Becker]

This revision was automatically updated to reflect the committed changes.
Closed by commit R240:59b311bcc2ed: ECMOptionalAddSubdirectory: Provide a bit 
more detail (authored by heikobecker).

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D14541?vs=38911=38915

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

AFFECTED FILES
  modules/ECMOptionalAddSubdirectory.cmake

To: heikobecker, apol
Cc: kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D14541: ECMOptionalAddSubdirectory: Provide a bit more detail

[Heiko Becker]

heikobecker created this revision.
Restricted Application added projects: Frameworks, Build System.
Restricted Application added subscribers: kde-buildsystem, kde-frameworks-devel.
heikobecker requested review of this revision.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

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

AFFECTED FILES
  modules/ECMOptionalAddSubdirectory.cmake

To: heikobecker
Cc: kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D14008: Use QTEST_GUILESS_MAIN

[Heiko Becker]

heikobecker created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: kde-frameworks-devel.
heikobecker requested review of this revision.

REVISION SUMMARY
  Allowing the tests to pass without a running X server.

REPOSITORY
  R235 Attica

BRANCH
  master

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

AFFECTED FILES
  autotests/configtest.cpp
  autotests/providertest.cpp

To: heikobecker
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D12872: ScalableTest, add "scalable" plasma-browser-integration

[Heiko Becker]

heikobecker added a comment.


  +1
  
  Btw, this is BUG: 393999

REPOSITORY
  R266 Breeze Icons

BRANCH
  scalable_pbi (branched from master)

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

To: maximilianocuria, #frameworks, dfaure, andreaska, andreask
Cc: heikobecker, kde-frameworks-devel, michaelh, ngraham, bruns

D12905: KF5I18NMacros: Don't install an empty dir when no po files exist

[Heiko Becker]

This revision was automatically updated to reflect the committed changes.
heikobecker marked an inline comment as done.
Closed by commit R249:918e304f057b: KF5I18NMacros: Dont install an empty 
dir when no po files exist (authored by heikobecker).

REPOSITORY
  R249 KI18n

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D12905?vs=34222=35777

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

AFFECTED FILES
  cmake/KF5I18NMacros.cmake.in

To: heikobecker, ilic, ltoscano
Cc: apol, ltoscano, kde-frameworks-devel, michaelh, ngraham, bruns

D12905: KF5I18NMacros: Don't install an empty dir when no po files exist

[Heiko Becker]

heikobecker marked an inline comment as done.
heikobecker added a comment.


  Considering the feedback I'll probably merge this in a few days if no 
objections turn up in the meantime.

INLINE COMMENTS

> ltoscano wrote in KF5I18NMacros.cmake.in:138-139
> I guess that those two lines are the critical parts (the call to file), but 
> probably it's not bad to avoid processing other instructions too.

Yes. And that was my thought as well and reason to move the rest inside the if

REPOSITORY
  R249 KI18n

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

To: heikobecker, ilic
Cc: apol, ltoscano, kde-frameworks-devel, michaelh, ngraham, bruns

D12905: KF5I18NMacros: Don't install an empty dir when no po files exist

[Heiko Becker]

heikobecker created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: kde-frameworks-devel.
heikobecker requested review of this revision.

REVISION SUMMARY
  I saw this happen with kdecoration from git since
  64d9f92f6a8708814f414dda0bb0d0e91c27235f 
. 
The directory passed in
  its ki18n_install call doesn't exist, resulting in an empty
  directory (LOCALE_INSTALL_DIR) getting installed, which at least
  some packaging systems don't like.

TEST PLAN
  Tested with kdecoration from git and tarballs where podir
  exists

REPOSITORY
  R249 KI18n

BRANCH
  master

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

AFFECTED FILES
  cmake/KF5I18NMacros.cmake.in

To: heikobecker
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D12216: Don't need to run previous iterations commands again

[Heiko Becker]

heikobecker added a comment.


  In D12216#247225 , @apol wrote:
  
  > I'm unsure if it's worth re-spinning ki18n.
  
  
  It's already out, so it would need a .1, but it may be worth it as it appears 
builds are hanging otherwise.

REPOSITORY
  R249 KI18n

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

To: apol, #frameworks, arojas
Cc: heikobecker, michaelh, ngraham, bruns

D12225: Also make installation of translated docs optional

[Heiko Becker]

This revision was automatically updated to reflect the committed changes.
Closed by commit R317:03d503362514: Also make installation of translated docs 
optional (authored by heikobecker).

REPOSITORY
  R317 Kross

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D12225?vs=32186=32273

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

AFFECTED FILES
  CMakeLists.txt

To: heikobecker, #frameworks, apol
Cc: michaelh, ngraham, bruns

D12225: Also make installation of translated docs optional

[Heiko Becker]

heikobecker created this revision.
heikobecker added reviewers: Frameworks, apol.
Restricted Application added a project: Frameworks.
heikobecker requested review of this revision.

REVISION SUMMARY
  76f3f5b541eea8128297e68bd80278e7f525c1aa 
 
made the dependency on
  KF5DocTools optional but forgot one instance when localized
  docs are installed, which will go unnoticed when one installs
  from git.

TEST PLAN
  Built with -DCMAKE_DISABLE_FIND_PACKAGE_KF5DocTools=TRUE

REPOSITORY
  R317 Kross

BRANCH
  master

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

AFFECTED FILES
  CMakeLists.txt

To: heikobecker, #frameworks, apol
Cc: michaelh, ngraham, bruns

D10340: Clean up old, unreachable code

[Heiko Becker]

This revision was automatically updated to reflect the committed changes.
Closed by commit R306:7387d21c4516: Clean up old, unreachable code (authored by 
heikobecker).

REPOSITORY
  R306 KParts

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10340?vs=26647=27537

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

AFFECTED FILES
  src/CMakeLists.txt
  src/browserrun_p.h

To: heikobecker, #frameworks, dfaure
Cc: elvisangelaccio, michaelh

D10339: Drop obsolete version checks

[Heiko Becker]

This revision was automatically updated to reflect the committed changes.
Closed by commit R306:faf16778ea6b: Drop obsolete version checks (authored by 
heikobecker).

REPOSITORY
  R306 KParts

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10339?vs=26646=26660

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

AFFECTED FILES
  src/browserextension.h
  src/liveconnectextension.h

To: heikobecker, #frameworks, apol
Cc: michaelh, ngraham

D10340: Clean up old, unreachable code

[Heiko Becker]

heikobecker created this revision.
heikobecker added a reviewer: Frameworks.
Restricted Application added a project: Frameworks.
heikobecker requested review of this revision.

REVISION SUMMARY
  Nepomuk is never searched for, so the removed code wasn't used in a
  long time. Furthermore Nepomuk is pretty dead.

REPOSITORY
  R306 KParts

BRANCH
  cleanupnepomuk

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

AFFECTED FILES
  src/CMakeLists.txt
  src/browserrun_p.h

To: heikobecker, #frameworks
Cc: michaelh, ngraham

D10339: Drop obsolete version checks

[Heiko Becker]

heikobecker created this revision.
heikobecker added a reviewer: Frameworks.
Restricted Application added a project: Frameworks.
heikobecker requested review of this revision.

REVISION SUMMARY
  Frameworks already require Qt 5.7.0.

REPOSITORY
  R306 KParts

BRANCH
  master

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

AFFECTED FILES
  src/browserextension.h
  src/liveconnectextension.h

To: heikobecker, #frameworks
Cc: michaelh, ngraham

Re: krename in kdereview

[Heiko Becker]

On 12/03/17 23:39, Albert Astals Cid wrote:
>> It's a batch renamer started outside of KDE and its infrastructure but
>> it was kind of abandoned and I got the ok the from the original author
>> to move it to git.kde.org.
>>
>> The code can be found at kde:krename.
>>
>> [..]
> 
> Maybe you want to use poppler instead of podofo for the pdf plugin? Since 
> Okular uses poppler most distros have it available, podofo seems to be a bit 
> more niche in that regard.

calibre also requires it here and it's also an optional dependency but
your point might have merit nevertheless and I guess it's not that hard
to get the same things from poppler.

> When in the Filename tab, wouldn't it make more sense for Simple Filename tab 
> to be first and not second?

Hmm, actually I only ever used the advanced tab. Which makes me think
the UI should be improved and there shouldn't be two tabs. Maybe
something like the advanced tab with helpful hints/shortcuts
buttons/highlighting for new users.

> Is it only me that Alt+4 doesn't select the 4th tab?

It seems to be only you ;-) or at least it works here.

> The list on the plugins tab seems to be working only on clicks instead of on 
> change, i.e. if i click on the first plugin and then use they keyboard arrows 
> to change to another plugin the right hand side contents don't change.

Fixed with 23d4701

Thanks for your review.

Best regards,
Heiko

D8672: Fix build with LibreSSL

[Heiko Becker]

This revision was automatically updated to reflect the committed changes.
heikobecker marked an inline comment as done.
Closed by commit R239:00cae452ac61: Fix build with LibreSSL (authored by 
heikobecker).

REPOSITORY
  R239 KDELibs4Support

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8672?vs=23309=23310

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

AFFECTED FILES
  src/kssl/kopenssl.cpp
  src/kssl/kopenssl.h
  src/kssl/ksslcertificate.cpp

To: heikobecker, #frameworks, #freebsd, dfaure
Cc: dfaure, asturmlechner

D8672: Fix build with LibreSSL

[Heiko Becker]

heikobecker marked an inline comment as done.
heikobecker added inline comments.

INLINE COMMENTS

> dfaure wrote in ksslcertificate.cpp:1225
> This seems to be missing parenthesis...
> 
> KSSL_HAVE_SSL && ( ... || ... )

Thanks, added.

REPOSITORY
  R239 KDELibs4Support

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

To: heikobecker, #frameworks, #freebsd, dfaure
Cc: dfaure, asturmlechner

D8672: Fix build with LibreSSL

[Heiko Becker]

heikobecker marked an inline comment as done.
heikobecker added inline comments.

INLINE COMMENTS

> dfaure wrote in kopenssl.cpp:1047
> this syntax will lead to a preprocessor warning when LIBRESSL_VERSION_NUMBER 
> isn't defined.
> Did you mean `|| defined(...)` ?

Yeah, that's indeed better...

REPOSITORY
  R239 KDELibs4Support

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

To: heikobecker, #frameworks, #freebsd, dfaure
Cc: dfaure, asturmlechner

D8672: Fix build with LibreSSL

[Heiko Becker]

heikobecker updated this revision to Diff 23301.
heikobecker added a comment.


  Added define(..)

REPOSITORY
  R239 KDELibs4Support

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8672?vs=21939=23301

BRANCH
  master

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

AFFECTED FILES
  src/kssl/kopenssl.cpp
  src/kssl/kopenssl.h
  src/kssl/ksslcertificate.cpp

To: heikobecker, #frameworks, #freebsd, dfaure
Cc: dfaure, asturmlechner

krename in kdereview

[Heiko Becker]

Hello,

thanks to the KDE Sysadmins krename was moved to kdereview today.

It's a batch renamer started outside of KDE and its infrastructure but
it was kind of abandoned and I got the ok the from the original author
to move it to git.kde.org.

The code can be found at kde:krename.

The intended target should be
extragear-or-whatever-that-thing-missing-a-proper-name-is/utils

Considering KDELibs4 reached the end of its life-cycle, I'd like to
release a beta version soon after krename passes review.

Questions? Comments?

Best regards,
Heiko

D8672: Fix build with LibreSSL

[Heiko Becker]

heikobecker added a reviewer: FreeBSD.

REPOSITORY
  R239 KDELibs4Support

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

To: heikobecker, #frameworks, #freebsd

D8672: Fix build with LibreSSL

[Heiko Becker]

heikobecker added a comment.


  Ping?

REPOSITORY
  R239 KDELibs4Support

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

To: heikobecker, #frameworks

D8672: Fix build with LibreSSL

[Heiko Becker]

heikobecker created this revision.
heikobecker added a reviewer: Frameworks.
Restricted Application added a project: Frameworks.

REVISION SUMMARY
  Unfortunately LibreSSL sets OPENSSL_VERSION_NUMBER to
  0x2000L and doesn't support the OpenSSL 1.1 API.

TEST PLAN
  Builds with LibreSSL

REPOSITORY
  R239 KDELibs4Support

BRANCH
  master

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

AFFECTED FILES
  src/kssl/kopenssl.cpp
  src/kssl/kopenssl.h
  src/kssl/ksslcertificate.cpp

To: heikobecker, #frameworks

D7478: Escape hyphen in rest.xml regular expressions

[Heiko Becker]

This revision was automatically updated to reflect the committed changes.
Closed by commit R216:ad077e4045e6: Escape hyphen in rest.xml regular 
expressions (authored by heikobecker).

REPOSITORY
  R216 Syntax Highlighting

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7478?vs=18602=18603

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

AFFECTED FILES
  data/syntax/rest.xml

To: heikobecker, #framework_syntax_hightlighting, kfunk, vkrause
Cc: dhaumann, alexeymin, #frameworks

D7478: Escape hyphen in rest.xml regular expressions

[Heiko Becker]

heikobecker updated this revision to Diff 18602.
heikobecker added a comment.


  Increased version

REPOSITORY
  R216 Syntax Highlighting

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7478?vs=18584=18602

BRANCH
  master

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

AFFECTED FILES
  data/syntax/rest.xml

To: heikobecker, #framework_syntax_hightlighting, kfunk, vkrause
Cc: dhaumann, alexeymin, #frameworks

D7478: Escape hyphen in rest.xml regular expressions

[Heiko Becker]

heikobecker added a comment.


  In https://phabricator.kde.org/D7478#138855, @alexeymin wrote:
  
  > Is it a fix for bug https://bugs.kde.org/show_bug.cgi?id=383632 ?
  
  
  Wasn't aware of the bug report, but yes. Will add a BUG: reference before 
pushing if this is accepted.

REPOSITORY
  R216 Syntax Highlighting

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

To: heikobecker, #framework_syntax_hightlighting, kfunk
Cc: alexeymin, #frameworks

D7478: Escape hyphen in rest.xml regular expressions

[Heiko Becker]

heikobecker updated this revision to Diff 18584.
heikobecker added a comment.


  Removed accidentally included change.

REPOSITORY
  R216 Syntax Highlighting

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7478?vs=18583=18584

BRANCH
  master

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

AFFECTED FILES
  data/syntax/rest.xml

To: heikobecker, #framework_syntax_hightlighting, kfunk
Cc: #frameworks

D7478: Escape hyphen in rest.xml regular expressions

[Heiko Becker]

heikobecker created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  The unescaped hyphen caused a build failure with pcre2-10.30 due to a broken
  regex: 'syntax-highlighting/data/syntax/rest.xml" line 27 broken regex:
  "^\\s*\\.\\. [w-_\\.]+::(\\s|$)" problem: "range out of order in character
  class" at offset 12'.
  
  The pcre2pattern documentation says this:
  
  "Perl treats a hyphen as a literal if it appears before or after a POSIX class
  (see below) or before or after a character type escape such as as \d or \H.
  However, unless the hyphen is the last character in the class, Perl outputs a
  warning in its warning mode, as this is most likely a user error. As PCRE2 has
  no facility for warning, an error is given in these cases."

TEST PLAN
  cmake && make && make test works fine pcre2-10.30, quick look at
  http://docutils.sourceforge.net/FAQ.txt in kate seems fine.

REPOSITORY
  R216 Syntax Highlighting

BRANCH
  master

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

AFFECTED FILES
  CMakeLists.txt
  data/syntax/rest.xml

To: heikobecker, #framework_syntax_hightlighting, kfunk
Cc: #frameworks

D7239: Drop unused dependency

[Heiko Becker]

This revision was automatically updated to reflect the committed changes.
Closed by commit R169:478b31fd1b92: Drop unused dependency (authored by 
heikobecker).

REPOSITORY
  R169 Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7239?vs=17984=18528

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

AFFECTED FILES
  CMakeLists.txt

To: heikobecker, #plasma, #frameworks, mart
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart, lukas

D7239: Drop unused dependency

[Heiko Becker]

heikobecker added a reviewer: Frameworks.

REPOSITORY
  R169 Kirigami

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

To: heikobecker, #plasma, #frameworks
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart, lukas

Re: Review Request 130193: [cmake]: De-duplicate "else" to fix build with cmake-3.9

[Heiko Becker]

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

(Updated Juli 20, 2017, 11:16 nachm.)


Status
--

This change has been marked as submitted.


Review request for kdelibs and Frank Osterfeld.


Repository: kdelibs


Description
---

Otherwise it errors out with:
"CMake Error at kdeui/CMakeLists.txt:316 (else): A duplicate ELSE
command was found inside an IF block."
Also adjust indentation to match the surrounding lines.


Diffs
-

  kdeui/CMakeLists.txt d6ec8b47e9af686441ab5ab761be9ff424cbb556 

Diff: https://git.reviewboard.kde.org/r/130193/diff/


Testing
---

Builds fine with cmake-3.9.0.


Thanks,

Heiko Becker

Review Request 130193: [cmake]: De-duplicate "else" to fix build with cmake-3.9

[Heiko Becker]

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

Review request for kdelibs and Frank Osterfeld.


Repository: kdelibs


Description
---

Otherwise it errors out with:
"CMake Error at kdeui/CMakeLists.txt:316 (else): A duplicate ELSE
command was found inside an IF block."
Also adjust indentation to match the surrounding lines.


Diffs
-

  kdeui/CMakeLists.txt d6ec8b47e9af686441ab5ab761be9ff424cbb556 

Diff: https://git.reviewboard.kde.org/r/130193/diff/


Testing
---

Builds fine with cmake-3.9.0.


Thanks,

Heiko Becker

D5289: Import Find{Clang,LLVM} from KDevelop for Python bindings generation

[Heiko Becker]

heikobecker added a comment.


  Ping? Not sure what to do with this, still would like to hear something from 
@skelly. Or should I just go ahead and use ClangConfig.cmake (meaning dropping 
the version requirement, I don't have any older clang versions around to easily 
test it.)

REPOSITORY
  R240 Extra CMake Modules

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

To: heikobecker, #frameworks, #build_system, skelly, kfunk
Cc: rdieter, shaheed, kde-buildsystem, lbeltrame

D4051: kcm_useraccount is dead, long live user_manager

[Heiko Becker]

This revision was automatically updated to reflect the committed changes.
Closed by commit R263:8f81a80f5dd9: kcm_useraccount is dead, long live 
user_manager (authored by heikobecker).

REPOSITORY
  R263 KXmlGui

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D4051?vs=9935=14061

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

AFFECTED FILES
  src/kbugreport.cpp

To: heikobecker, #frameworks, aacid