[frameworks/extra-cmake-modules] modules: Revert "ECMEnableSanitizers: do not enable linker flags when not supported"

[Bhushan Shah]

Git commit fffae63daa48648784919aec4b576034e44a2da0 by Bhushan Shah.
Committed on 26/01/2022 at 07:46.
Pushed by cgiboudeaux into branch 'master'.

Revert "ECMEnableSanitizers: do not enable linker flags when not supported"

This reverts commit abc3a698abc0dfea19040007a7c57d04c3bb6865.

Unfortunately it caused various problems:

- Minimum cmake version for extra-cmake-modules does not contain the
  required module
- Even with newer cmake it had issue with old policy that was not fixed
  until very late that breaks packages using old policy

CCMAIL: kde-frameworks-devel@kde.org

M  +10   -17   modules/ECMEnableSanitizers.cmake

https://invent.kde.org/frameworks/extra-cmake-modules/commit/fffae63daa48648784919aec4b576034e44a2da0

diff --git a/modules/ECMEnableSanitizers.cmake 
b/modules/ECMEnableSanitizers.cmake
index 42d5fcb7..84f1819c 100644
--- a/modules/ECMEnableSanitizers.cmake
+++ b/modules/ECMEnableSanitizers.cmake
@@ -74,7 +74,6 @@ This is an example of usage::
 Since 1.3.0.
 #]===]
 
-include(CheckLinkerFlag)
 # MACRO check_compiler_version
 #-
 macro (check_compiler_version gcc_required_version clang_required_version 
msvc_required_version)
@@ -148,24 +147,18 @@ if (ECM_ENABLE_SANITIZERS)
 string(TOLOWER ${CUR_SANITIZER} CUR_SANITIZER)
 # check option and enable appropriate flags
 enable_sanitizer_flags ( ${CUR_SANITIZER} )
-check_linker_flag(CXX "-l${XSAN_LINKER_FLAGS}" 
_HAVE_XSAN_LINKER_FLAGS)
-if (_HAVE_XSAN_LINKER_FLAGS)
-  # TODO: GCC will not link pthread library if enabled ASan
-  if(CMAKE_C_COMPILER_ID MATCHES "Clang")
-string(APPEND CMAKE_C_FLAGS " ${XSAN_COMPILE_FLAGS}")
-  endif()
-  string(APPEND CMAKE_CXX_FLAGS " ${XSAN_COMPILE_FLAGS}")
-  if(CMAKE_CXX_COMPILER_ID MATCHES "GNU")
-  link_libraries(${XSAN_LINKER_FLAGS})
-  endif()
-  if (CMAKE_CXX_COMPILER_ID MATCHES "Clang")
+# TODO: GCC will not link pthread library if enabled ASan
+if(CMAKE_C_COMPILER_ID MATCHES "Clang")
+  set( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${XSAN_COMPILE_FLAGS}" )
+endif()
+set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${XSAN_COMPILE_FLAGS}" )
+if(CMAKE_CXX_COMPILER_ID MATCHES "GNU")
+  link_libraries(${XSAN_LINKER_FLAGS})
+endif()
+if (CMAKE_CXX_COMPILER_ID MATCHES "Clang")
 string(REPLACE "-Wl,--no-undefined" "" 
CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}")
 string(REPLACE "-Wl,--no-undefined" "" 
CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS}")
-  endif ()
-else()
-  message(STATUS "Tried to enable sanitizers 
-DECM_ENABLE_SANITIZERS=${ECM_ENABLE_SANITIZERS}, \
-but linker does not have sanitizer support")
-endif()
+endif ()
 endforeach()
 else()
 message(STATUS "Tried to enable sanitizers 
(-DECM_ENABLE_SANITIZERS=${ECM_ENABLE_SANITIZERS}), \

Merge tags in master branch?

[Bhushan Shah]

Hello,

So I have one question regarding the how we do the framework versioning.
Namely the tags,

So currently some packages have a versioned tags on their master branch,

i.e

karchive:

➜ git describe
v5.76.0-1-g7304c28

While in case of some frameworks where translations needs to be taken
from svn, it is something super weird like,

kdesu:

➜ git describe
v5.2.0-234-gb7ba89f

Some packagers who package -git versions in their unstable repos check
the git describe to figure out what is current revision of the package
and having "wrong" version there bugs out weirdly.

Do anyone have any opinion on "merging" latest git tag in master branch?
and potentially doing that for next releases as well?

Thanks
-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

[sysadmin/repo-metadata] projects: projects: move new wayland repos to their final place

[Bhushan Shah]

Git commit 53d913c3af459024d359c13def87db8913d8ed6b by Bhushan Shah.
Committed on 29/04/2020 at 11:09.
Pushed by bshah into branch 'master'.

projects: move new wayland repos to their final place

- plasma-wayland-protocols -> frameworks
- kwayland-server -> kde/workspace

Ref: T13052

CCMAIL: kde-frameworks-devel@kde.org
CCMAIL: plasma-de...@kde.org

R  +0-0projects/frameworks/plasma-wayland-protocols/i18n.json [from: 
projects/playground/libs/kwayland-server/i18n.json - 100% similarity]
R  +1-1projects/frameworks/plasma-wayland-protocols/metadata.yaml 
[from: projects/playground/libs/plasma-wayland-protocols/metadata.yaml - 080% 
similarity]
R  +0-0projects/kde/workspace/kwayland-server/i18n.json [from: 
projects/playground/libs/plasma-wayland-protocols/i18n.json - 100% similarity]
R  +1-1projects/kde/workspace/kwayland-server/metadata.yaml [from: 
projects/playground/libs/kwayland-server/metadata.yaml - 082% similarity]

https://commits.kde.org/sysadmin/repo-metadata/53d913c3af459024d359c13def87db8913d8ed6b

diff --git a/projects/playground/libs/kwayland-server/i18n.json 
b/projects/frameworks/plasma-wayland-protocols/i18n.json
similarity index 100%
rename from projects/playground/libs/kwayland-server/i18n.json
rename to projects/frameworks/plasma-wayland-protocols/i18n.json
diff --git a/projects/playground/libs/plasma-wayland-protocols/metadata.yaml 
b/projects/frameworks/plasma-wayland-protocols/metadata.yaml
similarity index 80%
rename from projects/playground/libs/plasma-wayland-protocols/metadata.yaml
rename to projects/frameworks/plasma-wayland-protocols/metadata.yaml
index 9b1dba4..c0602cf 100644
--- a/projects/playground/libs/plasma-wayland-protocols/metadata.yaml
+++ b/projects/frameworks/plasma-wayland-protocols/metadata.yaml
@@ -5,7 +5,7 @@ members:
 - displayname: Aleix Pol
   username: apol
 name: Plasma Wayland Protocols
-projectpath: playground/libs/plasma-wayland-protocols
+projectpath: frameworks/plasma-wayland-protocols
 repoactive: true
 repopath: plasma-wayland-protocols
 type: project
diff --git a/projects/playground/libs/plasma-wayland-protocols/i18n.json 
b/projects/kde/workspace/kwayland-server/i18n.json
similarity index 100%
rename from projects/playground/libs/plasma-wayland-protocols/i18n.json
rename to projects/kde/workspace/kwayland-server/i18n.json
diff --git a/projects/playground/libs/kwayland-server/metadata.yaml 
b/projects/kde/workspace/kwayland-server/metadata.yaml
similarity index 82%
rename from projects/playground/libs/kwayland-server/metadata.yaml
rename to projects/kde/workspace/kwayland-server/metadata.yaml
index d6c5cd8..3f8d612 100644
--- a/projects/playground/libs/kwayland-server/metadata.yaml
+++ b/projects/kde/workspace/kwayland-server/metadata.yaml
@@ -5,7 +5,7 @@ members:
 - displayname: Aleix Pol
   username: apol
 name: KWayland Server
-projectpath: playground/libs/kwayland-server
+projectpath: kde/workspace/kwayland-server
 repoactive: true
 repopath: kwayland-server
 type: project

Information regarding upcoming Gitlab Migration: clarifications

[Bhushan Shah]

Good afternoon,

[Please keep sysad...@kde.org list or bs...@kde.org in the CC for
replies]

I want to clarify some bits for which we have gotten a questions about,

- Non unique naming: There's some teams which prefer if we dropped the
  namespace- part from their name which we have added. While currently
  this does not result in the naming conflict right away, we realize
  this will cause it at one point, for example,

  maui-dialer -> maui/dialer
  plasma-dialer -> plasma-mobile/dialer

  To minimize the impact of the Gitlab move we won't be doing such
  renames which introduce non-unique names right away. But we would
  prefer if the existing tooling or infrastructure is ready for this
  kind of cases at later point. Only way to enforce non-unique naming is
  one big KDE/ subgroup which we want to avoid.

  Current naming in the repo-metadata branch[1] I've pointed does not
  reflect those renames, as we are not planning to do those renames
  right away during gitlab move, but at a later stage.

- Existing configurations: we want to reduce impact on existing release
  schedule, and existing developer workflow,  therefore we will continue
  to privide the existing anongit.kde.org and git.kde.org (although this
  will be read-only) with current flat structuring for 3 weeks after
  actual migration, which will keep the existing scripts/clones working
  enough to give developers time to change to the new structure.

  We will also try to provide a script which allows you to migrate your
  existing clones to new repo paths and as mentioned by Ben in other
  message, potentially a git-kde script which would allow you to clone
  individual repository without knowing it's namespace (provided that
  there is no conflict of it's name). like "git kde karchive"

- Translations: we will co-ordinate with the translations team to let
  them adapt their tooling to updated structure as this requires changes
  on their side how translations are stored in svn repository

Thanks!

[1] 
https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Re: Information regarding upcoming Gitlab Migration

[Bhushan Shah]

Hi Adriaan,

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

We have a plan to provide a script which can change remotes in existing
clones. (It would take a top-level directory path for all your clones).

> Perhaps it's the "old school", but kdesrc-build doesn't do anything for me. 
> I'm intermittently interested in the source of some random part of KDE -- 
> generally because it's mentioned on IRC -- and then I need that source where 
> I 
> can look at it. Whether it's 'git clone' or 'kdesrc-build --just-the-source-
> please' doesn't matter much.
> 
> If there's any compiling to be done, the less magic there is between me and 
> the compile, the better.
> 
> So, yeah: `git clone kde:x` all the way, but I'm also not really invested in 
> the structure of the label x, or the precise configuration of kde:.
> 
> 
> > Now, if a simple(ish) script can be created to make
> > something akin to the kde: rewriting work, even if what it really does is to
> > search gitlab and create a clone with the appropriate command, i could deal
> > with that, but having the ability to simply ask for the project name is
> > more than a little useful.
> 
> I think we shouldn't underestimate how names are a social construct, though: 
> the current flat structure comes after a structured SVN naming epoch. But I'd 
> totes +1 a search-and-redirector, especially if it means I can write `git 
> clone kde:peruse` and the resulting .git/config has followed the redirects 
> and 
> whatnot and ended up with `url: kdeforreal:audio/peruse`

One thing to remember is, you can't really have a dynamic insteadOf URL
setup. Besides, even if we had a everything under KDE namespace I'd find
a setup for this weird enough.

Let's assume that everything is under invent.kde.org/kde (and
invent.kde.org/sysadmin and invent.kde.org/websites as it is right now).

Now you add a following snippet in gitconfig,

 [url "https://invent.kde.org/KDE/";]
 insteadOf = kde:
 [url "g...@invent.kde.org:KDE/"]
 pushInsteadOf = kde:

Which is slightly modified version of the existing kde: URL helper shown here,
https://community.kde.org/Sysadmin/GitKdeOrgManual#Let_Git_rewrite_URL_prefixes

Now this is perfectly fine for the something which is kde/ so you can do
git clone kde:krita and it would happily replace 'kde:' part with
'https://invent.kde.org/KDE/' and would clone 
'https://invent.kde.org/KDE/krita' 

But, now things get interesting when you want to clone the
docs-krita-org which is in the websites/ namespace. We will have to keep
this things in separate namespace for policy reasons (and same goes for
sysadmin stuff). How would you clone docs-krita-org?

git clone kde:../websites/krita-org ?
add a separate prefix for websites and sysadmin?

Let's assume that you added snippet for sysadmin and websites, it's
just 8 more lines after all,

 [url "https://invent.kde.org/websites/";]
 insteadOf = websites:
 [url "g...@invent.kde.org:websites/"]
 pushInsteadOf = websites:
 [url "https://invent.kde.org/sysadmin/";]
 insteadOf = sysadmin:
 [url "g...@invent.kde.org:sysadmin/"]
 pushInsteadOf = sysadmin:

Does this solve all use-cases? I believe no, it still does not support
the personal repositories of users. So you also need to add 4 more lines
for your own user, and 4 for each user whose repository you want to
clone.

What our workflow with the kde: prefix so far had been really useful I
agree, and I will miss it, but with departure of gitolite which allowed
repositories at top-level, we can't easily support this, and we have to
accept it.

Perhaps solution suggested by Ben in his email could be useful instead
and in addition generic invent: snippet which does not include any
namespace.

 [url "https://invent.kde.org/";]
 insteadOf = invent:
 [url "g...@invent.kde.org:"]
 pushInsteadOf = invent:

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

Just to clarify, sysadmins have no plan to support or maintain the cgit
instance once we migrate to Gitlab.

Thanks

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Re: Information regarding upcoming Gitlab Migration

[Bhushan Shah]

Hi Olivier,

On Mon, Apr 27, 2020 at 10:49:46PM +0200, Olivier Churlaud wrote:
> >Because in order to search for something, you need to know it exists.
> >
> >If you are just casually browsing, then the search can't help you.
> 
> I don't think people casually browse our repos. What use case is more likely 
> to happen and do we want to support? 

We don't really want to discard use-cases just because it does not suit
our workflow. That is not how we are going to gain new contributors, we
should value each contribution, be it drive-by contribution, or focused
contribution towards one single project.

> Use case 1 : Jerry learns about KDE and go in their forge in the Multimedia 
> section. After carefully reading the code of two applications and three libs 
> he starts contributing to Elisa. 
> 
> Use case 2 : While using her Ubuntu installation of Elisa / while reading on 
> reddit about Elisa, Jerry decides to try to contribute to this project/fix 
> this bug that itches her and searches for it in KDE's forge. 

Let me add a some more usecases, some of which I've been dealing with in
project I maintain.

Use case 3 : Tom comes in Plasma Mobile channel and asks for Plasma
Mobile applications source code

Use case 4 : Tom is a student in Germany and is interested in
contributing to wikitolearn, and he asks where can I find code of the
wikitolearn?

Suggestion offered by sysadmin team does not cater to one single
use-case, but offers a way to provide a solution to all 4 usecases. For
Plasma Mobile team or Wikitolearn team it would be much easier to refer
contributors to the https://invent.kde.org/plasma-mobile or
https://invent.kde.org/wikitolearn then tell them to go to
https://invent.kde.org/KDE and search for the tag wikitolearn or Plasma
Mobile.

> On the other hand, I think the discussion about spotting open merge requests 
> (in a derived thread from this one) should be answered, being by relevant 
> tags, subgroups or whatever. 

(super personal note)

Ironically, Usecase 1 is how I started contributing to KDE 7 years back.
While I was inspired by battery monitor re-design in 4.11 release, I
wanted to work on "something" so I did literally browse through various
repositories to find something where my technical capabilities were
enough to work on [1]. Back then it was projects.kde.org (chiliproject
installation).

[1] https://blog.bshah.in/2013/09/01/hello-planet/

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Re: Information regarding upcoming Gitlab Migration

[Bhushan Shah]

Hi Ingo,

On Mon, Apr 27, 2020 at 03:46:13PM +0200, Ingo Klöcker wrote:
> > > I'm sorry, but I don't think that this is solved by your proposal for the
> > > KDE PIM projects because not everything related to KDE PIM (e.g. relevant
> > > frameworks like kcontacts, kholidays, kpeople and soon kdav) will be in
> > > the same group. The same is true for any project which uses some
> > > frameworks, e.g. graphics and the imageformats framework or whatever
> > > group kate and kwrite are going to end up in and the ktexteditor
> > > framework.
> > 
> > This is something which can be easily solved by Gitlab, Gitlab offers a
> > solution where project can be shared with another group.
> > 
> > So e.g. sharing kcontacts with kdepim should be possible, then all merge
> > requests/issues from kcontacts would show up under pim as well.
> 
> Great. So we could put all repos into an "all" group (e.g. rename kde to all) 
> and then have every subcommunity decide for themselves which repos they want 
> to see in their group.

No, sadly this does not work, I just tested this,

I have two different groups here

- https://invent.kde.org/sysadmin/test/test1
- https://invent.kde.org/sysadmin/test/test2

test1 have a repo called foo under it, which is shared with the test2
group. When someone visits test2, they are not offered the list of the
shared repositories but they are instead offered the empty page. One
have to click on Shared repositories tab to actually see the list.

https://invent.kde.org/groups/sysadmin/test/test2/-/shared

This defeats the purpose of the creating subgroups (offering easy
reachability).

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Re: Information regarding upcoming Gitlab Migration

[Bhushan Shah]

Hi Nate,

On Mon, Apr 27, 2020 at 07:45:23AM -0600, Nate Graham wrote:
> Trying to categorize everything into a single group cannot succeed because
> many projects could logically belong to multiple groups (e.g
> plasma-framework is a framework that's a part of Plasma; Discover is an app
> that's a part of Plasma; kdenetwork-filesharing and kio-extras are libraries
> that are distributed via the apps release service). I foresee endless
> pointless arguments about the best group for something to live in.

I've agreed in previous threads that sometime our grouping is not
perfect, but this is something we can improve instead of throwing idea
of grouping out altogether.

> Let's step back: do we have to put every repo inside a group in the first
> place? Is it solely so you can look at a nice list of all open merge
> requests for PIM/Frameworks/etc? If so, perhaps this workflow could be
> approximated with tags instead or group assignments instead

No goal is not just that you get nice list of all open merge requests or
issues. Main goal is we want to offer user or potential contributors a
list of closely related projects instead of list of all 1100+ projects
we have. That would mean, If user wants to see all frameworks, or
graphics applications, or multimedia applications, they can.

The workflow, with labels you mention is trying to achieve a totally
different goal then what we are trying to solve here. Labels/Tags are
for sorting issues, and/or merge requests. They can't be reliable
solution for the sorting of the multiple repositories.

On technical side, Gitlab does not offer labels for projects, but
setting called topic. You can see that in screenshot[1] linked. Besides,
from home page there's no way to filter something for e.g "Graphics".
nore project listing shows the tags alongside of the project names, also
making use of this tags means that if user clicks this tags, what they
are offered is *all* the repositories including forks of the
repositories, which means when you search for graphics [2], you get many
duplicative results and this is really not something discoverable.

> We create many very granular groups for the purposes of organizing teams and
> and performing code review (e.g. Plasma, KWin, Frameworks, PIM, Krita,
> Dolphin, Okular, VDG, etc.) and then every new merge request could receive a
> tag or assignee corresponding to its relevant code review groups (e.g. merge
> requests for kio and kio-extras could get get tagged with both "Frameworks",
> and "Dolphin"; plasma-frameworks MRs could get tagged with both "Plasma" and
> "Frameworks", and so on).

As explained above, while grouping repositories is trying to solve the
merge requests/issue organization, it is not sole purpose of the
suggested grouping, discoverability and reachability is the main issue
we are trying to solve here.

[1] https://i.imgur.com/h1L1A5H.png
[2] https://i.imgur.com/ajOszEL.png

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Re: Information regarding upcoming Gitlab Migration

[Bhushan Shah]

In part I am mostly re-iterating what Ben already mentioned in different
messages.

On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote:
> Does this mean that to clone it we'll have to go "git clone
> kde:games/knetwalk" or something along the lines?

Yes

[Rest of message is with sysadmin hat off and as a developer]

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

I do agree that it maybe small inconvience, but let's be honest, most of
us have been using kdesrc-build or some kind of automated tooling for
building everything, apart from very rare case we never have to manually
clone any of KDE repository, at least it is true for me personally. I am
not sure about others.

[Very non-scientific test, I did "history | grep 'git clone kde:'" on my
machine and only instances were 4, websites/conf-kde-in,
kde-build-metadata, sysadmin/irc-notifications,
sysadmin/binary-factory-tooling, rest was automatically downloaded by
the kdesrc-build]

Anyway, getting back on topic, while this option gives some initial
setbacks in our own personal workflow, let's look at bigger picture.

Let's say I am the new developer who wants to contribute to frameworks.
One of reason we are switching to gitlab is better onboarding, current
state is that we have cgit.kde.org as a repository browser.

By default I open it, I get the sorting by name, first repository is
abakus. Commits as old as 14 years(!), after that some more mix of
unmaintained repositories and scrolling almost 1.5 page, I get greeted
with baloo, first framework in whole list. Let's just assume that name
based sorting is bad idea, and we sort by activity instead.

Here I get much better results, first framework is solid. But at same
time if I was looking for SDK, kdevelop would appear at 3rd scroll-page.
Here cgit is able to show many items in single scroll page, you can be
assured that on gitlab it would not show kdevelop in first 6-7 pages.

You might wonder why search does not help here? So problem with search
is you need to know what you are looking for[*], but drive-by
contributors, or users who are simply browsing our repositories won't
know what they are looking for, they are simply trying to find a thing
that interests them. Giving them categories/groups allows them to focus
on topic they like and they can contribute to.

> e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> krita graphics or its own thing?

I agree that categories are something which we can improve upon, but
this is something which we can improve upon, rejecting idea of
categories just because 7-10 repos are at wrong place is ultimately not
going to do anything good.

> I really prefer when I don't have to guess this kind of things when
> fetching a repository.

[*] Ironically, in your case search would be helpful as you know you are
looking for knetwalk so you can just add it and search it

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Information regarding upcoming Gitlab Migration

[Bhushan Shah]

[Please keep sysad...@kde.org list or bs...@kde.org in the CC for
replies]

Hello Community members,

In view of upcoming Gitlab migration, we sysadmin team wants to share
the recommended structuring for the repositories on Gitlab.

We had multiple options,

- Flat structure: In this option we would have everything under one
  single namespace/group: https://invent.kde.org/kde/knetwalk
- Subgroups under top-level group: In this option we would have a groups
  under KDE namespace: https://invent.kde.org/kde/games/knetwalk
- Groups at top level: In this option we would establish a series of
  groups at the top level, e.g.  https://invent.kde.org/games/knetwalk

We have discussed this with small but representative group of
contributors or maintainers, and based on their suggestions, we
recommend that we go with option 3. Having sub-groups at top level will
allow us to,

- Provides good visibility on all reviews, tasks and other items within
  the groups/modules we define
- Provides improvements to discoverability of projects
- Makes it possible for groups of projects to establish a group level
  task board should it fit their needs (for tracking a release for
  instance)
- Makes the most semantic sense, as the ‘KDE’ top level group suggested
  in option 2 is duplicative considering the Gitlab instance is under
  kde.org.
- The discoverability of projects is maximised, as there is no need to
  open the top level ‘KDE’ group before going into the subgroup.

I've worked on draft "move" of the current set of the repositories in
their respective subgroups at the repo-metadata project's branch [1].
You can browse the directory structure to get idea of how final
structure on Gitlab would look like.

If we don't have any objections we would like to implement this next
week and move projects to https://invent.kde.org.

Thanks!
Bhushan for sysadmin team

[1] 
https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

D28163: Add input-dialpad and call-voicemail

[Bhushan Shah]

bshah added a comment.


  Hmm yeah I am also not a fan of the stretched out dialpad icon

REPOSITORY
  R266 Breeze Icons

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

To: ndavis, #vdg
Cc: ngraham, bshah, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, 
bruns

D28114: Add call-incoming/missed/outgoing

[Bhushan Shah]

bshah added a subscriber: jbbgameich.

REPOSITORY
  R266 Breeze Icons

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

To: ndavis, #vdg
Cc: jbbgameich, bshah, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, 
ngraham, bruns

D27708: Cleanup accounts kded module

[Bhushan Shah]

bshah accepted this revision.

REPOSITORY
  R155 KAccounts Integration

BRANCH
  arcpatch-D27708

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

To: nicolasfella, #frameworks, bshah, leinir

D27637: kill twitter support

[Bhushan Shah]

bshah accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R495 Purpose Library

BRANCH
  killtwitter

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

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

D27622: only find bash once

[Bhushan Shah]

bshah accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R266 Breeze Icons

BRANCH
  master

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

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

D27614: build: fix the build where install prefix is not user-writable

[Bhushan Shah]

This revision was automatically updated to reflect the committed changes.
Closed by commit R266:462c5dfe2e9a: build: fix the build where install prefix 
is not user-writable (authored by bshah).

REPOSITORY
  R266 Breeze Icons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27614?vs=76278&id=76279

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

AFFECTED FILES
  icons-dark/CMakeLists.txt
  icons/CMakeLists.txt
  validate_svg.sh

To: bshah, ngraham, lbeltrame, sitter
Cc: sitter, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27614: build: fix the build where install prefix is not user-writable

[Bhushan Shah]

bshah updated this revision to Diff 76278.
bshah added a comment.


  rebase

REPOSITORY
  R266 Breeze Icons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27614?vs=76256&id=76278

BRANCH
  bshah/fix-build

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

AFFECTED FILES
  icons-dark/CMakeLists.txt
  icons/CMakeLists.txt
  validate_svg.sh

To: bshah, ngraham, lbeltrame, sitter
Cc: sitter, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27614: build: fix the build where install prefix is not user-writable

[Bhushan Shah]

bshah created this revision.
bshah added reviewers: ngraham, lbeltrame.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
bshah requested review of this revision.

REVISION SUMMARY
  - Validate only the files and symlinks
  - Fix target names, they were swapped
  - generate the icons in build-dir and then install it

TEST PLAN
  done make and make install and verified install_manifest.txt looks sane

REPOSITORY
  R266 Breeze Icons

BRANCH
  bshah/fix-build

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

AFFECTED FILES
  icons-dark/CMakeLists.txt
  icons/CMakeLists.txt
  validate_svg.sh

To: bshah, ngraham, lbeltrame
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D26273: cmake: don't use taglib-config if we are cross compiling

[Bhushan Shah]

bshah created this revision.
bshah added a reviewer: vkrause.
Herald added projects: Frameworks, Baloo.
Herald added subscribers: Baloo, kde-frameworks-devel.
bshah requested review of this revision.

REVISION SUMMARY
  If we are cross compiling two things are possible,
  
  - cmake finds host taglib-config
  - cmake finds target taglib-config in sysroot
  
  depending on toolchain configuration. In both cases taglib-config values
  are useless since, we can't link to host libraries or can't run target
  taglib-config in most cases.

TEST PLAN
  tested it finds the taglib from sysroot when cross compiling

REPOSITORY
  R286 KFileMetaData

BRANCH
  bshah/cross

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

AFFECTED FILES
  cmake/FindTaglib.cmake

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

D22968: Make it possible to modify contacts

[Bhushan Shah]

bshah requested changes to this revision.
bshah added inline comments.
This revision now requires changes to proceed.

INLINE COMMENTS

> abstracteditablecontact.h:31
> + *
> + * @since 5.60
> + * @internal

Since 5.62

> persondata.h:103
>  
> +Q_SCRIPTABLE bool setContactCustomProperty(const QString &key, const 
> QVariant &value);
> +

Missing API docs

> persondata.h:126
>  
> +bool isEditable() const;
> +

Missing API doc

REPOSITORY
  R307 KPeople

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

To: apol, #frameworks, jbbgameich, bshah
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

KCalendarCore plugins/datasources?

[Bhushan Shah]

[I am not subscribed to kde-pim list, please keep me or k-f-d in CC]

Hello,

So yesterday I was discussing this with the Volker in #kde-devel, that
currently kcalcore doesn't provide a "plugin interface" to create a
various data sources like, file storage, online/cloud storage, or
akonadi storage, and Akonadi have it's own custom code for this.

Would it make sense to have something like this in kcalcore itself?
Volker mentioned to me that it needs close look at Akonadi based
implementation and trying to finalize API.

Thanks

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

D22836: Fix checking dirs for metainfo.yaml with non-ascii chars with Python 2.7

[Bhushan Shah]

bshah accepted this revision.
bshah added a comment.


  As a short term workaround, this is fine, in terms of porting to python3 it 
will also need changes on our server zivo.kde.org which is hosting api.kde.org, 
right now every scripts including krazy2 and apidox generation scripts are too 
much complex, and current system is running Gentoo. So overall this asks for 
much more effort. https://invent.kde.org/branislavaz/documentation-generator is 
one of steps to tidify all this and get things working properly.
  
  For now I am in favor of submitting this.

REPOSITORY
  R264 KApiDox

BRANCH
  handlenonasciipathwpython27

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

To: kossebau, ochurlaud, bshah, aacid
Cc: davidre, aacid, pino, kde-frameworks-devel, kde-doc-english, LeGast00n, 
sbergeron, gennad, fbampaloukas, michaelh, ngraham, bruns, skadinna

D22425: personsmodel: Add phoneNumber

[Bhushan Shah]

bshah added a reviewer: apol.

REPOSITORY
  R307 KPeople

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

To: jbbgameich, #plasma:_mobile, #kde_pim, apol
Cc: kde-frameworks-devel, LeGast00n, sbergeron, michaelh, ngraham, bruns

D22049: pluginloader: Change behavior of X-KDE-ParentApp

[Bhushan Shah]

This revision was automatically updated to reflect the committed changes.
Closed by commit R242:7ae271987ca2: pluginloader: Change behavior of 
X-KDE-ParentApp (authored by bshah).

REPOSITORY
  R242 Plasma Framework (Library)

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22049?vs=60501&id=60636

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

AFFECTED FILES
  src/plasma/pluginloader.cpp
  src/plasma/pluginloader.h

To: bshah, mart, apol
Cc: kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns

D22049: pluginloader: Change behavior of X-KDE-ParentApp

[Bhushan Shah]

bshah created this revision.
bshah added reviewers: mart, apol.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
bshah requested review of this revision.

REVISION SUMMARY
  X-KDE-ParentApp is the key in desktop file to display that given service
  or application is part of the another application or extension of other
  application. In KDE4 this key was used to mark applets to be used in the
  specific application like plasma-desktop, kdevelop, amarok etc.
  
  In KF5 world, none of this applications have applet loading mechanism
  apart from plasma*, and there are likely only Plasma applet, containment
  or dataengines.
  
  Previous API, when no/empty parentApp was passed would filter out every
  application which had something as parentApp. This was to ensure only
  compatible plugins are loaded in Plasma. This resulted in applets
  getting excluded if they suggested that org.kde.plasmashell is their
  parent application. Refine this API to,
  
  - If no/empty parentApp is provided, provide all applets
  - If parentApp is provided, filter by applet
  
  This behavior is more filter like instead of other way around.
  
  CHANGELOG: Applet, DataEngine and containment listing methods in
  Plasma::PluginLoader no longer filters the plugins with X-KDE-ParentApp
  provided when empty string is passed.

TEST PLAN
  tested that plasma loads properly, plasmaengineexplorer lists
  all engines and plasmawindowed works fine. Neverthless requires more testing

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  master

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

AFFECTED FILES
  src/plasma/pluginloader.cpp
  src/plasma/pluginloader.h

To: bshah, mart, apol
Cc: kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns

D21778: Add some documentation for PlatformDependent

[Bhushan Shah]

This revision was automatically updated to reflect the committed changes.
Closed by commit R235:fbda1d799cc1: Add some documentation for 
PlatformDependent (authored by bshah).

REPOSITORY
  R235 Attica

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D21778?vs=59711&id=59712

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

AFFECTED FILES
  src/platformdependent.h

To: bshah, leinir
Cc: kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns

D21778: Add some documentation for PlatformDependent

[Bhushan Shah]

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

REVISION SUMMARY
  Also add note about deprecating askForCredentials and saveCredentials in
  future.

REPOSITORY
  R235 Attica

BRANCH
  bshah/docs

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

AFFECTED FILES
  src/platformdependent.h

To: bshah, leinir
Cc: kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns

Re: [sysadmin/ci-tooling] build-specs/Plasma: Disable execution of tests for plasma-integration.

[Bhushan Shah]

> 
> Can we try to get this documented? 1.7GB isn't a lot for lots of people with 
> fast internet (if the server serves fast enough).

https://invent.kde.org/sysadmin/ci-tooling/wikis/CI-On-Local-Machine

I have added some initial documentation here, which I will improve
later.

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

D17808: Don't force Phonon on Android

[Bhushan Shah]

bshah accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

To: vkrause, bshah
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D17345: Support Bluetooth batteries

[Bhushan Shah]

bshah accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R245 Solid

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

To: broulik, #plasma, bruns, davidedmundson, bshah
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

Re: Downtime announcement: www.kde.org

[Bhushan Shah]

[sending again from right address since my gmail address is not
subscribed to somee lists]

Hello,

On Mon, Nov 05, 2018 at 11:02:43PM +1300, Ben Cooksley wrote:
> > In order to allow for hardware maintenance, one of our physical
> > hardware hosts will need to be shutdown for a few hours on Monday.
> > This downtime will commence around 9:30am UTC and may take several
> > hours.

The maintenance is now completed, and as far as we are aware, all
services are now back up. If you have trouble accessing any of services,
please let us know over email or sysadmin ticket.

Thanks!

> >
> > During this time a number of sites will be inaccessible, including:
> > - www.kde.org
> > - autoconfig.kde.org
> > - docs.kde.org
> > - ev.kde.org
> > - freebsd.kde.org
> > - hig.kde.org
> > - kdesrc-build.kde.org
> > - neon.kde.org
> > - releases.neon.kde.org
> > - networkcheck.kde.org
> > - planet.kde.org
> >
> > Other websites within KDE.org that are dependent on resources hosted
> > on those sites may also experience delayed loading times in browsers
> > during this window.
> >
> > As some of these sites are relied upon by applications to function
> > properly, those applications may experience degraded functionality
> > during this time.
> >
> > Affected applications include:
> > - Discover
> > - Kaffeine
> > - Kopete
> > - Plasma Network Manager (when behind a captive portal)
> > - Any application using GHNS
> >
> > In addition, any other site which is hosted by the server known as
> > "olios.kde.org" will also be unavailable during this time.
> >
> > Apologies for any inconvenience caused.
> 
> The maintenance window has now commenced.
> The above sites will be inaccessible until the maintenance is completed.
> 
> >
> > Regards,
> > Ben Cooksley
> > KDE Sysadmin
> 
> Regards,
> Ben

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Re: Pre-review CI

[Bhushan Shah]

On Mon, Jul 30, 2018 at 11:50:48AM +0200, Friedrich W. H. Kossebau wrote:
> More advantages with parallel builds:
> * bigger projects, where building takes some time (krita, kdevelop, plasma-*, 
> etc) and where sometimes patches are reviewed almost in sync, parallel builds 
> mean quicker feedback
> * when doing fix-up for patches which fail on a platform, getting quicker 
> feedback would be also good
> * parallel builds might also mean easier report for results on the different 
> platforms in the jenkins page, so one can quickly see on which platform there 
> are issues (and which experts might be needed)
> * a platform being broken on normal CI for some unrelated reason (outdated 
> deps, platform issues) will also mean the review build breaks there, in that 
> case any later platforms in the single job build would not be reached for 
> review feedback
> * platform-specific issues (like missing includes) which need platform 
> experts 
> will result in a fail before reaching other issues (like regressions in 
> tests), having parallel builds would allow the non-build failing platforms to 
> also run the tests and allow the developer to already investigate the test 
> regression, while waiting for the platform experts to help out with the 
> platform specific issues
> 
> So unless we are short of resources on CI, I really would favour separate 
> builds, to always get feedback for all platforms, instead of doing some try & 
> error walk through all platforms one by one, with the others having to wait 
> for the earlier (and respective people to sort out things there).
> 
> Let's make sure things can be worked in parallel where possible, and as quick 
> as possible, given most FLOSS contributors only have small time snippets to 
> do 
> things.

Your arguments makes sense perfectly.

> Which brings another question: how long would review build logs be kept?
> 
> I could imagine that discarding once a review is closed (discarded or 
> committed) would be fine. But while a review request is open, keeping also 
> build logs for older revisions (at least to a certain count) of a patch under 
> review would be good to have, as sometimes one needs to compare results for 
> different versions.

Builds will stay on CI as long as the review request is open, also we
are thinking of the "cleanup" at regular period to purge the review
request builds which had no updates in "some period".

Thanks

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Re: Pre-review CI

[Bhushan Shah]

On Sun, Jul 29, 2018 at 05:00:19PM +0200, Friedrich W. H. Kossebau wrote:
> 1 job means one huge build log to look at, or? In that case I would prefer 
> separate jobs. Given review requests are prone to fail.

Thing is, you don't care about the pre-review CI jobs as long as they
are passing, but in case of fail, yes you might have to look at long
log depending on where failure was, in first platform or last one.

> compare to non-review build jobs, I would assume. And having jobs separate 
> also means one gets results for any platforms, does not stop on the first 
> failing?

Yes, but it also means that if there is obvious mistake in review, all
will fail, insteaad of bailing out earlier.

> All that said though without having seen how a one-job-to-rule-them-all would 
> look like, and how the others. Any chance for some samples, please?

We haven't enabled multi-platform jobs currently but it would be
basically for each platform (linux, windows, FreeBSD, Android). It will
execute them in order, and if one fails, it will just bail out.

> > - Should we send out comment for failure and success? Or is it easier to
> >   figure out the console log link without the comment? See linked review
> >   for example [1].
> 
> [1] -> [2] here.
> 
> What do you mean exactly by "send out comment for failure and success"? More 
> emails? (Please not). That example works fine with me, but not sure what the 
> alternative is?

The alternative being, instead of jenkins-ci comemnting with link, you
find it manually in Diff detail section, see screenshot

https://screenshots.firefox.com/1GG7B0bPLod3QMFg/phabricator.kde.org

Here, the "Jenkins" after the "Build 1313: Frameworks Pre-Review CI" is
link to jenkins build. But the test was if you were able to spot it in
first glance, and it failed. :P so yeah we will keep comments enabled
even if it means extra emails.

> Cheers and Thanks again for improving the review system
> Friedrich

Thanks

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Pre-review CI

[Bhushan Shah]

Hello,

So in previous email about staging repository I talked about pre-review
CI [1]. After some time, we finally have some code in ci-tooling which can
handle the pre-review CI for KDE repositories. And for initial pilot run
we want to enable it for frameworks repositories.

We have several questions about this though,

- Should we have seperate CI jobs per platform (Linux, Windows, FreeBSD,
  Android) for review? or just 1 job which runs the builds across all
  platforms?
- Should we send out comment for failure and success? Or is it easier to
  figure out the console log link without the comment? See linked review
  for example [1].

Looking forward to feedback.

Thanks!

[1] https://mail.kde.org/pipermail/kde-frameworks-devel/2018-June/065616.html
[2] https://phabricator.kde.org/D14438

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

D13819: dummy commit to test pre-review CI

[Bhushan Shah]

bshah removed a project: Frameworks.
bshah removed a subscriber: kde-frameworks-devel.
Restricted Application added a project: Frameworks.

REPOSITORY
  R243 KArchive

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

To: bshah
Cc: jenkins-ci, michaelh, ngraham, bruns, kde-frameworks-devel

D13819: dummy commit to test pre-review CI

[Bhushan Shah]

bshah updated this revision to Diff 38634.
bshah added a comment.


  - Revert "make it fail"
  - break test

REPOSITORY
  R243 KArchive

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13819?vs=38632&id=38634

BRANCH
  bshah

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

AFFECTED FILES
  CMakeLists.txt
  autotests/karchivetest.cpp

To: bshah
Cc: jenkins-ci, kde-frameworks-devel, michaelh, ngraham, bruns

D13819: dummy commit to test pre-review CI

[Bhushan Shah]

bshah updated this revision to Diff 38632.
bshah added a comment.


  - make it fail

REPOSITORY
  R243 KArchive

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13819?vs=38631&id=38632

BRANCH
  bshah

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

AFFECTED FILES
  CMakeLists.txt

To: bshah
Cc: jenkins-ci, kde-frameworks-devel, michaelh, ngraham, bruns

D13819: dummy commit to test pre-review CI

[Bhushan Shah]

bshah updated this revision to Diff 38631.
bshah added a comment.


  - change

REPOSITORY
  R243 KArchive

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13819?vs=38500&id=38631

BRANCH
  bshah

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

AFFECTED FILES
  CMakeLists.txt

To: bshah
Cc: jenkins-ci, kde-frameworks-devel, michaelh, ngraham, bruns

D13819: dummy commit to test pre-review CI

[Bhushan Shah]

bshah updated this revision to Diff 38500.
bshah added a comment.


  - change

REPOSITORY
  R243 KArchive

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13819?vs=37574&id=38500

BRANCH
  bshah

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

AFFECTED FILES
  CMakeLists.txt

To: bshah
Cc: jenkins-ci, kde-frameworks-devel, michaelh, ngraham, bruns

D13819: dummy commit to test pre-review CI

[Bhushan Shah]

bshah updated this revision to Diff 37574.
bshah added a comment.


  - jhdkjfhdskj

REPOSITORY
  R243 KArchive

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13819?vs=37004&id=37574

BRANCH
  bshah

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

AFFECTED FILES
  CMakeLists.txt

To: bshah
Cc: jenkins-ci, kde-frameworks-devel, michaelh, ngraham, bruns

D13559: Fix some of cppcheck warnings

[Bhushan Shah]

This revision was automatically updated to reflect the committed changes.
Closed by commit R127:84bc3cbd6102: Fix some of cppcheck warnings (authored by 
bshah).

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13559?vs=37088&id=37135

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

AFFECTED FILES
  autotests/server/test_display.cpp
  src/client/xdgoutput.cpp
  src/server/dpms_interface.cpp
  src/server/xdgoutput_interface.cpp

To: bshah, #frameworks, aacid
Cc: apol, aacid, kde-frameworks-devel, michaelh, ngraham, bruns

D13559: Fix some of cppcheck warnings

[Bhushan Shah]

bshah added subscribers: aacid, apol.
bshah added a comment.


  Added subscribers back which arc removed.

REPOSITORY
  R127 KWayland

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

To: bshah, #frameworks
Cc: apol, aacid, kde-frameworks-devel, michaelh, ngraham, bruns

D13559: Fix some of cppcheck warnings

[Bhushan Shah]

bshah updated this revision to Diff 37088.
bshah edited the summary of this revision.
bshah removed subscribers: aacid, apol.
bshah added a comment.


  update commit message

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13559?vs=37087&id=37088

BRANCH
  fix-cppcheck

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

AFFECTED FILES
  autotests/server/test_display.cpp
  src/client/xdgoutput.cpp
  src/server/dpms_interface.cpp
  src/server/xdgoutput_interface.cpp

To: bshah, #frameworks
Cc: kde-frameworks-devel, michaelh, ngraham, bruns, aacid, apol

D13559: Fix some of cppcheck warnings

[Bhushan Shah]

bshah updated this revision to Diff 37087.
bshah added a comment.


  - fix memory leak properly

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13559?vs=36199&id=37087

BRANCH
  fix-cppcheck

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

AFFECTED FILES
  autotests/server/test_display.cpp
  src/client/xdgoutput.cpp
  src/server/dpms_interface.cpp
  src/server/xdgoutput_interface.cpp

To: bshah, #frameworks
Cc: aacid, apol, kde-frameworks-devel, michaelh, ngraham, bruns

D13559: Fix some of cppcheck warnings

[Bhushan Shah]

bshah added a comment.


  In D13559#285804 , @apol wrote:
  
  > I don't see any fix here. It's just silencing cppcheck.
  
  
  Only supressing done is the memleak in the autotests, otherwise for 
selfInitialization it is the false alarm, which can be fixed by giving 
different name to argument  variable.

REPOSITORY
  R127 KWayland

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

To: bshah, #frameworks
Cc: apol, kde-frameworks-devel, michaelh, ngraham, bruns

D13819: dummy commit to test pre-review CI

[Bhushan Shah]

bshah updated this revision to Diff 37004.
bshah added a comment.


  - fix tests

REPOSITORY
  R243 KArchive

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13819?vs=36992&id=37004

BRANCH
  bshah

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

AFFECTED FILES
  CMakeLists.txt

To: bshah
Cc: jenkins-ci, kde-frameworks-devel, michaelh, ngraham, bruns

D13559: Fix some of cppcheck warnings

[Bhushan Shah]

bshah added a comment.


  bump?

REPOSITORY
  R127 KWayland

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

To: bshah, #frameworks
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D13819: dummy commit to test pre-review CI

[Bhushan Shah]

bshah updated this revision to Diff 36992.
bshah added a comment.


  - less fun, but this time try failing unit test

REPOSITORY
  R243 KArchive

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13819?vs=36991&id=36992

BRANCH
  bshah

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

AFFECTED FILES
  CMakeLists.txt
  autotests/karchivetest.cpp

To: bshah
Cc: jenkins-ci, kde-frameworks-devel, michaelh, ngraham, bruns

D13819: dummy commit to test pre-review CI

[Bhushan Shah]

bshah updated this revision to Diff 36991.
bshah added a comment.


  - find qt5 fun, because that will make build fail

REPOSITORY
  R243 KArchive

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13819?vs=36989&id=36991

BRANCH
  bshah

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

AFFECTED FILES
  CMakeLists.txt

To: bshah
Cc: jenkins-ci, kde-frameworks-devel, michaelh, ngraham, bruns

D13819: dummy commit to test pre-review CI

[Bhushan Shah]

bshah updated this revision to Diff 36989.
bshah added a comment.


  - final change handover chnage

REPOSITORY
  R243 KArchive

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13819?vs=36988&id=36989

BRANCH
  bshah

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

AFFECTED FILES
  CMakeLists.txt

To: bshah
Cc: jenkins-ci, kde-frameworks-devel, michaelh, ngraham, bruns

D13819: dummy commit to test pre-review CI

[Bhushan Shah]

bshah updated this revision to Diff 36988.
bshah added a comment.


  - enough derps

REPOSITORY
  R243 KArchive

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13819?vs=36987&id=36988

BRANCH
  bshah

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

AFFECTED FILES
  CMakeLists.txt

To: bshah
Cc: jenkins-ci, kde-frameworks-devel, michaelh, ngraham, bruns

D13819: dummy commit to test pre-review CI

[Bhushan Shah]

bshah updated this revision to Diff 36987.
bshah added a comment.


  - derp

REPOSITORY
  R243 KArchive

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13819?vs=36986&id=36987

BRANCH
  bshah

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

AFFECTED FILES
  CMakeLists.txt

To: bshah
Cc: jenkins-ci, kde-frameworks-devel, michaelh, ngraham, bruns

D13819: dummy commit to test pre-review CI

[Bhushan Shah]

bshah updated this revision to Diff 36986.
bshah added a comment.


  - derp

REPOSITORY
  R243 KArchive

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13819?vs=36985&id=36986

BRANCH
  bshah

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

AFFECTED FILES
  CMakeLists.txt

To: bshah
Cc: jenkins-ci, kde-frameworks-devel, michaelh, ngraham, bruns

D13819: dummy commit to test pre-review CI

[Bhushan Shah]

bshah updated this revision to Diff 36985.
bshah added a comment.


  - edit 4, to check change handover works

REPOSITORY
  R243 KArchive

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13819?vs=36982&id=36985

BRANCH
  bshah

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

AFFECTED FILES
  CMakeLists.txt

To: bshah
Cc: jenkins-ci, kde-frameworks-devel, michaelh, ngraham, bruns

D13819: dummy commit to test pre-review CI

[Bhushan Shah]

bshah created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: kde-frameworks-devel.
Harbormaster failed remote builds in B508: Diff 36977!
Harbormaster returned this revision to the author for changes because remote 
builds failed.
bshah updated this revision to Diff 36979.
bshah added a comment.
Harbormaster failed remote builds in B509: Diff 36979!
Harbormaster returned this revision to the author for changes because remote 
builds failed.
bshah updated this revision to Diff 36980.
Harbormaster failed remote builds in B510: Diff 36980!
Harbormaster returned this revision to the author for changes because remote 
builds failed.
bshah updated this revision to Diff 36982.
Harbormaster failed remote builds in B511: Diff 36982!
Harbormaster returned this revision to the author for changes because remote 
builds failed.
bshah requested review of this revision.


  - edit 1 to re-trigger failed CI

bshah added a comment.


  - 2nd time is charm

bshah added a comment.


  - edit 3, let's try this

jenkins-ci added a comment.


  Build is green https://build.kde.org/job/test/10/ for more details.

REVISION SUMMARY
  please ignore this, it is part of work to test the upcoming pre-review CI

REPOSITORY
  R243 KArchive

BRANCH
  bshah

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

AFFECTED FILES
  CMakeLists.txt

To: bshah
Cc: jenkins-ci, kde-frameworks-devel, michaelh, ngraham, bruns

PSA: Phabricator staging repositories

[Bhushan Shah]

Hello developers,

So in last few days I and Ben has been working on setting up the staging
repositories for phabricator. More information on this feature is
documented as part of Harbormaster documentation [1] change handoff
section.

To explain further, this will allow the people to push commits for
review to a dedicated staging area, which opens up the new possibilities
like,

- Landing the changes directly from Web UI
- Handing over the changes to CI systems like build.kde.org or
  build.neon.kde.org or binary-factory.kde.org which in turn can run the
  build against proposed changes and send status back to review saying
  "Hey! That review doesn't build" or "All Green!"

Currently required changes for those two usecases is not implemented
yet. But, enabling staging repository is the first step in that
direction. Currently we have all pieces to enable the staging area in
the repositories ready, but it is not enabled. As we think we should
notify community about upcoming changes. We will be enabling this feature
in upcoming week.

# So how does staging repository works?

When you create a diff using arcanist, what it does is, push the commit
for which changes were created to tag like phabricator/diff/12345, where
12345 represents the diff ID to different git mirror of mainline git
repositories on git.kde.org.

The URL where this tags will be pushed is,

"stag...@git.kde.org:reponame.git"

One imporant thing to note is, stag...@git.kde.org won't accept the
normal pushes, and for most of the developers this URL is implementation
detail. You should not push direct changes to this repositories.

Also, to allow non-developers to push to the staging area, we have
enabled the option to upload ssh keys for the normal users. The keys
added there will be synced to stag...@git.kde.org automatically allowing
the non-developers to push to staging area.

So in general here is what you should do,

# For users who want to submit the changes to phabricator

Please make sure you have your keys uploaded to identity.kde.org, you
can do it by clicking on "Manage SSH Keys" option in right sidebar
after logging in.

# For both users and developers

Make sure your ~/.ssh/config have entry for stag...@git.kde.org.

Below is example from my ssh config.

Host git.kde.org
HostName git.kde.org
User staging
IdentityFile ~/.ssh/id_rsa_kde

# For maintainers of projects

For some reason you don't want your project to use the staging
repositories on phabricator, or have any questions, please get in touch
with us.

PS: We are interested in getting some beta testing for this feature
before we enable this changes to all repositories, if you maintain a
project and if you are interested in testing this out, please mention
us.

PPS: I have just sent this e-mail to few lists I am subscribed to
(kde-devel, kde-core-devel, kde-frameworks-devel, plasma-devel and
sysadmin list) but if you think I have missed sending this to some list,
feel free to forward it and please make sure to include sysad...@kde.org
or me in reply.

Thanks

[1] https://secure.phabricator.com/book/phabricator/article/harbormaster/

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

D13559: Fix some of cppcheck warnings

[Bhushan Shah]

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

REVISION SUMMARY
  - selfInitialization
  - memleak
  
  I could probably suppress the selfInitialization warning, but probably
  is cleaner this way. Opinions welcome

TEST PLAN
  - arc lint --everything
  - Fix issues
  - build
  - run tests

REPOSITORY
  R127 KWayland

BRANCH
  fix-cppcheck

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

AFFECTED FILES
  autotests/server/test_display.cpp
  src/client/xdgoutput.cpp
  src/server/dpms_interface.cpp
  src/server/xdgoutput_interface.cpp

To: bshah, #frameworks
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D13533: Add the arclint file in kwayland

[Bhushan Shah]

This revision was automatically updated to reflect the committed changes.
Closed by commit R127:b046ca8e9d1f: Add the arclint file in kwayland (authored 
by bshah).

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13533?vs=36152&id=36192

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

AFFECTED FILES
  .arclint

To: bshah, #frameworks, mart
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D13533: Add the arclint file in kwayland

[Bhushan Shah]

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

REVISION SUMMARY
  - xml linter to make sure that we don't add broken protocols
  - merge-conflict so that we don't commit merge-conflict markers
  - spell check for documentation
  - cppcheck to check the code

TEST PLAN
  broke some files manually, and then ran arc lint

REPOSITORY
  R127 KWayland

BRANCH
  add-arclint

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

AFFECTED FILES
  .arclint

To: bshah, #frameworks
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D13076: Increase org_kde_plasma_shell interface version

[Bhushan Shah]

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


  Works for me, (and makes sense). Thanks for debugging this @romangg

REPOSITORY
  R127 KWayland

BRANCH
  fixPlasmaShellVersion

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

To: romangg, #plasma, sharvey, bshah
Cc: bshah, kde-frameworks-devel, michaelh, ngraham, bruns

D12919: [Plotter] Don't render if m_node is null

[Bhushan Shah]

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


  Sounds good to me.

REPOSITORY
  R296 KDeclarative

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

To: broulik, #plasma, bshah
Cc: bshah, kde-frameworks-devel, michaelh, ngraham, bruns

D12820: Add KWayland virtual desktop protocol

[Bhushan Shah]

bshah added inline comments.

INLINE COMMENTS

> registry.h:154
>  PlasmaShell, ///< Refers to org_kde_plasma_shell interface
> +PlasmaVirtualDesktopManagement, ///< Refers to 
> org_kde_plasma_virtual_desktop_management interface
>  PlasmaWindowManagement, ///< Refers to 
> org_kde_plasma_window_management interface

This should be added at end and not in middle and also add `@since 5.47(?)`

REPOSITORY
  R127 KWayland

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

To: mart, #kwin, #plasma, graesslin, hein
Cc: bshah, romangg, kde-frameworks-devel, michaelh, ngraham, bruns

D11717: regenerate qrc on every build

[Bhushan Shah]

This revision was automatically updated to reflect the committed changes.
Closed by commit R290:f3619363ed63: regenerate qrc on every build (authored by 
bshah).

REPOSITORY
  R290 KPackage

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11717?vs=30628&id=30631

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

AFFECTED FILES
  KF5PackageMacros.cmake
  qrc.cmake

To: bshah, mart, davidedmundson
Cc: #frameworks, michaelh, ngraham

D11717: regenerate qrc on every build

[Bhushan Shah]

bshah created this revision.
bshah added a reviewer: mart.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.
bshah requested review of this revision.

REVISION SUMMARY
  this will ensure that file deletion and inclusion are taken care of when
  running build

TEST PLAN
  - kdeplasma-addons
  - clean build works
  - Add a file in comic applet
  - run make
  - ensure qrc file contains new file
  - install
  - run applet ensure new file is there
  - remove new qml file
  - install
  - ensure that file is removed from qrc and rcc

REPOSITORY
  R290 KPackage

BRANCH
  regenerateqrc

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

AFFECTED FILES
  KF5PackageMacros.cmake
  qrc.cmake

To: bshah, mart
Cc: #frameworks, michaelh, ngraham

D11709: Don't create dependency loop

[Bhushan Shah]

This revision was automatically updated to reflect the committed changes.
Closed by commit R290:0a26d53a0f86: Don't create dependency loop (authored 
by bshah).

REPOSITORY
  R290 KPackage

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11709?vs=30610&id=30611

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

AFFECTED FILES
  KF5PackageMacros.cmake

To: bshah, romangg, mart
Cc: #frameworks, michaelh, ngraham

D11709: Don't create dependency loop

[Bhushan Shah]

bshah created this revision.
bshah added a reviewer: romangg.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.
bshah requested review of this revision.

REVISION SUMMARY
  The code tried to depend on the generated .rcc file which was generated
  by target itself.

TEST PLAN
  tested that plasma-pa now builds with clean dir

REPOSITORY
  R290 KPackage

BRANCH
  fix-kpackag

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

AFFECTED FILES
  KF5PackageMacros.cmake

To: bshah, romangg
Cc: #frameworks, michaelh, ngraham

D11642: Fix the rcc binary package generation

[Bhushan Shah]

bshah marked 2 inline comments as done.
bshah added a comment.


  opened PR for KDE_INSTALL_DATADIR : https://phabricator.kde.org/D11675

REPOSITORY
  R290 KPackage

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

To: bshah, mart, davidedmundson, apol
Cc: kossebau, #frameworks, michaelh, ngraham

D11675: use KDE_INSTALL_DATADIR instead of FULL_DATADIR

[Bhushan Shah]

bshah created this revision.
bshah added a reviewer: kossebau.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.
bshah requested review of this revision.

REVISION SUMMARY
  This is inline with other install statements

REPOSITORY
  R290 KPackage

BRANCH
  usedatadir

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

AFFECTED FILES
  KF5PackageMacros.cmake

To: bshah, kossebau
Cc: #frameworks, michaelh, ngraham

D11642: Fix the rcc binary package generation

[Bhushan Shah]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R290:b69866996e7e: Fix the rcc binary package generation 
(authored by bshah).

REPOSITORY
  R290 KPackage

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11642?vs=30412&id=30486

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

AFFECTED FILES
  KF5PackageMacros.cmake
  qrc.cmake

To: bshah, mart, davidedmundson, apol
Cc: kossebau, #frameworks, michaelh, ngraham

D11642: Fix the rcc binary package generation

[Bhushan Shah]

bshah added inline comments.

INLINE COMMENTS

> kossebau wrote in KF5PackageMacros.cmake:164
> Does a plain `${KDE_INSTALL_DATADIR}` not also work? The non-FULL variable 
> variants are the ones used usually with `install()`. Not exactly sure why 
> they are, but doing here as well would be consistent at least and less 
> surprising.

I'll create seperate PR for that.

REPOSITORY
  R290 KPackage

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

To: bshah, mart, davidedmundson, apol
Cc: kossebau, #frameworks, michaelh, ngraham

D11642: Fix the rcc binary package generation

[Bhushan Shah]

bshah marked 2 inline comments as done.

REPOSITORY
  R290 KPackage

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

To: bshah, mart, davidedmundson, apol
Cc: kossebau, #frameworks, michaelh, ngraham

D11642: Fix the rcc binary package generation

[Bhushan Shah]

bshah updated this revision to Diff 30412.
bshah added a comment.


  - regnerate rcc file on every build
  - add comment in add_custom_target for logging in build log
  - Fix the path in the qrc file which broke in previous attempt, 
plasma/plasmoids// v/s plasma/plasmoids//

REPOSITORY
  R290 KPackage

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11642?vs=30385&id=30412

BRANCH
  fix-bundled-packages

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

AFFECTED FILES
  KF5PackageMacros.cmake
  qrc.cmake

To: bshah, mart, davidedmundson, apol
Cc: kossebau, #frameworks, michaelh, ngraham

D11642: Fix the rcc binary package generation

[Bhushan Shah]

bshah added a comment.


  In D11642#232866 , @apol wrote:
  
  > See older reviews. This won't work because cmake doesn't know when one of 
the contained files is modified so rcc files are never regenerated properly.
  
  
  I've solution for that in mind.. will fix.

REPOSITORY
  R290 KPackage

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

To: bshah, mart, davidedmundson, apol
Cc: kossebau, #frameworks, michaelh, ngraham

D11642: Fix the rcc binary package generation

[Bhushan Shah]

bshah added reviewers: mart, davidedmundson, apol.

REPOSITORY
  R290 KPackage

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

To: bshah, mart, davidedmundson, apol
Cc: #frameworks, michaelh, ngraham

D11642: Fix the rcc binary package generation

[Bhushan Shah]

bshah updated this revision to Diff 30385.
bshah edited the test plan for this revision.
bshah added a comment.


  update commit message

REPOSITORY
  R290 KPackage

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11642?vs=30384&id=30385

BRANCH
  fix-bundled-packages

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

AFFECTED FILES
  KF5PackageMacros.cmake

To: bshah
Cc: #frameworks, michaelh, ngraham

D11642: Fix the rcc binary package generation

[Bhushan Shah]

bshah created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.
bshah requested review of this revision.

REVISION SUMMARY
  kpackage_install_bundled_package used install(CODE ..) for the
  generation and installation of the rcc file. This had multiple flows,
  
  - It didn't respect the DESTDIR variable of install target which made
  
  most of distribution packaging fail as it tried to write to installation
  prefix directly.
  
  - It used the execute_process which resulted in the rcc file generation
  
  at time of install instead of the build-time, so it would fail with
  permission errors if make install is run as normal user

TEST PLAN
  - tested with kdeplasma-addons that it installs all the applets
  - it installs the content.rrc in $prefix/share/plasma/plasmoids/$id/

REPOSITORY
  R290 KPackage

BRANCH
  fix-bundled-packages

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

AFFECTED FILES
  KF5PackageMacros.cmake

To: bshah
Cc: #frameworks, michaelh, ngraham

D11331: add gaming_input devices and others to Battery

[Bhushan Shah]

bshah added reviewers: broulik, Plasma.

REPOSITORY
  R245 Solid

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

To: dollinger, broulik, #plasma
Cc: #frameworks, michaelh, ngraham

D10072: Add APKBUILD to be highlighted as a Bash file

[Bhushan Shah]

bshah added a comment.


  In D10072#204816 , @ltoscano wrote:
  
  > I suggest to push a revert and push it again with the right metadata.
  
  
  done.

REPOSITORY
  R216 Syntax Highlighting

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

To: PureTryOut, vkrause
Cc: ltoscano, dhaumann, bshah, vkrause, bcooksley, #frameworks, michaelh

D10072: Add APKBUILD to be highlighted as a Bash file

[Bhushan Shah]

bshah added a comment.


  Uhm sorry, arc screwed up author metadata :-(
  
  but submitted patch anyway.

REPOSITORY
  R216 Syntax Highlighting

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

To: PureTryOut, vkrause
Cc: dhaumann, bshah, vkrause, bcooksley, #frameworks, michaelh

D10072: Add APKBUILD to be highlighted as a Bash file

[Bhushan Shah]

This revision was automatically updated to reflect the committed changes.
Closed by commit R216:7bafdc592040: Add APKBUILD to be highlighted as a Bash 
file (authored by bshah).

REPOSITORY
  R216 Syntax Highlighting

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10072?vs=25985&id=26985

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

AFFECTED FILES
  data/syntax/bash.xml

To: PureTryOut, vkrause
Cc: dhaumann, bshah, vkrause, bcooksley, #frameworks, michaelh

D10450: Generate a custom target in kcoreaddons_desktop_to_json

[Bhushan Shah]

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


  +1

REPOSITORY
  R244 KCoreAddons

BRANCH
  master

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

To: tcberner, #freebsd, mpyne, bshah, dfaure
Cc: adridg, kossebau, #frameworks, michaelh

D9589: Unexport kjscmd

[Bhushan Shah]

bshah added inline comments.

INLINE COMMENTS

> vkrause wrote in CMakeLists.txt:6
> That suggests it shouldn't even be installed in the first place? Would fix 
> the cross-compilation issue too.

I am not sure tbh, question is what it does and what does it mean by developer 
tool?

- KJSEmbed framework developer?
- 3rd-party developer?

If it's 3rd party, it should be installed IMO, but well who knows.. I am not 
even sure I understand what this tool does..

REPOSITORY
  R315 KJsEmbed

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

To: vkrause, #frameworks
Cc: bshah, michaelh

D9587: Make kdoctools dependency optional

[Bhushan Shah]

bshah accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R314 KJs

BRANCH
  master

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

To: vkrause, #frameworks, bshah
Cc: michaelh

D9588: Make kdoctools dependency optional

[Bhushan Shah]

bshah accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R315 KJsEmbed

BRANCH
  master

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

To: vkrause, #frameworks, bshah
Cc: michaelh

D9594: Make kdoctools dependency optional

[Bhushan Shah]

bshah accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R298 KDesignerPlugin

BRANCH
  master

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

To: vkrause, #frameworks, bshah
Cc: michaelh

D9589: Unexport kjscmd

[Bhushan Shah]

bshah added inline comments.

INLINE COMMENTS

> CMakeLists.txt:6
>  
>  # This is a developer tool, not intended for normal user installs
>  add_executable(kjscmd5 ${kjscmd_SRCS})

:-P

REPOSITORY
  R315 KJsEmbed

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

To: vkrause, #frameworks
Cc: bshah, michaelh

D10072: Add APKBUILD to be highlighted as a Bash file

[Bhushan Shah]

bshah added subscribers: vkrause, bshah.
bshah added a reviewer: vkrause.
bshah added a comment.


  Adding @vkrause as reviewer who is listed as maintainer in metainfo.yaml

REPOSITORY
  R216 Syntax Highlighting

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

To: PureTryOut, vkrause
Cc: bshah, vkrause, bcooksley, #frameworks

D10074: parametrize qqc2 version

[Bhushan Shah]

bshah accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  phab/qqcversion

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

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

D9894: [UDisks Device] Show loop device with their backing file name and icon

[Bhushan Shah]

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


  , showed up with file name a

REPOSITORY
  R245 Solid

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

To: broulik, #vdg, davidedmundson, bshah
Cc: bshah, apol, #frameworks

D9895: [UDisks] Ignore non-user mounts

[Bhushan Shah]

bshah accepted this revision as: bshah.
This revision is now accepted and ready to land.

REPOSITORY
  R245 Solid

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

To: broulik, #plasma, #vdg, #frameworks, bshah
Cc: mart, ngraham, sitter, plasma-devel, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol

D10020: add a workaround to mark snap bundle mounts as hidden

[Bhushan Shah]

bshah added subscribers: broulik, bshah.
bshah added a comment.


  umm, @broulik had a patch for this somewhere...
  
  https://phabricator.kde.org/D9895

REPOSITORY
  R245 Solid

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

To: sitter, apol
Cc: bshah, broulik, #frameworks

D8806: Do not leak rfkill file descriptors.

[Bhushan Shah]

bshah added a comment.


  In https://phabricator.kde.org/D8806#167510, @drosca wrote:
  
  > Why? It's not like any other process can't open /dev/rfkill as we ship udev 
rule to enable r+w access to /dev/rfkill for all users.
  
  
  My comment was question :-)
  
  But well I didn't know about udev rule.. in that case it's fine

REPOSITORY
  R269 BluezQt

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

To: ofreyermuth, davidedmundson
Cc: drosca, bshah, broulik, #frameworks

D8806: Do not leak rfkill file descriptors.

[Bhushan Shah]

bshah added a comment.


  I do wonder if this is security fix? And should probably be handled like that?

REPOSITORY
  R269 BluezQt

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

To: ofreyermuth, davidedmundson
Cc: drosca, bshah, broulik, #frameworks

D8806: Do not leak rfkill file descriptors.

[Bhushan Shah]

bshah added a comment.


  Do you have commit access?

REPOSITORY
  R269 BluezQt

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

To: ofreyermuth, davidedmundson
Cc: bshah, broulik, #frameworks

D8111: Require Kirigami 2.1 instead of 1.0 for KNewStuffQuick

[Bhushan Shah]

bshah added a comment.


  +1, looks good to me.

REPOSITORY
  R304 KNewStuff

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

To: leinir, #knewstuff
Cc: bshah, #frameworks, ZrenBot

D8105: Find test helper

[Bhushan Shah]

bshah accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R278 KWindowSystem

BRANCH
  master

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

To: davidedmundson, bshah
Cc: #frameworks

D8107: Find test helper

[Bhushan Shah]

bshah accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R278 KWindowSystem

BRANCH
  master

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

To: davidedmundson, bshah
Cc: #frameworks

D7533: KIO: port the URI filter plugins from KServiceTypeTrader to json+KPluginMetaData

[Bhushan Shah]

bshah added a comment.


  In https://phabricator.kde.org/D7533#140680, @dfaure wrote:
  
  > Ah, phabricator is strange, I have indeed modified the commit log before 
doing `arc diff` but it didn't update it here.
  
  
  And it also did overwrite your change in actual commit message it seems 
*shrug*

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

To: dfaure, apol, davidedmundson, arichardson, bshah
Cc: vandenoever, elvisangelaccio, bshah, #frameworks

D7533: KIO: port the URI filter plugins from KServiceTypeTrader to json+KPluginMetaData

[Bhushan Shah]

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


  Looks good to me.
  
  (Maybe modify the commit message to remove the priority int/string bits)

BRANCH
  master

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

To: dfaure, apol, davidedmundson, arichardson, bshah
Cc: vandenoever, elvisangelaccio, bshah, #frameworks

D7533: KIO: port the URI filter plugins from KServiceTypeTrader to json+KPluginMetaData

[Bhushan Shah]

bshah added a comment.


  > One thing I don't understand is the need for toString().toInt(),
  >  or in other words, why my json file with a numeric value gets turned
  >  into a string value when using qtplugininfo to inspect the plugin:
  
  Maybe you need to add following in the `src/widgets/kurifilterplugin.desktop`
  
[PropertyDef::X-KDE-InitialPreference]
Type=int

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

To: dfaure, apol, davidedmundson, arichardson
Cc: bshah, #frameworks