Re: Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

On Tue, Jan 31, 2017 at 11:36 PM, René J.V. Bertin  wrote:
> On Sunday January 29 2017 08:32:21 Ben Cooksley wrote:
>
> Hi,

Hi Rene,

>
> >From this point forward, communities should be moving away from
>>Reviewboard to Phabricator for conducting code review. Sysadmin will
>>be announcing a timeline for the shutdown of Reviewboard in the near
>>future.
>
> I hope that shutdown doesn't mean complete disconnect; it would probably be a 
> loss of as-yet unknown importance if all code reviews become unavailable.
>
> I'll miss ReviewBoard. Phabrithingy may be more powerful and versatile, but 
> RB had its advantages too which could be why it's still being used (quite a 
> lot, as far as I can see) and hasn't been integrated with KDE's own IDE yet.

It will be a complete shutdown of Reviewboard - we'll be archiving it
in the event for some reason it becomes necessary to access the data
it stores.

In most cases mailing lists should have the history of reviews in
their archives, so those will continue to be accessible through list
archives in the long run.


>
> R.

Cheers,
Ben

Phabricator Project Organisation - Plasma

[Ben Cooksley]

Hi Plasma Folks,

The current structure of the Plasma project on Phabricator causes a
few issues with how we currently prefer to setup Herald rules. It also
means that people interested in subcommunities within Plasma aren't
able to selectively subscribe to those notifications.

This is because the majority of repositories are currently tagged with
the parent Plasma project - and parent projects inherit the membership
of their children. This means anyone subscribing to subprojects will
be notified of everything that happens in the Parent project.

This is why the KWin mailing list received all the Plasma reviews not
too long ago.

I also note that Plasma (as a collective effort, from my point of view
anyway) is related to or includes code which is currently located in
Extragear or Playground.

The easiest one from my perspective is to classify the Plasma:
Workspaces project as the "Release" project for Plasma (to match the
ones KDE Applications and Frameworks have) and retag all the
repositories which make up the release appropriately. A second
subproject would hold the tags for the other related repositories
which aren't part of the release.

Any comments, other suggestions?

Thanks,
Ben Cooksley
KDE Sysadmin

Phabricator: All repositories registered - upcoming workflow changes

[Ben Cooksley]

Hi everyone,

We've just completed the registration of all mainline repositories
(not including Websites or Sysadmin namespaced ones) on Phabricator.
Thanks go to Luigi Toscano for providing significant assistance with
this process.

>From this point forward, communities should be moving away from
Reviewboard to Phabricator for conducting code review. Sysadmin will
be announcing a timeline for the shutdown of Reviewboard in the near
future.

Projects which haven't yet looked into Phabricator, including getting
things like mailing list notifications and projects setup should do so
as soon as practical.

As part of the registration process, Sysadmin tagged repositories,
associating them to Projects. These tags show what a repository is
associated with and it's status.

This includes things like whether development is currently active (the
Historical Archival and Up For Adoption tags), which release unit it
is part of (KDE Applications, Frameworks, etc) and the general
development effort it is associated with.

It would be appreciated if everyone could please check their
repositories to ensure they've been tagged correctly. Adjustments can
either be sent as replies to this email (include sysadmin@ in CC
please) or by asking a member of the Community Admins project on
Phabricator to make the change for you.

Thanks,
Ben Cooksley
KDE Sysadmin

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Fri, Jan 6, 2017 at 9:52 PM, Martin Gräßlin  wrote:
> Am 2017-01-06 05:57, schrieb Ben Cooksley:
>>
>> On Fri, Jan 6, 2017 at 12:38 AM, Martin Gräßlin 
>> wrote:
>>>
>>> Am 2017-01-05 11:20, schrieb Ben Cooksley:
>>>>
>>>>
>>>> On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin
>>>>  wrote:
>>>>>
>>>>>
>>>>> Am 2017-01-05 09:44, schrieb Ben Cooksley:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> It seems that my previous vocal complaints about system level /
>>>>>> serious impact dependency bumps on the CI system have gone completely
>>>>>> unnoticed by (some) members of our Community.
>>>>>>
>>>>>> This was demonstrated earlier this week when components of Plasma
>>>>>> bumped their version requirements for XKBCommon and Appstream-Qt -
>>>>>> without even a thought about notifying Sysadmin or checking which
>>>>>> version the CI had, until their builds broke.
>>>>>>
>>>>>> Neither of these is easy to fix at this stage, as the system base is
>>>>>> now too old to receive updates such as these. Base upgrades require a
>>>>>> full rebuild of everything on the CI system, and usually involve
>>>>>> significant additional churn and is a process that must be done
>>>>>> roughly twice a year, depending on dependency bump demands.
>>>>>>
>>>>>> Does anyone have any suggestions as to how we may avoid this in the
>>>>>> future?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I have a few questions here:
>>>>>
>>>>> 1) Where is this requirement to check with sysadmins codified? So far I
>>>>> was
>>>>> only aware of dependency freeze.
>>>>
>>>>
>>>>
>>>> It's been codified since the PIM Qt 5.6 / WebEngine debacle, where
>>>> Sysadmin had to rush delivery of Qt 5.6 to the CI system because the
>>>> whole of PIM broke when they started using QtWebEngine. That was
>>>> around March/April 2016, my mail archives can't seem to find the exact
>>>> thread though.
>>>
>>>
>>>
>>> I'm sorry Ben, but I fear "sending out a mail about an issue with PIM"
>>> doesn't
>>> qualify as codifying it. Given what we have it looks like this did not
>>> reach
>>> the
>>> target audience. And neither will this thread.
>>
>>
>> Uhm, it was far more than a single email. It was quite the thread, and
>> if memory serves was on at least one of the mailing lists this thread
>> was on.
>> One of the key things that came out of that thread was to ask for
>> things to be bumped well in advance if a newer version is needed.
>>
>> I'm disappointed that you think that email threads have insufficient
>> reach given it's one of our communities principal means of
>> communication.
>
>
> Email threads don't work to codify such requirements. What we need is
> something like an "announce new dependency to sysadmin freeze" prior to
> the dependency freeze in the release schedule. That's what I mean with
> codifying it. We need to have it in a way where devs actually check.
> It needs to be part of the process. An old email thread cannot be part of
> the process.

Announcing new dependencies to Sysadmin as part of a release schedule
doesn't really work... because dependencies can be bumped at any time
(as long as a dependency freeze is not in effect for a project). Also,
CI builds for far more than just Plasma, including for software that
doesn't have a formal release schedule, including software in
Extragear. CI also doesn't really care for release schedules at all,
it just builds the latest state of the repository.

If you want to specify a time it has to be X before the commits
introducing the dependency land.

>
>>
>>>
>>> This needs to change the process, the way KDE develops software. It needs
>>> to
>>> be
>>> listed in the release schedule (is not, I checked), maybe reviews need to
>>> be
>>> acked by release managers, etc.
>>
>>
>> It seems to be part of the process for many others already, so not
>> sure what needs to change. The gpgme transition went quite well for
>> PIM,

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Fri, Jan 6, 2017 at 12:38 AM, Martin Gräßlin  wrote:
> Am 2017-01-05 11:20, schrieb Ben Cooksley:
>>
>> On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin
>>  wrote:
>>>
>>> Am 2017-01-05 09:44, schrieb Ben Cooksley:
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> It seems that my previous vocal complaints about system level /
>>>> serious impact dependency bumps on the CI system have gone completely
>>>> unnoticed by (some) members of our Community.
>>>>
>>>> This was demonstrated earlier this week when components of Plasma
>>>> bumped their version requirements for XKBCommon and Appstream-Qt -
>>>> without even a thought about notifying Sysadmin or checking which
>>>> version the CI had, until their builds broke.
>>>>
>>>> Neither of these is easy to fix at this stage, as the system base is
>>>> now too old to receive updates such as these. Base upgrades require a
>>>> full rebuild of everything on the CI system, and usually involve
>>>> significant additional churn and is a process that must be done
>>>> roughly twice a year, depending on dependency bump demands.
>>>>
>>>> Does anyone have any suggestions as to how we may avoid this in the
>>>> future?
>>>
>>>
>>>
>>> I have a few questions here:
>>>
>>> 1) Where is this requirement to check with sysadmins codified? So far I
>>> was
>>> only aware of dependency freeze.
>>
>>
>> It's been codified since the PIM Qt 5.6 / WebEngine debacle, where
>> Sysadmin had to rush delivery of Qt 5.6 to the CI system because the
>> whole of PIM broke when they started using QtWebEngine. That was
>> around March/April 2016, my mail archives can't seem to find the exact
>> thread though.
>
>
> I'm sorry Ben, but I fear "sending out a mail about an issue with PIM"
> doesn't
> qualify as codifying it. Given what we have it looks like this did not reach
> the
> target audience. And neither will this thread.

Uhm, it was far more than a single email. It was quite the thread, and
if memory serves was on at least one of the mailing lists this thread
was on.
One of the key things that came out of that thread was to ask for
things to be bumped well in advance if a newer version is needed.

I'm disappointed that you think that email threads have insufficient
reach given it's one of our communities principal means of
communication.

>
> This needs to change the process, the way KDE develops software. It needs to
> be
> listed in the release schedule (is not, I checked), maybe reviews need to be
> acked by release managers, etc.

It seems to be part of the process for many others already, so not
sure what needs to change. The gpgme transition went quite well for
PIM, and other applications developers have reached out and asked
about version upgrades to various libraries which were in their area
of interest which we have sorted out easily enough.

>
>>
>>> 2) How can we easily check what build.kde.org has? Looking at cmake
>>> output
>>> is not a sufficient way as it gives me wrong information
>>
>>
>> If CMake is outputting wrong information, then your CMakeLists.txt
>> can't make the appropriate decisions as to whether the available
>> version is suitable, so i'd say you've got bigger problems here that
>> need to be addressed first.
>
>
> Cmake feature summary says: "required version >= 0.5" and that's for all
> found
> depeendencies. Unfortunately no information at all in the feature summary
> about
> the actual version.

Quoting the KWin CMake log...

15:08:41 -- Found Wayland_Client:
/usr/lib/x86_64-linux-gnu/libwayland-client.so (found version
"1.12.90")
15:08:41 -- Found Wayland_Cursor:
/usr/lib/x86_64-linux-gnu/libwayland-cursor.so (found version
"1.12.90")
15:08:42 -- Found Wayland_Egl:
/usr/lib/x86_64-linux-gnu/libwayland-egl.so (found version "11.0.2")
15:08:42 -- Found Wayland:
/usr/lib/x86_64-linux-gnu/libwayland-client.so;/usr/lib/x86_64-linux-gnu/libwayland-cursor.so;/usr/lib/x86_64-linux-gnu/libwayland-egl.so
(found suitable version "1.12.90", minimum required is "1.2") found
components:  Cursor Egl
15:08:42 -- Could NOT find XKB: Found unsuitable version "0.5.0", but
required is at least "0.7.0" (found
/usr/lib/x86_64-linux-gnu/libxkbcommon.so)
15:08:42 -- Found Libinput: /usr/lib/x86_64-linux-gnu/libinput.so
(found suitable version "1.5.2", minimum required is "1.5")
15:08:42 -- Found UDev: /

Re: CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin
 wrote:
> Am 2017-01-05 09:44, schrieb Ben Cooksley:
>>
>> Hi all,
>>
>> It seems that my previous vocal complaints about system level /
>> serious impact dependency bumps on the CI system have gone completely
>> unnoticed by (some) members of our Community.
>>
>> This was demonstrated earlier this week when components of Plasma
>> bumped their version requirements for XKBCommon and Appstream-Qt -
>> without even a thought about notifying Sysadmin or checking which
>> version the CI had, until their builds broke.
>>
>> Neither of these is easy to fix at this stage, as the system base is
>> now too old to receive updates such as these. Base upgrades require a
>> full rebuild of everything on the CI system, and usually involve
>> significant additional churn and is a process that must be done
>> roughly twice a year, depending on dependency bump demands.
>>
>> Does anyone have any suggestions as to how we may avoid this in the
>> future?
>
>
> I have a few questions here:
>
> 1) Where is this requirement to check with sysadmins codified? So far I was
> only aware of dependency freeze.

It's been codified since the PIM Qt 5.6 / WebEngine debacle, where
Sysadmin had to rush delivery of Qt 5.6 to the CI system because the
whole of PIM broke when they started using QtWebEngine. That was
around March/April 2016, my mail archives can't seem to find the exact
thread though.

> 2) How can we easily check what build.kde.org has? Looking at cmake output
> is not a sufficient way as it gives me wrong information

If CMake is outputting wrong information, then your CMakeLists.txt
can't make the appropriate decisions as to whether the available
version is suitable, so i'd say you've got bigger problems here that
need to be addressed first.

In any case, you can see the Docker log of the container being
generated at https://build.kde.org/job/create_ubuntu_slave-ange/

> 3) What should we do when build.kde.org does not have the requirement?

You have to file a Sysadmin ticket, also tagging the project
'build.kde.org' at the same time.

>
> It should be rather obvious that we don't introduce new dependencies because
> we like to. There is a very important software reason to it.
> That's the case for the xkbcommon dependency increase. Should I have let the
> code broken as it was, expecting half a year of bug reports till
> build.kde.org has the base upgraded to Ubuntu 16.04?

That's what #ifdef is for...

>
> If I have to degrade the quality of the product for serving the CI, I and
> all users have a problem. And this is currently the only alternative. The
> quality of our product is highly at risk as our changes are no longer
> compile tested. This is a huge problem for the release of Plasma 5.9. On the
> other hand I cannot revert the dependency change as that would break tests
> or introduce the broken code again. So actually we are caught between a hard
> and a rock place.
>
> When I increased the dependency I had the dependency freeze of Plasma 5.9 in
> mind. That's the one target I have to hit from release process currently.
> Also I had to consider a social aspect here. I asked xkbcommon devs to do
> the release. I would have feeled ashamed if we asked for the release and
> then don't use it. For me it was from a social point of view a very high
> requirement to ship with the dependency in the next release after xkbcommon
> release.
>
> If we have to wait an arbitrary time till build.kde.org has upgraded the
> base, maybe the choice of the base is not sufficient. E.g. I asked openSUSE
> about this dependency weeks ago. Actually a few days after xkbcommon had the
> release and it was already shipped in tumbleweed. Similar for Mesa 13 which
> I'm also eagerly waiting for build.kde.org to fetch it.

Mesa 13 is news to me.

Base upgrades are a major, major piece of effort. Ignoring changes to
packaging made by the distros, everything on the CI has to be fully
rebuilt due to broken binary compatibility (GLIBC usually changes)

Even if it were kept, as soon as you get new builds using new features
while old build artifacts are still using old ones, it'll start to
break (Cue wave to Qt's plugin loader & Akonadi with even patch level
version bumps to Qt). This problem is exacerbated by us often ending
up using PPA's and other third party repositories to provide certain
version bumped dependencies - which of course are packaged
differently, leading to not only potential naming differences but also
different sets of compiler flags (ABI compatibility says hi again).

In terms of the rebuild - that's everything from Qt, up through
Frameworks, then all of the 

CI Requirements - Lessons Not Learnt?

[Ben Cooksley]

Hi all,

It seems that my previous vocal complaints about system level /
serious impact dependency bumps on the CI system have gone completely
unnoticed by (some) members of our Community.

This was demonstrated earlier this week when components of Plasma
bumped their version requirements for XKBCommon and Appstream-Qt -
without even a thought about notifying Sysadmin or checking which
version the CI had, until their builds broke.

Neither of these is easy to fix at this stage, as the system base is
now too old to receive updates such as these. Base upgrades require a
full rebuild of everything on the CI system, and usually involve
significant additional churn and is a process that must be done
roughly twice a year, depending on dependency bump demands.

Does anyone have any suggestions as to how we may avoid this in the future?

At this point i'm in favour of if you don't follow the rules your
dependency bump just gets reverted out of existence, then you get to
go through the process properly...

Regards,
Ben

[Differential] [Updated] D3479: [libinput] Add more support for touchpads in preparation for the new touchpad KCM

[bcooksley (Ben Cooksley)]

bcooksley edited projects, added KWin; removed Plasma.

REPOSITORY
  R108 KWin

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: subdiff, #kwin, davidedmundson, #plasma
Cc: graesslin, davidedmundson, plasma-devel, kwin, #kwin, lesliezhai, 
ali-mohamed, hardening, jensreuterberg, abetts, sebas

[Differential] [Updated] D3479: [libinput] Add more support for touchpads in preparation for the new touchpad KCM

[bcooksley (Ben Cooksley)]

bcooksley edited projects, added Plasma; removed KWin.

REPOSITORY
  R108 KWin

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: subdiff, #kwin, davidedmundson, #plasma
Cc: graesslin, davidedmundson, plasma-devel, kwin, #kwin, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas

Re: Please cleanup your scratch and clone repositories

[Ben Cooksley]

On Sat, Nov 26, 2016 at 7:53 AM, Ben Cooksley  wrote:
> Hi all,

Hi all,

>
> To help Sysadmin assess how these types of repositories would be used
> under Phabricator, it would be appreciated if everyone could please
> cleanup the scratch and clone repositories they're no longer using and
> have no need to keep.
>
> You can get a list of repositories you have by visiting
> https://cgit.kde.org/ or by running the below command and filtering
> appropriately using your favourite tools.
>
> ssh g...@git.kde.org info
>
> Once you've determined the repositories to remove, they can be removed
> by running the following two commands:
>
> ssh g...@git.kde.org D unlock scratch/username/reponame
> ssh g...@git.kde.org D rm scratch/username/reponame
>
> Please note that the trailing .git should not be included, otherwise
> the system will not accept your request. You can substitute
> scratch/... for clones/... as appropriate here.
>
> Thanks in advance for removing unused repos!

We've had good progress so far in cleaning up unused repositories -
i'd estimate good 50 or so repositories have been cleaned up.
For those who haven't yet checked their personal clones and scratch
repositories it would be appreciated if you could do so.

>
> Regards,
> Ben Cooksley
> KDE Sysadmin

Thanks,
Ben Cooksley

[Differential] [Updated] D3112: Pass transient parent window to KToolTipWindow

[bcooksley (Ben Cooksley)]

bcooksley added a comment.


  This looks fine to me. The whole KToolTip class thing should at some point be 
replaced or merged with the code which Dolphin and KInfoCenter use - which is 
basically the same last I recall.

REPOSITORY
  rSYSTEMSETTINGS System Settings

BRANCH
  wayland-fix-tooltips

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #plasma, davidedmundson, bcooksley
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

Re: Review Request 128707: Add support for captive portals

[Ben Cooksley]

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



>From my perspective using www.kde.org for the browser part of the process is 
>fine. Using it to detect whether or not you are behind a captive portal (which 
>afaik is handled by NetworkManager and the URL for doing that is set by 
>distributions).

Please note that the index of www.kde.org is not static - it is dynamic 
content, generated via PHP.

- Ben Cooksley


On Sept. 6, 2016, 7:37 a.m., Jan Grulich wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128707/
> ---
> 
> (Updated Sept. 6, 2016, 7:37 a.m.)
> 
> 
> Review request for Network Management, Plasma, KDE Usability, and Lamarque 
> Souza.
> 
> 
> Bugs: 365417
> http://bugs.kde.org/show_bug.cgi?id=365417
> 
> 
> Repository: plasma-nm
> 
> 
> Description
> ---
> 
> Adds portal monitor to our kded module, which checks NetworkManager 
> connectivity. If the value gets changed to NM_CONNECTIVITY_PORTAL (means we 
> are behind a captive portal), then we open a QWebEngineView trying to load 
> "http://kde.org"; page which is supposed to be redirected to the captive 
> portal page. Once user logs in and url changes, we re-check the connectivity 
> again and close the web view if we are no longer behind the captive portal.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt a27c1f2 
>   kded/CMakeLists.txt 1f0613e 
>   kded/portalmonitor.h PRE-CREATION 
>   kded/portalmonitor.cpp PRE-CREATION 
>   kded/service.cpp 18ffd41 
> 
> Diff: https://git.reviewboard.kde.org/r/128707/diff/
> 
> 
> Testing
> ---
> 
> Tested with three different captive portals and it worked perfectly.
> 
> 
> Thanks,
> 
> Jan Grulich
> 
>

[sysadmin/ci-master-config] docker/ubuntu-wily-slave: Include libcanberra-dev in the CI system image for KF5 based builds, as needed by Plasma PA.

[Ben Cooksley]

Git commit 02fdad704cca5fa4a141c7b9a18cfa89c4e4cf9c by Ben Cooksley.
Committed on 29/07/2016 at 20:21.
Pushed by bcooksley into branch 'master'.

Include libcanberra-dev in the CI system image for KF5 based builds, as needed 
by Plasma PA.
This should fix it's CI build.
@PlasmaDevs: Please ask for packages to be made available before beginning to 
depend on them, to help the CI system function smoothly.
CCMAIL: plasma-devel@kde.org

M  +2-1docker/ubuntu-wily-slave/Dockerfile

http://commits.kde.org/sysadmin/ci-master-config/02fdad704cca5fa4a141c7b9a18cfa89c4e4cf9c

diff --git a/docker/ubuntu-wily-slave/Dockerfile 
b/docker/ubuntu-wily-slave/Dockerfile
index 9a4ab73..f8dc248 100644
--- a/docker/ubuntu-wily-slave/Dockerfile
+++ b/docker/ubuntu-wily-slave/Dockerfile
@@ -253,7 +253,8 @@ RUN DEBIAN_FRONTEND=noninteractive apt-get -y --force-yes 
install \
 libgconf2-dev \
 libpodofo-dev \
 libclang-3.7-dev \
-llvm-3.7
+llvm-3.7 \
+libcanberra-dev
 
 RUN gem install cucumber
 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[sysadmin/ci-master-config] /: Change the versions of Qt 5 used on the CI system.

[Ben Cooksley]

Git commit 0b3511e4c66cce6206b04294c504cfbf93ae7056 by Ben Cooksley.
Committed on 20/07/2016 at 07:58.
Pushed by bcooksley into branch 'master'.

Change the versions of Qt 5 used on the CI system.
As Qt's compatibility between versions usually breaks on the CI, expect many 
things to break until everything has been rebuilt.
CCMAIL: kde-frameworks-de...@kde.org
CCMAIL: release-t...@kde.org
CCMAIL: kde-...@kde.org
CCMAIL: plasma-devel@kde.org
CCMAIL: kde-de...@kde.org

M  +2-2identifiers.json

http://commits.kde.org/sysadmin/ci-master-config/0b3511e4c66cce6206b04294c504cfbf93ae7056

diff --git a/identifiers.json b/identifiers.json
index 0067758..cf9becb 100644
--- a/identifiers.json
+++ b/identifiers.json
@@ -3903,8 +3903,8 @@
 "git": "git://code.qt.io/qt/qt5.git",
 "branchgroups":
 {
-"stable-kf5-qt5": "5.5",
-"kf5-qt5": "5.6"
+"stable-kf5-qt5": "5.6",
+"kf5-qt5": "5.7"
 },
 
"cron": "@weekly",
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Usage of QNetworkAccessManager

[Ben Cooksley]

Hi all,

Just my regular reminder regarding usage of QNetworkAccessManager in
your applications and libraries, especially when it comes to
interacting with kde.org infrastructure.

Unfortunately, from it's first iteration in Qt 4 QNetworkAccessManager
was shipped with a severe and fundamental defect in that it does not
follow HTTP redirects by default. Due to Qt behavioural and other
compatibility promises they can never change this behaviour, not even
in Qt 6.

Please therefore ensure your application handles redirects
appropriately (the form of the code will depend on the version of Qt
in use) if you decide to use QNAM.

Failure to do so can, depending on your code, lead to crashes or hangs
within your applications. If I recall right the Qt Installer Framework
(Qt 4) crashes when it encounters a redirect (it caused the Necessitas
SDK installer to crash anyway).

Not handling redirects restricts the ability of Sysadmin to change
infrastructure as needed - so please ensure you get this right.

If you'd like to avoid all of this: just use KIO - which gets it right
and handles redirects out of the box for you.

Cheers,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plamsa Stable Build.kde.org failures

[Ben Cooksley]

On Fri, Jul 1, 2016 at 10:41 PM, David Edmundson
 wrote:
>
> On Thu, Jun 30, 2016 at 10:25 PM, Ben Cooksley  wrote:
>>
>> Hi David,
>>
>> On Fri, Jul 1, 2016 at 12:50 AM, David Edmundson
>>  wrote:
>> > I wanted to write up why Plasma stable is failing on CI so that we have
>> > a
>> > written down record. (and so we don't keep getting told off by sysadmins
>> > for
>> > not fixing it)
>>
>> Sorry if it seems like we've done that.
>> I don't see any issue with the situation we're in here - Qt version
>> upgrades happen (although advance notice of needing it is nice so
>> we can be ready in advance)
>>
>> >
>> > Plasma 5.7 requires Qt 5.6
>> > The "stable-kf5-qt5 " layer on CI  builds against Qt 5.5
>> >
>> > Can we set Plasma stable to use latest Qt/Frameworks (the kf5-qt5 layer
>> > master uses):
>> >
>> > Yes, but:
>> > [10:06]  you'll just end up without a CI on your master
>> >
>> >
>> > Can we update the stable-kf5-qt5 layer to use a newer Qt:
>> > Not without upping the Qt used by Applications/16.04
>> >
>> > Could we add another layer:
>> >
>> > [10:04]  new layer is even more painful
>> > [10:04]  requires adjusting the DSL
>> > [10:04]  and building Qt another time
>> > [10:05]  plus all of Frameworks
>> > [10:05]  and anything else which Plasma happens to need in
>> > there
>> >
>> > Is there a long term plan:
>> >
>> > Michael Pyne/Ben have a thread redesigning logical-module-strucutre in
>> > that
>> > long email thread somewhere. See thread
>> > "Proposal to improving KDE Software Repository Organization"
>>
>> Anyone interested in helping with this point?
>>
>> >
>> >
>> > Is there a short term plan:
>> >
>> > Personally I think our our only viable short term options are:
>> >  -  forcing Qt5.6 on the stable branches of applications. Theoretically
>> > it
>> > won't break anything (though in practice who knows)
>> >  - turning off the CI for Plasma stable for now.
>>
>> Option #1 from that list is probably the easiest thing.
>> Applications doesn't actually need Qt 5.5 - it just happens to be what
>> is there currently.
>>
>> It does mean a carefully orchestrated rebuild of everything on
>> stable-kf5-qt5 is necessary though, due to Qt's issues with
>> compatibility.
>>
> Does carefully orchestrated mean clicking "rebuild now" on everything in a
> vaguely valid order until it works?

Yes. For the frameworks around KXMLGUI / KIO / KParts (I think) you
have to rebuild them in an exactly precise order, otherwise they'll
fail.
Same goes for large parts of KDE PIM.

I've tended to use the "mash the build button until it all goes green"
approach...

>
> If so I can do that. Just give me the go ahead and I'll make the changes

As long as nobody is planning any releases in the next couple of days
for Frameworks / Applications it should be fine from my point of view.
You'll need to update logical-module-structure, then wait until the
DSL job has finished to update the Jenkins job to point to the right
branch.

>
> David
>
>

Cheers,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plamsa Stable Build.kde.org failures

[Ben Cooksley]

Hi David,

On Fri, Jul 1, 2016 at 12:50 AM, David Edmundson
 wrote:
> I wanted to write up why Plasma stable is failing on CI so that we have a
> written down record. (and so we don't keep getting told off by sysadmins for
> not fixing it)

Sorry if it seems like we've done that.
I don't see any issue with the situation we're in here - Qt version
upgrades happen (although advance notice of needing it is nice so
we can be ready in advance)

>
> Plasma 5.7 requires Qt 5.6
> The "stable-kf5-qt5 " layer on CI  builds against Qt 5.5
>
> Can we set Plasma stable to use latest Qt/Frameworks (the kf5-qt5 layer
> master uses):
>
> Yes, but:
> [10:06]  you'll just end up without a CI on your master
>
>
> Can we update the stable-kf5-qt5 layer to use a newer Qt:
> Not without upping the Qt used by Applications/16.04
>
> Could we add another layer:
>
> [10:04]  new layer is even more painful
> [10:04]  requires adjusting the DSL
> [10:04]  and building Qt another time
> [10:05]  plus all of Frameworks
> [10:05]  and anything else which Plasma happens to need in there
>
> Is there a long term plan:
>
> Michael Pyne/Ben have a thread redesigning logical-module-strucutre in that
> long email thread somewhere. See thread
> "Proposal to improving KDE Software Repository Organization"

Anyone interested in helping with this point?

>
>
> Is there a short term plan:
>
> Personally I think our our only viable short term options are:
>  -  forcing Qt5.6 on the stable branches of applications. Theoretically it
> won't break anything (though in practice who knows)
>  - turning off the CI for Plasma stable for now.

Option #1 from that list is probably the easiest thing.
Applications doesn't actually need Qt 5.5 - it just happens to be what
is there currently.

It does mean a carefully orchestrated rebuild of everything on
stable-kf5-qt5 is necessary though, due to Qt's issues with
compatibility.

>
> I'm not sure what other options there are.
>
> David
>
>

Cheers,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Broken Builds

[Ben Cooksley]

On Sun, Jun 19, 2016 at 9:44 AM, Burkhard Lück  wrote:
> Am Sonntag, 19. Juni 2016, 09:38:07 CEST schrieb Ben Cooksley:
>
>> - Cervisia (latest-qt4): Likely outdated build metadata, it looks to
>> be trying to build Frameworks/Qt 5 code in the Qt 4 environment
>
> Cervisia master ist kf5 based since a few days

Please note that it's the maintainers/developers responsibility to
keep the build metadata file up to date with the relevant information
concerning their project (this is the only scalable method due to the
number of projects that are developed under the KDE Umbrella)

If this is the case, would the Cervisia developers mind fixing things please?

>
> --
> Burkhard Lück
>

Cheers,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Broken Builds

[Ben Cooksley]

Hi all,

On the CI system there are currently a number of broken builds which
have occurred in recent times. It would be appreciated if folks could
fix those.

They are:
- Cervisia (latest-qt4): Likely outdated build metadata, it looks to
be trying to build Frameworks/Qt 5 code in the Qt 4 environment
- kdepim-runtime (stable-kf5-qt5): Missing *.ui file, or alternatively
the build system is not setup to handle highly parallel compilation
and attempts to use the output of the header generation process before
it has been produced.
- khotkeys (kf5-qt5): Missing plugin metadata file, or also lacking
setup for highly parallel compilation.
- kdeconnect-kde (both variants): Appears to be missing a header or
include path setup.
- kmymoney (kf5-qt5): Missing plugin metadata file, or lack of setup
for highly parallel compilation.
- PIM in general (all variants): Has broken binary/source
compatibility in it's various libraries, causing numerous builds to
fail. Please be more careful with the changes you make. I've performed
the necessary rebuilds to fix this.

Thanks,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[sysadmin/ci-master-config] /: Disable new_delete_type_mismatch ASAN checks, due to defective Qt code.

[Ben Cooksley]

Git commit 8bdb20f0189da74e9875be45822e7f9aa872543e by Ben Cooksley.
Committed on 26/04/2016 at 06:41.
Pushed by bcooksley into branch 'master'.

Disable new_delete_type_mismatch ASAN checks, due to defective Qt code.
We've little choice but to disable this for the next few weeks, until the 
necessary patches make their way through the Qt processes.
CCMAIL: kde-frameworks-de...@kde.org
CCMAIL: plasma-devel@kde.org

Differential Revision: https://phabricator.kde.org/D1489

M  +1-1base.groovy

http://commits.kde.org/sysadmin/ci-master-config/8bdb20f0189da74e9875be45822e7f9aa872543e

diff --git a/base.groovy b/base.groovy
index 9b0cb30..e925073 100644
--- a/base.groovy
+++ b/base.groovy
@@ -366,7 +366,7 @@ while(projects.hasNext()) {
environmentVariables {
env('JENKINS_SLAVE_HOME', 
'/home/jenkins/scripts')
env('JENKINS_TEST_HOME', '/home/jenkins')
-   env('ASAN_OPTIONS', 'detect_leaks=0')
+   env('ASAN_OPTIONS', 
'detect_leaks=0:new_delete_type_mismatch=0')
env('XDG_CONFIG_DIRS', 
'/etc/xdg/xdg-plasma:/etc/xdg:/usr/share/:${JENKINS_TEST_HOME}/.qttest/config')
env('XDG_DATA_DIRS', 
'/usr:/usr/share:${JENKINS_TEST_HOME}/.local/share')
env('XDG_DATA_HOME', 
'${JENKINS_TEST_HOME}/.qttest/share:${JENKINS_TEST_HOME}/.local/share') 
   
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [KDE Usability] Review Request 126953: Remove Theme Details KCM

[Ben Cooksley]

Hi,

Please refrain from using the phrase "KDE Identity" outside the context of
KDE.org sites which use identity.kde.org for login.
For a moment there I thought you were referring to breakages in our
infrastructure.

Regards,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Workspace - Improperly exporting targets

[Ben Cooksley]

On Wed, Mar 30, 2016 at 3:19 AM, Aleix Pol  wrote:
> On Tue, Mar 29, 2016 at 11:07 AM, Ben Cooksley  wrote:
>> On Tue, Mar 29, 2016 at 7:03 PM, Martin Graesslin  wrote:
>>> On Tuesday, March 29, 2016 10:13:02 AM CEST Ben Cooksley wrote:
>>>> Hi Plasma Devs,
>>>>
>>>> It would appear Plasma Workspace is improperly exporting it's targets,
>>>> leading to build failures. This particularly affects Apper, which is
>>>> unable to build on the CI system as a result. Please ensure when
>>>> exporting targets / finding libraries that the full path to the
>>>> library is given, not a short name.
>>>>
>>>> Please see
>>>> https://build.kde.org/job/apper%20master%20kf5-qt5/3/PLATFORM=Linux,compile
>>>> r=gcc/consoleFull for more details.
>>>
>>> Well it looks like Apper is doing it wrong. It links kworkspace5 instead of
>>> PW::KWorkspace
>>
>> If someone could push a fix to Apper that would be appreciated.
>> (I don't have the necessary environment and would be making it blindly)
>
> Fixed.

Thanks, Apper is now green :)

>
> Aleix

Cheers,
Ben

> ___
> Kde-buildsystem mailing list
> kde-buildsys...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Workspace - Improperly exporting targets

[Ben Cooksley]

On Tue, Mar 29, 2016 at 7:03 PM, Martin Graesslin  wrote:
> On Tuesday, March 29, 2016 10:13:02 AM CEST Ben Cooksley wrote:
>> Hi Plasma Devs,
>>
>> It would appear Plasma Workspace is improperly exporting it's targets,
>> leading to build failures. This particularly affects Apper, which is
>> unable to build on the CI system as a result. Please ensure when
>> exporting targets / finding libraries that the full path to the
>> library is given, not a short name.
>>
>> Please see
>> https://build.kde.org/job/apper%20master%20kf5-qt5/3/PLATFORM=Linux,compile
>> r=gcc/consoleFull for more details.
>
> Well it looks like Apper is doing it wrong. It links kworkspace5 instead of
> PW::KWorkspace

If someone could push a fix to Apper that would be appreciated.
(I don't have the necessary environment and would be making it blindly)

>
> Cheers
> Martin

Thanks,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

KHotKeys: Plugin metadata missing?

[Ben Cooksley]

Hi Plasma Devs,

It would seem that KHotkeys now fails to build, due to either:
a) Missing plugin metadata
b) Missing CMake target dependencies between the automoc task and the
task that generates the plugin metadata.

Could someone correct this please?
https://build.kde.org/view/branchGroup%20kf5-qt5/job/khotkeys%20master%20kf5-qt5/2/PLATFORM=Linux,compiler=gcc/console

Thanks,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Workspace - Improperly exporting targets

[Ben Cooksley]

On Tue, Mar 29, 2016 at 10:59 AM, Stephen Kelly  wrote:
> Ben Cooksley wrote:
>
>> Hi Plasma Devs,
>>
>> It would appear Plasma Workspace is improperly exporting it's targets,
>> leading to build failures. This particularly affects Apper, which is
>> unable to build on the CI system as a result. Please ensure when
>> exporting targets / finding libraries that the full path to the
>> library is given, not a short name.
>>
>> Please see
>> https://build.kde.org/job/apper%20master%20kf5-qt5/3/PLATFORM=Linux,compiler=gcc/consoleFull
>> for more details.
>
> Hi Ben,

Hi Steve,

>
> Is this a result of some specific recent commit? Or has it been failing list
> this for a while?

Unfortunately it isn't possible to tell - the previous CI system was
wiped when we migrated to the new system.
I suspect it has probably been failing for some time, but can't confirm that.

Sorry I can't provide much more information here.

>
> Thanks,
>
> Steve.

Thanks,
Ben

>
>
> ___
> Kde-buildsystem mailing list
> kde-buildsys...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasma Workspace - Improperly exporting targets

[Ben Cooksley]

Hi Plasma Devs,

It would appear Plasma Workspace is improperly exporting it's targets,
leading to build failures. This particularly affects Apper, which is
unable to build on the CI system as a result. Please ensure when
exporting targets / finding libraries that the full path to the
library is given, not a short name.

Please see 
https://build.kde.org/job/apper%20master%20kf5-qt5/3/PLATFORM=Linux,compiler=gcc/consoleFull
for more details.

Thanks,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: apidocs page seems broken

[Ben Cooksley]

On Mon, Feb 8, 2016 at 1:29 PM, Valorie Zimmerman
 wrote:
> On Sun, Feb 7, 2016 at 2:56 PM, Albert Astals Cid  wrote:
>> Someone on irc said
>>
>>  All the links on 
>> http://api.kde.org/frameworks-api/frameworks5-apidocs/ are failing for me 
>> with a "Not Found" error
>>
>> Cheers,
>>   Albert
>
> I can confirm that the links are all broken.

From the server:

22:08:31 INFO Generating dependency diagram
Traceback (most recent call last):
  File "/home/api/kapidox/src/kgenframeworksapidox", line 411, in 
main()
  File "/home/api/kapidox/src/kgenframeworksapidox", line 384, in main
ok = generate_diagram(png_path, fwinfo['fancyname'], t, dot_files, tmp_dir)
  File "/home/api/kapidox/src/kgenframeworksapidox", line 181, in
generate_diagram
ok = depdiagram.generate(f, dot_files, framework=fancyname, with_qt=with_qt)
  File "/home/api/kapidox/src/kapidox/depdiagram/generate.py", line
157, in generate
db.populate(dot_files, with_qt=with_qt)
  File "/home/api/kapidox/src/kapidox/depdiagram/frameworkdb.py", line
166, in populate
with open(yaml_file) as f:
IOError: [Errno 2] No such file or directory:
'/home/api/dependency-information/kf5-qt5/frameworks/kdeclarative/inst/KDeclarative.yaml'

Someone fix KDeclarative please (something in the CMake magic
generates that file), and kapidox needs hardening against improper
setup of Frameworks.
This should also have been caught in the review process!

This is far from the first time that improper metadata has broken the
API Documentation generation requiring sysadmin to look into this.

>
> Valorie

Regards,
Ben

> ___
> kde-www mailing list
> kde-...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-www
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: robots.txt in quickgit.kde.org

[Ben Cooksley]

On Wed, Jan 6, 2016 at 3:17 AM, Kevin Funk  wrote:
> On Wednesday, December 30, 2015 12:57:23 PM Ben Cooksley wrote:
>> On Tue, Dec 29, 2015 at 11:16 PM, Kevin Funk  wrote:
>> > On Tuesday, December 29, 2015 10:39:01 PM Ben Cooksley wrote:
>> >> On Tue, Dec 29, 2015 at 7:59 AM, Lydia Pintscher  wrote:
>> >> > On Sun, Dec 27, 2015 at 12:35 PM, Ben Cooksley 
> wrote:
>> >> >>> Is there some place where search engines can easily index our source
>> >> >>> code or are we shooting ourselves in the foot here?
>> >> >>
>> >> >> We could probably make it available by publishing the source trees
>> >> >> used by LXR / EBN.
>> >> >> This would only have the main branches obviously rather than
>> >> >> everything
>> >> >> though.
>> >> >>
>> >> >> I haven't checked, but LXR may already make it's copy of the code
>> >> >> accessible...>
>> >> >
>> >> > I think making our sourcecode available to search engines is pretty
>> >> > important for the reasons already mentioned by others. Do you need
>> >> > help for it? If you write down what's needed I can help find someone
>> >> > to do it.
>> >>
>> >> I've now provisioned https://sources.kde.org/
>> >
>> > I'm not sure this is super useful, to be honest (as mentioned in #kde-
>> > sysadmins already).
>> >
>> > This is really just plain file serving, with no cross-references to either
>> > LXR (or apidocs). This is basically a dead-end when you follow a result
>> > on Google.
>> >
>> > Wouldn't it be possible to let robots index https://lxr.kde.org/source/
>> >
>> >  instead? We have the infrastructure...
>>
>> We'll give it a shot.
>
> Just to stress again this would be *really* useful to have.



>
> I answered a post on SO:
>   http://stackoverflow.com/a/34612692/592636
>
> Tried to link kwallet's FindGpgpme.cmake into the answer; and there's *no*
> easy way quickly get a link to KDE infrastructure serving the file via Google
> (not even api.kde.org).
>
> Try googling for "kwallet findgpgme.cmake" (very specific search after all):
>   https://www.google.de/search?q=kwallet+findgpgme.cmake
>
> -> First result: Github..., rest: mildly interesting
>
>
> Different issue I just noticed: There's no way to get the plain-text (raw)
> representation of a given file on LXR, is there? Would be useful as well.

There isn't a link in our templates, but my Google fu (and subsequent
tests confirm) that adding the parameter "_raw=1" to a LXR source view
URL will return the file without any HTML around it.

>
> Cheers,
> Kevin

Regards,
Ben

>
>> > Of course we need to blacklist all the pages allowing to actively *search*
>> > LXR for robots, in order to avoid abuse.
>>
>> Note that despite robots.txt, many spiders (including Google, Yahoo
>> and Bing) will actively disregard the instructions in there.
>> While they may not return the results - or omit snippets of the page
>> content - they have all been guilty (at least in the past) of
>> disregarding our restrictions, resulting in downtime (which have in
>> some cases necessitated full host reboots to fix) for numerous KDE.org
>> subsites in the past.
>>
>> This is why QuickGit and WebSVN have extremely restrictive robots.txt
>> policies, in addition to blacklist rules within our web server
>> configurations.
>>
>> > Cheers,
>> > Kevin
>>
>> Regards,
>> Ben
>>
>> >> > Cheers
>> >> > Lydia
>> >>
>> >> Regards,
>> >> Ben
>> >>
>> >> > --
>> >> > Lydia Pintscher - http://about.me/lydia.pintscher
>> >> > KDE e.V. Board of Directors / KDE Community Working Group
>> >> > http://kde.org - http://open-advice.org
>> >> >
>> >> >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>> >> >>> unsubscribe <<>>
>> >> >>
>> >> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>> >> >> unsubscribe
>> >> >> <<
>> >
>> > --
>> > Kevin Funk | kf...@kde.org | http://kfunk.org
>
> --
> Kevin Funk | kf...@kde.org | http://kfunk.org
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: robots.txt in quickgit.kde.org

[Ben Cooksley]

On Tue, Dec 29, 2015 at 11:16 PM, Kevin Funk  wrote:
> On Tuesday, December 29, 2015 10:39:01 PM Ben Cooksley wrote:
>> On Tue, Dec 29, 2015 at 7:59 AM, Lydia Pintscher  wrote:
>> > On Sun, Dec 27, 2015 at 12:35 PM, Ben Cooksley  wrote:
>> >>> Is there some place where search engines can easily index our source
>> >>> code or are we shooting ourselves in the foot here?
>> >>
>> >> We could probably make it available by publishing the source trees
>> >> used by LXR / EBN.
>> >> This would only have the main branches obviously rather than everything
>> >> though.
>> >>
>> >> I haven't checked, but LXR may already make it's copy of the code
>> >> accessible...>
>> > I think making our sourcecode available to search engines is pretty
>> > important for the reasons already mentioned by others. Do you need
>> > help for it? If you write down what's needed I can help find someone
>> > to do it.
>>
>> I've now provisioned https://sources.kde.org/
>
> I'm not sure this is super useful, to be honest (as mentioned in #kde-
> sysadmins already).
>
> This is really just plain file serving, with no cross-references to either LXR
> (or apidocs). This is basically a dead-end when you follow a result on Google.
>
> Wouldn't it be possible to let robots index https://lxr.kde.org/source/
>  instead? We have the infrastructure...

We'll give it a shot.

>
> Of course we need to blacklist all the pages allowing to actively *search* LXR
> for robots, in order to avoid abuse.

Note that despite robots.txt, many spiders (including Google, Yahoo
and Bing) will actively disregard the instructions in there.
While they may not return the results - or omit snippets of the page
content - they have all been guilty (at least in the past) of
disregarding our restrictions, resulting in downtime (which have in
some cases necessitated full host reboots to fix) for numerous KDE.org
subsites in the past.

This is why QuickGit and WebSVN have extremely restrictive robots.txt
policies, in addition to blacklist rules within our web server
configurations.

>
> Cheers,
> Kevin

Regards,
Ben

>
>> > Cheers
>> > Lydia
>>
>> Regards,
>> Ben
>>
>> > --
>> > Lydia Pintscher - http://about.me/lydia.pintscher
>> > KDE e.V. Board of Directors / KDE Community Working Group
>> > http://kde.org - http://open-advice.org
>> >
>> >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>> >>> unsubscribe <<>>
>> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>> >> <<
>
> --
> Kevin Funk | kf...@kde.org | http://kfunk.org
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: robots.txt in quickgit.kde.org

[Ben Cooksley]

On Tue, Dec 29, 2015 at 7:59 AM, Lydia Pintscher  wrote:
> On Sun, Dec 27, 2015 at 12:35 PM, Ben Cooksley  wrote:
>>> Is there some place where search engines can easily index our source
>>> code or are we shooting ourselves in the foot here?
>>
>> We could probably make it available by publishing the source trees
>> used by LXR / EBN.
>> This would only have the main branches obviously rather than everything 
>> though.
>>
>> I haven't checked, but LXR may already make it's copy of the code 
>> accessible...
>
> I think making our sourcecode available to search engines is pretty
> important for the reasons already mentioned by others. Do you need
> help for it? If you write down what's needed I can help find someone
> to do it.

I've now provisioned https://sources.kde.org/

>
>
> Cheers
> Lydia

Regards,
Ben

>
> --
> Lydia Pintscher - http://about.me/lydia.pintscher
> KDE e.V. Board of Directors / KDE Community Working Group
> http://kde.org - http://open-advice.org
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: robots.txt in quickgit.kde.org

[Ben Cooksley]

On Mon, Dec 28, 2015 at 12:15 AM, Lydia Pintscher  wrote:
> On Sun, Dec 27, 2015 at 12:08 PM, Ben Cooksley  wrote:
>> On Sun, Dec 27, 2015 at 11:53 PM, Ashish Bansal
>>  wrote:
>>> Hi everyone,
>>
>> Hi Ashish,
>>
>>>
>>> "quickgit.kde.org" contains robots.txt[0] which is disallowing search
>>> engines to fetch the project repos. I just wanted to know if this is
>>> intentional or not?
>>>
>>> If I recall correctly, mirror of kde repositories on github was created just
>>> because it wasn't being indexed by the search engines.
>>
>> This is intentional, and is done to reduce the server load created by
>> indexers such as Google on the system hosting quickgit.kde.org.
>> (Generation of the pages, including the main index is substantially
>> more expensive than it appears due to the disk access required by
>> Git/SVN to return the needed information).
>
> Is there some place where search engines can easily index our source
> code or are we shooting ourselves in the foot here?

We could probably make it available by publishing the source trees
used by LXR / EBN.
This would only have the main branches obviously rather than everything though.

I haven't checked, but LXR may already make it's copy of the code accessible...

>
>
> Cheers
> Lydia

Regards,
Ben

>
> --
> Lydia Pintscher - http://about.me/lydia.pintscher
> KDE e.V. Board of Directors / KDE Community Working Group
> http://kde.org - http://open-advice.org
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: robots.txt in quickgit.kde.org

[Ben Cooksley]

On Sun, Dec 27, 2015 at 11:53 PM, Ashish Bansal
 wrote:
> Hi everyone,

Hi Ashish,

>
> "quickgit.kde.org" contains robots.txt[0] which is disallowing search
> engines to fetch the project repos. I just wanted to know if this is
> intentional or not?
>
> If I recall correctly, mirror of kde repositories on github was created just
> because it wasn't being indexed by the search engines.

This is intentional, and is done to reduce the server load created by
indexers such as Google on the system hosting quickgit.kde.org.
(Generation of the pages, including the main index is substantially
more expensive than it appears due to the disk access required by
Git/SVN to return the needed information).

>
> [0] https://quickgit.kde.org/robots.txt
>
> --
>
> Regards,
> Ashish Bansal
> http://ashish-bansal.in

Regards,
Ben Cooksley
KDE Sysadmin

>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125187: Stop requiring Frameworks 5.15

[Ben Cooksley]

> On Sept. 14, 2015, 8:44 a.m., Martin Gräßlin wrote:
> > -2, a change for a month in the devel branch doesn't make much sense.
> 
> David Faure wrote:
> As you want. You're raising the bar for new contributors, who can't work 
> on your code using the latest KDE Frameworks release.
> 
> You and me might compile everything, but you'll get more contributors if 
> you let people work on workspace and apps using a released frameworks (for 
> which there are distro packages) than if you require them to compile 
> frameworks first. Just like we don't require Qt from git, we shouldn't 
> require KF5 from git, I thought this was the general agreement.
> 
> If you're worried about the ifdef, just use the two liner version of the 
> code forever, I was always a bit dubious about adding a method just for that 
> anyway.
> 
> Martin Gräßlin wrote:
> It's really not that uncommon to depend on latest frameworks in 
> workspace. It's common that I add things in KWindowSystem to make use of it 
> in KWin directly. Or lately I used lots of new functionalty from KGlobalAccel 
> directly.
> 
> Yes it raises the entry level, but it's also rather unlikely that we are 
> able to a policy forbidding depending on frameworks master without CI checks.
> 
> Sebastian Kügler wrote:
> Besides, these occasional devs can use the stable branch en then forward 
> port?
> 
> Marco Martin wrote:
> -2 from here as well for the same reasons
> 
> Ben Cooksley wrote:
> Please note that the CI system is shifting towards only allowing usage of 
> released products. We'll also be imposing a dependency prohibition between 
> Applications and Plasma so there will no longer be any ability to have 
> dependencies between the two.
> 
> Aleix Pol Gonzalez wrote:
> @Ben: Really? Why? Where was this discussed?
> 
> Martin Gräßlin wrote:
> @Ben: where should libraries like kwayland and kdecoration go then? They 
> do not fit requirements of frameworks but might be useable to applications 
> (kwayland is a must have library for any wayland integration).

That has yet to be resolved. Likely another layer which will be released as 
needed by Applications / Plasma which sits in between Frameworks and them will 
be added I suspect. No binary compatibility commitments, same licensing rules 
as Applications / Plasma, just a logically separate product so it doesn't cause 
dependency problems. I don't expect too many libraries or runtime components to 
end up there (Dr Konqi might perhaps?).


- Ben


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


On Sept. 12, 2015, 9:38 a.m., Armin K. wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125187/
> ---
> 
> (Updated Sept. 12, 2015, 9:38 a.m.)
> 
> 
> Review request for Plasma and David Faure.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> KDesktopFile.readMimeTypes(); hasn't made it into Frameworks 5.14, causing 
> plasma-workspace git master to depend on yet unreleased version of KDE 
> Frameworks to build. David Faure has suggested to use fix like this one until 
> at least Frameworks 5.15 have been released.
> 
> I don't have commit access, so someone needs to commit this for me.
> 
> 
> Diffs
> -
> 
>   applets/icon/plugin/icon_p.cpp 97af67a 
> 
> Diff: https://git.reviewboard.kde.org/r/125187/diff/
> 
> 
> Testing
> ---
> 
> It builds.
> 
> 
> Thanks,
> 
> Armin K.
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125187: Stop requiring Frameworks 5.15

[Ben Cooksley]

> On Sept. 14, 2015, 8:44 a.m., Martin Gräßlin wrote:
> > -2, a change for a month in the devel branch doesn't make much sense.
> 
> David Faure wrote:
> As you want. You're raising the bar for new contributors, who can't work 
> on your code using the latest KDE Frameworks release.
> 
> You and me might compile everything, but you'll get more contributors if 
> you let people work on workspace and apps using a released frameworks (for 
> which there are distro packages) than if you require them to compile 
> frameworks first. Just like we don't require Qt from git, we shouldn't 
> require KF5 from git, I thought this was the general agreement.
> 
> If you're worried about the ifdef, just use the two liner version of the 
> code forever, I was always a bit dubious about adding a method just for that 
> anyway.
> 
> Martin Gräßlin wrote:
> It's really not that uncommon to depend on latest frameworks in 
> workspace. It's common that I add things in KWindowSystem to make use of it 
> in KWin directly. Or lately I used lots of new functionalty from KGlobalAccel 
> directly.
> 
> Yes it raises the entry level, but it's also rather unlikely that we are 
> able to a policy forbidding depending on frameworks master without CI checks.
> 
> Sebastian Kügler wrote:
> Besides, these occasional devs can use the stable branch en then forward 
> port?
> 
> Marco Martin wrote:
> -2 from here as well for the same reasons

Please note that the CI system is shifting towards only allowing usage of 
released products. We'll also be imposing a dependency prohibition between 
Applications and Plasma so there will no longer be any ability to have 
dependencies between the two.


- Ben


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


On Sept. 12, 2015, 9:38 a.m., Armin K. wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125187/
> ---
> 
> (Updated Sept. 12, 2015, 9:38 a.m.)
> 
> 
> Review request for Plasma and David Faure.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> KDesktopFile.readMimeTypes(); hasn't made it into Frameworks 5.14, causing 
> plasma-workspace git master to depend on yet unreleased version of KDE 
> Frameworks to build. David Faure has suggested to use fix like this one until 
> at least Frameworks 5.15 have been released.
> 
> I don't have commit access, so someone needs to commit this for me.
> 
> 
> Diffs
> -
> 
>   applets/icon/plugin/icon_p.cpp 97af67a 
> 
> Diff: https://git.reviewboard.kde.org/r/125187/diff/
> 
> 
> Testing
> ---
> 
> It builds.
> 
> 
> Thanks,
> 
> Armin K.
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125161: Make the classic module optional and thus the dependencie to khtml.

[Ben Cooksley]

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

Ship it!


Looks fine to me.

- Ben Cooksley


On Sept. 11, 2015, 12:10 p.m., Patrick von Reth wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125161/
> ---
> 
> (Updated Sept. 11, 2015, 12:10 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: systemsettings
> 
> 
> Description
> ---
> 
> Make the classic module optional and thus the dependencie to khtml.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 6bcd1b1b419a222350957b09bf715b6f88744889 
> 
> Diff: https://git.reviewboard.kde.org/r/125161/diff/
> 
> 
> Testing
> ---
> 
> Windows
> 
> 
> Thanks,
> 
> Patrick von Reth
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 124668: Re-render 5.4 wallpapers with 4x antialiasing and a split noise, compress them.

[Ben Cooksley]

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


I've now corrected the issue with Reviewboard - for some reason the permissions 
weren't marked properly so Apache was rightly denying access to the file(s). I 
suspect Reviewboard fell over part way through processing your upload, so it 
never got to change the permissions on the original files.

- Ben Cooksley


On Aug. 9, 2015, 7:23 a.m., Nikita Skovoroda wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124668/
> ---
> 
> (Updated Aug. 9, 2015, 7:23 a.m.)
> 
> 
> Review request for Plasma, David Edmundson and Martin Klapetek.
> 
> 
> Description
> ---
> 
> Atm, 5.4 wallpapers have pixelated lines and blurred noise (the same as 
> [https://bugs.kde.org/show_bug.cgi?id=346018](https://bugs.kde.org/show_bug.cgi?id=346018)
>  for 5.3).
> 
> I re-rendered them using the same script (4x supersample antialiasing and 
> split noise).
> 
> Split noise means that the noise pattern is not scaled for the different 
> resolution wallpapers (which looked bad on both too low and too high 
> resolutions), but is post-applied and tiled.
> 
> I uploaded the renders and the patch against the 'breeze' repo to 
> [http://oserv.org/files/kde/wallpaper-horizon/](http://oserv.org/files/kde/wallpaper-horizon/)
>  
> 
> Also there is an updated version of the script (render.sh), but the only 
> difference from the previous version is that I added some more comments at 
> the top.
> 
> When reviewing, everything should be viewed at 1:1 scale.
> 
> I also uploaded a separate patch to add a 1366x768 resolution wallpaper, it's 
> (sadly) still rather popular and not covered by any of the existing 
> resolutions without downscaling or cropping from both edges.
> 
> 
> Diffs
> -
> 
> 
> Diff: https://git.reviewboard.kde.org/r/124668/diff/
> 
> 
> Testing
> ---
> 
> Just opened the wallpapers at 1:1 scale and compared them.
> Also I put the corresponding resolution version as my current wallpaper =).
> 
> 
> File Attachments
> 
> 
> 1024x768 before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/08/09/759129c3-b0c6-40a4-96a2-45489899c0cd__1024x768.png
> 1024x768 after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/08/09/0800d133-08a1-4599-9942-25e3762c5ab0__1024x768.png
> 3200x2000 before (top-left part)
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/08/09/95c0b177-209f-4fe6-a1c8-ead02199f32d__3200x2000-topleft-before.png
> 3200x2000 after (top-left part)
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/08/09/61e34da3-b9eb-4a88-b2b7-455bf3dcc322__3200x2000-topleft-after.png
> 
> 
> Thanks,
> 
> Nikita Skovoroda
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: on review process again.. phabricator?

[Ben Cooksley]

On Mon, Jul 13, 2015 at 12:06 AM, Ivan Čukić  wrote:
> One issue from 'many projects sharing the same phab' is that the main
> page gets populated with 'Unbreak now!' issues from other projects.

The main page can probably be customised I suspect. The instance at
https://secure.phabricator.com/ shows feeds of recent activity for
instance, and the Differential and Maniphest pages there contain
personalised variants by default.

>
> Nothing really problematic, but it would be nice if these would be
> filtered on the projects a user is interested on.
>
> Cheers,
> Ivan

Regards,
Ben

>
> On 8 July 2015 at 23:20, Ben Cooksley  wrote:
>> On Thu, Jul 9, 2015 at 2:18 AM, Boudewijn Rempt  wrote:
>>> On Wed, 8 Jul 2015, Marco Martin wrote:
>>>
>>>> Some projects are trying out phabricator (looking at kactivities) how do
>>>> they find it?
>>>
>>>
>>> Krita developers, testers and designers all feel Phabricator is pretty fab.
>>> Newbies take to it easiliy. It takes getting used to because it's more than
>>> a reviewboard replacement, it also has project management, task management
>>> and much more.
>>>
>>> The way different projects/repos share the website is a bit of a put-off at
>>> the moment. You don't get kactivities.phabricator.kde.org, but you find all
>>> repos in one website.
>>
>> Unfortunately there is little we can do about this - it, like most
>> software out there, is designed for one project sharing a very closely
>> related group of tasks, repositories, etc. KDE doesn't really fit that
>> pattern anymore, but having multiple instances of it is totally
>> infeasible.
>>
>> I'd like to know more about where this falls down though to see if it
>> can be remedied to a certain extent.
>>
>>>
>>>> can it go more large scale? (more a sysadmin question) If it doesn't have
>>>> big obvious problems I would like to try it on plasma-framework at least. 
>>>> To
>>>> eventually have plasma-workspace et al too, but not yet (at least I would
>>>> never want gerrit on those projects..)
>>>
>>>
>>> Boudewijn
>>
>> Cheers,
>> Ben
>>
>>>
>>> ___
>>> Plasma-devel mailing list
>>> Plasma-devel@kde.org
>>> https://mail.kde.org/mailman/listinfo/plasma-devel
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
>
> --
> Cheerio,
> Ivan
>
> --
> While you were hanging yourself on someone else's words
> Dying to believe in what you heard
> I was staring straight into the shining sun
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: on review process again.. phabricator?

[Ben Cooksley]

On Thu, Jul 9, 2015 at 7:25 PM, Boudewijn Rempt  wrote:
> On Wed, 8 Jul 2015, Aleix Pol wrote:
>
>> Is it public? It could be useful to see what it looks like to get an
>> idea...
>
>
>
> Sure, go to phabricator.kde.org and login with your identity in the ldap
> login box.

In many cases you shouldn't need to login, unless we've misconfigured it

>
>
> Boudewijn

Cheers,
Ben

> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: on review process again.. phabricator?

[Ben Cooksley]

On Thu, Jul 9, 2015 at 2:18 AM, Boudewijn Rempt  wrote:
> On Wed, 8 Jul 2015, Marco Martin wrote:
>
>> Some projects are trying out phabricator (looking at kactivities) how do
>> they find it?
>
>
> Krita developers, testers and designers all feel Phabricator is pretty fab.
> Newbies take to it easiliy. It takes getting used to because it's more than
> a reviewboard replacement, it also has project management, task management
> and much more.
>
> The way different projects/repos share the website is a bit of a put-off at
> the moment. You don't get kactivities.phabricator.kde.org, but you find all
> repos in one website.

Unfortunately there is little we can do about this - it, like most
software out there, is designed for one project sharing a very closely
related group of tasks, repositories, etc. KDE doesn't really fit that
pattern anymore, but having multiple instances of it is totally
infeasible.

I'd like to know more about where this falls down though to see if it
can be remedied to a certain extent.

>
>> can it go more large scale? (more a sysadmin question) If it doesn't have
>> big obvious problems I would like to try it on plasma-framework at least. To
>> eventually have plasma-workspace et al too, but not yet (at least I would
>> never want gerrit on those projects..)
>
>
> Boudewijn

Cheers,
Ben

>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Shutdown/Logout/Restart problems with KDE/Plasma5

[Ben Cooksley]

On Wed, Jul 8, 2015 at 9:26 PM, Christian Butcher  wrote:
> I originally send this to kde-linux, and was advised to post to
> plasma-devel.
>
> When I go to use the logout/shutdown/restart buttons in Plasma 5, the
> computer does not take the action requested.
>
> A message in the style of
>
> Shutdown called with confirm  -1  type  2  and mode  -1
>
> is appended to ~/.xsession-errors each second (approximately, I didn't time
> it).
>
> qdbus org.kde.ksmserver /KSMServer org.kde.KSMServerInterface.logout x y z
>
> with x, y, z some integer (not just the values allowed) does the same, and
> the log reflects the values passed.
>
> In this case, at the time of the request, but only once, the
> ~/.xsession-errors shows also
>
> kf5.kinit.klauncher: appId= ":1.49" newAppId= ":1.49" pendingAppId=
> "*.polkit-kde-authentication-agent-1"
> kf5.kinit.klauncher: appName= "49"

And here is your problem. I'm going to guess that your session doesn't
restore and the system seems to take a long time to login as well.
To workaround as an immediate fix: killall -9 polkit-kde-authentication-agent-1

>
> I don't have systemd.
> ConsoleKit is build from a revision somewhere around 0.9.2 from the
> ConsoleKit2 github repository, and running ck-list-sessions returns two
> sessions, such as:
>
> Session3:
>unix-user = '1000'
>realname = 'Christian'
>seat = 'Seat1'
>session-type = ''
>active = TRUE
>x11-display = ':0'
>x11-display-device = '/dev/tty7'
>display-device = ''
>remote-host-name = ''
>is-local = TRUE
>on-since = '2015-07-08T08:36:30.639138Z'
>login-session-id = '6'
> Session2:
>unix-user = '1000'
>realname = 'Christian'
>seat = 'Seat3'
>session-type = ''
>active = FALSE
>x11-display = ':0'
>x11-display-device = ''
>display-device = ''
>remote-host-name = ''
>is-local = TRUE
>on-since = '2015-07-08T08:36:28.901189Z'
>login-session-id = '6'
>
> It can be seen that one is TRUE/TRUE, whilst the other is FALSE/TRUE, which
> seems reasonable. Playing with files in /etc/pam.d/{sddm,sddm-greeter} or
> /usr/share/sddm/scripts/Xsession can change these, but they tend to become
> more problematic/messy, rather than less.
>
>
> Any ideas what I could look into to try and fix this?
>
> Possibly related, although maybe not:
> InputActions doesn't run on startup, despite being selected. Several other
> startup services behave similarly. I found a text file that confirmed this,
> although I can't now find it again.
>
> Some reports of similar issues suggested that the problem might lie in the
> ability to play .ogg sound files, such as
> /opt/kde/share/sounds/Oxygen-Sys-Log-Out.ogg. Although I did have some
> problems playing this (and other) sound file(s), I have since managed to fix
> that up by some combination of installing KMix, adding 'load-module
> module-device-manager' to the bottom of /etc/pulse/default.pa and adding the
> plasma-volume-control in Harold Sitter's scratch repository. Sound files
> (including the Log-Out.ogg) now play fine.
>
> Any advice appreciated,
> Chris

Regards,
Ben

>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122781: Enable high DPI pixmaps in systemsettings

[Ben Cooksley]

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


Coding all looks fine from my perspective.
I don't have a Plasma 5 environment though - so can't comment on how well this 
works.

- Ben Cooksley


On March 2, 2015, 6:51 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122781/
> ---
> 
> (Updated March 2, 2015, 6:51 p.m.)
> 
> 
> Review request for Plasma and Ben Cooksley.
> 
> 
> Repository: systemsettings
> 
> 
> Description
> ---
> 
> Enable high DPI pixmaps in systemsettings
> 
> 
> Diffs
> -
> 
>   app/main.cpp 150ca90 
> 
> Diff: https://git.reviewboard.kde.org/r/122781/diff/
> 
> 
> Testing
> ---
> 
> Went through every KCM in systemsettings with 
> QT_DEVICE_PIXEL_RATIO=2,including tree view and checked that nothing was 
> broken.
> 
> 
> A few things are still low res pixmaps scaled up, but without this everything 
> is low res pixmaps scaled up, so it's no worse.
> Full list of TODO tasks at 
> https://todo.kde.org/?controller=task&action=show&task_id=981.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Qt 5 buildability

[Ben Cooksley]

On Fri, Jan 9, 2015 at 10:19 PM, Martin Gräßlin  wrote:
> On Friday 09 January 2015 22:14:09 Ben Cooksley wrote:
>> On Fri, Jan 9, 2015 at 10:59 AM, Ben Cooksley  wrote:
>> > Hi all,
>> >
>> > I'm not sure about which list is most appropriate for this, so i'm
>> > sending it here.
>> > It seems that changes from Qt 5.3 to 5.4 have introduced a series of
>> > hidden dependencies.
>> >
>> > QtWebEngine won't build unless you have nss-devel installed (which it
>> > complains about) but it also won't build unless libcap-devel is
>> > installed (which it doesn't complain about - you only find out when
>> > the compiler bails out on you).
>> >
>> > The real big issue here though is none of this is integrated with
>> > ./configure, and the failure in QtWebEngine is fatal. Can someone
>> > please raise this with the Qt developers and get them to fix their
>> > build system please?
>>
>> Unfortunately the Qt developers have bigger problems than the above to fix.
>> Qt 5.4 as it exists in the 5.4 branch at the moment is unbuildable
>> (despite their blocking CI system).
>
> what about disabling the QtWebEngine module for now?

We did a similar head bury in sand act when CMake regressions broke our builds.
Let's not repeat that experience.

Our system has detected a breakage upstream, let's get them to fix it
*now* not when some part of KDE begins to use QtWebEngine.

>
>>
>> Please see http://build.kde.org/view/FAILED/job/qt5_master_qt5/168/console
>> for why.
>> Could someone prod them into fixing their build?
>>
>> This means that no KDE project can depend on Qt 5.4 at this time.
>>
>> > Thanks,
>> > Ben
>>
>> Thanks,
>> Ben
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Qt 5 buildability

[Ben Cooksley]

On Fri, Jan 9, 2015 at 10:59 AM, Ben Cooksley  wrote:
> Hi all,
>
> I'm not sure about which list is most appropriate for this, so i'm
> sending it here.
> It seems that changes from Qt 5.3 to 5.4 have introduced a series of
> hidden dependencies.
>
> QtWebEngine won't build unless you have nss-devel installed (which it
> complains about) but it also won't build unless libcap-devel is
> installed (which it doesn't complain about - you only find out when
> the compiler bails out on you).
>
> The real big issue here though is none of this is integrated with
> ./configure, and the failure in QtWebEngine is fatal. Can someone
> please raise this with the Qt developers and get them to fix their
> build system please?

Unfortunately the Qt developers have bigger problems than the above to fix.
Qt 5.4 as it exists in the 5.4 branch at the moment is unbuildable
(despite their blocking CI system).

Please see http://build.kde.org/view/FAILED/job/qt5_master_qt5/168/console
for why.
Could someone prod them into fixing their build?

This means that no KDE project can depend on Qt 5.4 at this time.

>
> Thanks,
> Ben

Thanks,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [kde-promo] Plasma 5.1.1 announcement

[Ben Cooksley]

On Wed, Nov 19, 2014 at 8:14 AM, Albert Astals Cid  wrote:
> El Dimarts, 11 de novembre de 2014, a les 22:53:58, Albert Astals Cid va
> escriure:
>> Hi guys, is there any reason
>> https://www.kde.org/announcements/plasma-5.1.1.php
>>
>> says "Plasma 5 was released in July" and links to
>> https://www.kde.org/announcements/plasma5.0/index.php
>>
>> instead of saying "Plasma 5.1 was released in October" and link to
>> https://www.kde.org/announcements/plasma-5.1/index.php
>>
>> ?
>
> Was the announcement written by a ghost?
>
> Or is the person that wrote the announcement for Plasma 5.1.1 not subscribed
> to neither kde-promo nor plasma-devel?
>
> Anyway, if noone oposes i'll fix it to refer Plasma 5.1 instead of Plasma 5.0.

I would recommend going ahead and making the change, I already had to
fix the download urls for 5.1.1 which were broken.

>
> Cheers,
>   Albert

Thanks,
Ben

>
>>
>> Cheers,
>>   Albert
>>
>> ___
>> This message is from the kde-promo mailing list.
>>
>> Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set
>> digest on or temporarily stop your subscription.
>
>
> ___
> This message is from the kde-promo mailing list.
>
> Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set 
> digest on or temporarily stop your subscription.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Moving repositories in the module structure

[Ben Cooksley]

On Fri, Oct 3, 2014 at 11:33 AM, Víctor Blázquez
 wrote:
> I'm sorry for doing the move that fast, I should have realized it was sent
> only to plasma-devel

No worries - in virtually all cases it is fine to process requests
when we receive them.

>
> Víctor Blázquez

Thanks,
Ben

>
> On Fri, Oct 3, 2014 at 12:04 AM, Aleix Pol  wrote:
>>
>> On Thu, Oct 2, 2014 at 11:34 PM, Ben Cooksley  wrote:
>>>
>>> Hi all,
>>>
>>> It seems there has been a recent outbreak of repository moves which
>>> have been extremely poorly co-ordinated by those doing the requests.
>>>
>>> In addition, it is actually a requirement that modules moving from
>>> Extragear into (what was at least) the SC need to re-transit through
>>> KDE Review.It is also considered proper practice to at least inform
>>> the translation, documentation and release  teams in advance you
>>> intend to make these moves - something which has also been neglected.
>>>
>>> For all further repository structure moves - please ensure you have
>>> received the appropriate consent from the above mentioned teams, and
>>> have announced them on the appropriate mailing lists in advance.
>>>
>>> @Plasma team: plasma-devel@kde.org does not constitute an appropriate
>>> mailing list, as it is not a community wide development mailing list.
>>> Only kde-devel and kde-core-devel qualify for this.
>>>
>>> Thanks,
>>> Ben Cooksley
>>> KDE Sysadmin
>>
>>
>> My apologies, I shouldn't have rushed into doing such moves and send
>> e-mails to all the interested parties.
>>
>> If someone considers it appropriate, I can roll some of the changes back.
>> Aleix
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Moving repositories in the module structure

[Ben Cooksley]

On Fri, Oct 3, 2014 at 2:28 PM, Aleix Pol  wrote:
> On Fri, Oct 3, 2014 at 1:52 AM, Albert Astals Cid  wrote:
>>
>> El Divendres, 3 d'octubre de 2014, a les 00:04:42, Aleix Pol va escriure:
>> > On Thu, Oct 2, 2014 at 11:34 PM, Ben Cooksley  wrote:
>> > > Hi all,
>> > >
>> > > It seems there has been a recent outbreak of repository moves which
>> > > have been extremely poorly co-ordinated by those doing the requests.
>> > >
>> > > In addition, it is actually a requirement that modules moving from
>> > > Extragear into (what was at least) the SC need to re-transit through
>> > > KDE Review.It is also considered proper practice to at least inform
>> > > the translation, documentation and release  teams in advance you
>> > > intend to make these moves - something which has also been neglected.
>> > >
>> > > For all further repository structure moves - please ensure you have
>> > > received the appropriate consent from the above mentioned teams, and
>> > > have announced them on the appropriate mailing lists in advance.
>> > >
>> > > @Plasma team: plasma-devel@kde.org does not constitute an appropriate
>> > > mailing list, as it is not a community wide development mailing list.
>> > > Only kde-devel and kde-core-devel qualify for this.
>> > >
>> > > Thanks,
>> > > Ben Cooksley
>> > > KDE Sysadmin
>> >
>> > My apologies, I shouldn't have rushed into doing such moves and send
>> > e-mails to all the interested parties.
>> >
>> > If someone considers it appropriate, I can roll some of the changes
>> > back.

I don't think it is necessary to revert the changes at the moment.

>>
>> Maybe you should explain the changes so people is aware of them :)
>>
>> Cheers,
>>   Albert
>>
>> > Aleix
>>
>
> Changes:
> - kde-gtk-config was moved from extragear/base to kde/workspace.
> - muon was moved from extragear/sysadmin to kde/workspace.
>
> That is, only projects.kde.org structure change.
>
> The reasoning is that this way they will be released together with Plasma
> Workspace. As they've been used they don't really make sense outside Plasma
> (especially the first) and we want to make sure that distros know these
> components are designed to work together with Plasma.
>
> I didn't notify kde-core-devel because it didn't occur to me that the
> community would have an opinion regarding whether it's me who releases the
> packages or Jonathan (who has been doing the Plasma packages).

Who is doing the releasing doesn't matter as such. It is the move in
location which matters here - various parts of our infrastructure rely
on these locations. Translations for instance.

Also, while this was only a Extragear to semi-SC module called
kde/workspace move, such moves still probably need announcement so
those interesting in reviewing the code, etc. can do so.

>
> Cheers!
> Aleix

Thanks,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Moving repositories in the module structure

[Ben Cooksley]

Hi all,

It seems there has been a recent outbreak of repository moves which
have been extremely poorly co-ordinated by those doing the requests.

In addition, it is actually a requirement that modules moving from
Extragear into (what was at least) the SC need to re-transit through
KDE Review.It is also considered proper practice to at least inform
the translation, documentation and release  teams in advance you
intend to make these moves - something which has also been neglected.

For all further repository structure moves - please ensure you have
received the appropriate consent from the above mentioned teams, and
have announced them on the appropriate mailing lists in advance.

@Plasma team: plasma-devel@kde.org does not constitute an appropriate
mailing list, as it is not a community wide development mailing list.
Only kde-devel and kde-core-devel qualify for this.

Thanks,
Ben Cooksley
KDE Sysadmin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 119822: QScreen backend for libkscreen

[Ben Cooksley]

> On Aug. 18, 2014, 11:55 a.m., Àlex Fiestas wrote:
> > autotests/testqscreenbackend.cpp, line 66
> > 
> >
> > If we don't have a config even though we correctly configured the 
> > backend, should not we fail? a QSKIP might be unnoticed (specially in 
> > jenkins).
> 
> Sebastian Kügler wrote:
> Until we can be sure to have a config running (i.e. either an X or a 
> Wayland server), this would mean we'd have failing tests. I'm happy to remove 
> the SKIP once we have the CI / tooling caught up to bring up a server for us, 
> until then, no use in having it not SKIP.

The CI system already starts an Xvfb server - although this doesn't support 
xrandr...
Plain X itself can't be run headless from what I understand.


- Ben


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


On Aug. 18, 2014, 9:31 a.m., Sebastian Kügler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119822/
> ---
> 
> (Updated Aug. 18, 2014, 9:31 a.m.)
> 
> 
> Review request for Plasma and Solid.
> 
> 
> Repository: libkscreen
> 
> 
> Description
> ---
> 
> This patch adds a QScreen backend to libkscreen.
> 
> This is useful to avoid a dependency on XRandR (at build time) and a running 
> X server at runtime.
> 
> The backend itself is read-only and kept simple. It only reports the basic 
> necessities (which is what QScreen provides).
> 
> The changes are kept to the backends/qscreen directory, so no API has been 
> touched. The changes outside of that directory are autotests, tests, and a 
> fallback to the qscreen backend non non-X11 platforms. The latter will 
> automatically make libkscreen work on Wayland (as far as QScreen allows us 
> to, so r-o). This case otherwise just crashes, and the XRandR backend can't 
> work. If the user specifies the backend using the KSCREEN_BACKEND env var, it 
> will be respected, the automatism only triggers when no backend is 
> explicitely specified. I've also added apidocs in some files, but again, no 
> functional changes.
> 
> The plan is to augment this also with a native Wayland backend, which will 
> take a bit longer to complete (more complex, it's r-w, I have to learn 
> Wayland APIs). That backend is work-in-progress in the sebas/wayland branch. 
> The QScreen backend allows us to test and run our code under Wayland, without 
> crashing, so we can continue the port while a native Wayland backend is 
> conceived.
> 
> You can find the code for this QScreen backend in sebas/qscreen if you'd like 
> to give it a try.
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 18b93c0 
>   autotests/testqscreenbackend.cpp PRE-CREATION 
>   backends/CMakeLists.txt a827ee8 
>   backends/abstractbackend.h 7ffe627 
>   backends/qscreen/CMakeLists.txt PRE-CREATION 
>   backends/qscreen/qscreenbackend.h PRE-CREATION 
>   backends/qscreen/qscreenbackend.cpp PRE-CREATION 
>   backends/qscreen/qscreenconfig.h PRE-CREATION 
>   backends/qscreen/qscreenconfig.cpp PRE-CREATION 
>   backends/qscreen/qscreenoutput.h PRE-CREATION 
>   backends/qscreen/qscreenoutput.cpp PRE-CREATION 
>   backends/qscreen/qscreenscreen.h PRE-CREATION 
>   backends/qscreen/qscreenscreen.cpp PRE-CREATION 
>   src/CMakeLists.txt 4606862 
>   src/backendloader.cpp d6ccdff 
>   src/config.h 10a8f1e 
>   tests/CMakeLists.txt 86efedc 
>   tests/testplugandplay.cpp PRE-CREATION 
>   tests/testpnp.h PRE-CREATION 
>   tests/testpnp.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/119822/diff/
> 
> 
> Testing
> ---
> 
> * Ran autotest "testqscreenbackend" under X11 and Wayland -- all pass
> * Tested hotplugging (using included testpnp app) under X11
> * Started plasmashell with KSCREEN_BACKEND=QScreen under X11
> * Started kcmshell5 kcm_kscreen
> 
> All of these work correctly in my tests, no strange behaviour observed.
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118388: rename systemsettings binary to systemsettings5

[Ben Cooksley]

> On May 29, 2014, 7:10 a.m., Ben Cooksley wrote:
> > Code wise, this change looks fine. In terms of renaming the desktop files - 
> > i'm fine with changing the filenames, but please don't change the name of 
> > the application itself. Ideally the KF5 based system settings will still be 
> > able to set configuration details relevant for KDE 4 applications.
> 
> Hrvoje Senjan wrote:
> >Ideally the KF5 based system settings will still be able to set 
> configuration details relevant for KDE 4 applications.
> 
> that sounds great to me - just that it would need work in every kcm 
> module. additional caveats:
> what if there's only 4.x variant of the kcm?
> an option is removed in KF5 variant?
> most importantly - how to implement it (different config locations, etc)? 
> =)
> 
> Ben Cooksley wrote:
> Indeed, that could complicate things quite a bit. I'm not sure what we 
> should do in that case then - but we can't have two "System Settings" 
> applications installed which do different things on the same system
> 
> Martin Gräßlin wrote:
> it's kind of the same situation as we had during the KDE3 -> 4 
> transition. We had kcontrol to configure KDE3 and systemsettings to configure 
> KDE4.
> 
> The big problem for the developers is that we don't have any access to 
> the KDE4 configuration files, thus it's difficult to adjust the 
> configuration. Now to make it even more complex: should adjusting e.g. the 
> widget style in a Plasma Next session really change the widget style of a 
> Plasma 4 session or just in Plasma Next?
> 
> Ben Cooksley wrote:
> I'm guessing that KDE4 applications probably won't be able to make full 
> use of Plasma Next themes, assuming they keep full compatibility (elements 
> over time may get new names, change format, etc).
> 
> The problem in this case is that the applications have the same name. 
> Should we come up with a new name for the Plasma Next series, or does a 
> mechanism exist to only show particular *.desktop files under Plasma Next / 
> KDE4?
> 
> In any case, the changes to rename the binary and the filenames of the 
> *.desktop files themselves can go ahead - they're independent of this 
> discussion.
> 
> Hrvoje Senjan wrote:
> >In any case, the changes to rename the binary and the filenames of the 
> *.desktop files themselves can go ahead - they're independent of this 
> >discussion.
> so it's a ship it, as is now? ;-)
> 
> Ben Cooksley wrote:
> Yes, it is.
> 
> Hrvoje Senjan wrote:
> are we too late for Plasma/5.0 branch? i guess so...

As this improves co-installability, and System Settings is often referenced for 
user support i'd appreciate being able to have both KDE 4 and Plasma 5 based 
System Settings installable if possible. I've no objections to this going into 
the Plasma/5.0 branch - unless release-team / distributions do...


- Ben


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


On May 28, 2014, 7:32 p.m., Hrvoje Senjan wrote:
> 
> -------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118388/
> ---
> 
> (Updated May 28, 2014, 7:32 p.m.)
> 
> 
> Review request for Plasma and Ben Cooksley.
> 
> 
> Repository: systemsettings
> 
> 
> Description
> ---
> 
> while workspace might not be targeted to co-exist with 4.x variant - 
> systemsettings should IMHO be able to co-exist. not only workspace components 
> are adjusting in there, and telling people to do kcmshell$notinstalledvariant 
> $wantedkcm is very user-unfriendly...
> one TODO if this gets a green light, is to rename desktop files, so people 
> know which variant they are opening.
> 
> 
> Diffs
> -
> 
>   app/systemsettings.desktop 5f27318 
>   app/kdesystemsettings.desktop 946d498 
>   app/CMakeLists.txt c45f7e7 
> 
> Diff: https://git.reviewboard.kde.org/r/118388/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118387: Bump systemsettingsview SOVERSION to 5

[Ben Cooksley]

> On June 16, 2014, 6:54 a.m., Ben Cooksley wrote:
> > As systemsettingsview is unlikely to break BC any further in the 4.x 
> > series, could the bump be to SOVERSION 3 instead please?
> > Otherwise, this looks fine to go in from my perspective.
> 
> Hrvoje Senjan wrote:
> off course, i've just used 5, as the rest of the Workspace 'umbrella' 
> uses it.
> 
> Ben Cooksley wrote:
> Any movement on this change Hrvoje? Once the change to SOVERSION 3 is 
> made i'm happy for this to go in - unless there is a compelling reason why it 
> should be 5.
> 
> Hrvoje Senjan wrote:
> i can push as soon as i know which branches to touch. only master makes 
> sense, but want to confirm.

I'm not aware of what the policy is from distributions on bumping SOVERSION in 
minor releases, however as it will probably improve co-installability I suspect 
including this in the release/stable branch would be welcome. I've no 
objections to it - all depends on the policies set by the release-team and 
distributions.


- Ben


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


On May 28, 2014, 7:26 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118387/
> -------
> 
> (Updated May 28, 2014, 7:26 p.m.)
> 
> 
> Review request for Plasma and Ben Cooksley.
> 
> 
> Repository: systemsettings
> 
> 
> Description
> ---
> 
> otherwise if KF5's is in LD_LIBRARY_PATH, there's no way to start 4.x version
> 
> 
> Diffs
> -
> 
>   core/CMakeLists.txt 9752ad7 
> 
> Diff: https://git.reviewboard.kde.org/r/118387/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118388: rename systemsettings binary to systemsettings5

[Ben Cooksley]

> On May 29, 2014, 7:10 a.m., Ben Cooksley wrote:
> > Code wise, this change looks fine. In terms of renaming the desktop files - 
> > i'm fine with changing the filenames, but please don't change the name of 
> > the application itself. Ideally the KF5 based system settings will still be 
> > able to set configuration details relevant for KDE 4 applications.
> 
> Hrvoje Senjan wrote:
> >Ideally the KF5 based system settings will still be able to set 
> configuration details relevant for KDE 4 applications.
> 
> that sounds great to me - just that it would need work in every kcm 
> module. additional caveats:
> what if there's only 4.x variant of the kcm?
> an option is removed in KF5 variant?
> most importantly - how to implement it (different config locations, etc)? 
> =)
> 
> Ben Cooksley wrote:
> Indeed, that could complicate things quite a bit. I'm not sure what we 
> should do in that case then - but we can't have two "System Settings" 
> applications installed which do different things on the same system
> 
> Martin Gräßlin wrote:
> it's kind of the same situation as we had during the KDE3 -> 4 
> transition. We had kcontrol to configure KDE3 and systemsettings to configure 
> KDE4.
> 
> The big problem for the developers is that we don't have any access to 
> the KDE4 configuration files, thus it's difficult to adjust the 
> configuration. Now to make it even more complex: should adjusting e.g. the 
> widget style in a Plasma Next session really change the widget style of a 
> Plasma 4 session or just in Plasma Next?
> 
> Ben Cooksley wrote:
> I'm guessing that KDE4 applications probably won't be able to make full 
> use of Plasma Next themes, assuming they keep full compatibility (elements 
> over time may get new names, change format, etc).
> 
> The problem in this case is that the applications have the same name. 
> Should we come up with a new name for the Plasma Next series, or does a 
> mechanism exist to only show particular *.desktop files under Plasma Next / 
> KDE4?
> 
> In any case, the changes to rename the binary and the filenames of the 
> *.desktop files themselves can go ahead - they're independent of this 
> discussion.
> 
> Hrvoje Senjan wrote:
> >In any case, the changes to rename the binary and the filenames of the 
> *.desktop files themselves can go ahead - they're independent of this 
> >discussion.
> so it's a ship it, as is now? ;-)

Yes, it is.


- Ben


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


On May 28, 2014, 7:32 p.m., Hrvoje Senjan wrote:
> 
> -------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118388/
> ---
> 
> (Updated May 28, 2014, 7:32 p.m.)
> 
> 
> Review request for Plasma and Ben Cooksley.
> 
> 
> Repository: systemsettings
> 
> 
> Description
> ---
> 
> while workspace might not be targeted to co-exist with 4.x variant - 
> systemsettings should IMHO be able to co-exist. not only workspace components 
> are adjusting in there, and telling people to do kcmshell$notinstalledvariant 
> $wantedkcm is very user-unfriendly...
> one TODO if this gets a green light, is to rename desktop files, so people 
> know which variant they are opening.
> 
> 
> Diffs
> -
> 
>   app/systemsettings.desktop 5f27318 
>   app/kdesystemsettings.desktop 946d498 
>   app/CMakeLists.txt c45f7e7 
> 
> Diff: https://git.reviewboard.kde.org/r/118388/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118387: Bump systemsettingsview SOVERSION to 5

[Ben Cooksley]

> On June 16, 2014, 6:54 a.m., Ben Cooksley wrote:
> > As systemsettingsview is unlikely to break BC any further in the 4.x 
> > series, could the bump be to SOVERSION 3 instead please?
> > Otherwise, this looks fine to go in from my perspective.
> 
> Hrvoje Senjan wrote:
> off course, i've just used 5, as the rest of the Workspace 'umbrella' 
> uses it.

Any movement on this change Hrvoje? Once the change to SOVERSION 3 is made i'm 
happy for this to go in - unless there is a compelling reason why it should be 
5.


- Ben


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


On May 28, 2014, 7:26 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118387/
> ---
> 
> (Updated May 28, 2014, 7:26 p.m.)
> 
> 
> Review request for Plasma and Ben Cooksley.
> 
> 
> Repository: systemsettings
> 
> 
> Description
> ---
> 
> otherwise if KF5's is in LD_LIBRARY_PATH, there's no way to start 4.x version
> 
> 
> Diffs
> -
> 
>   core/CMakeLists.txt 9752ad7 
> 
> Diff: https://git.reviewboard.kde.org/r/118387/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118387: Bump systemsettingsview SOVERSION to 5

[Ben Cooksley]

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


As systemsettingsview is unlikely to break BC any further in the 4.x series, 
could the bump be to SOVERSION 3 instead please?
Otherwise, this looks fine to go in from my perspective.

- Ben Cooksley


On May 28, 2014, 7:26 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118387/
> ---
> 
> (Updated May 28, 2014, 7:26 p.m.)
> 
> 
> Review request for Plasma and Ben Cooksley.
> 
> 
> Repository: systemsettings
> 
> 
> Description
> ---
> 
> otherwise if KF5's is in LD_LIBRARY_PATH, there's no way to start 4.x version
> 
> 
> Diffs
> -
> 
>   core/CMakeLists.txt 9752ad7 
> 
> Diff: https://git.reviewboard.kde.org/r/118387/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118388: rename systemsettings binary to systemsettings5

[Ben Cooksley]

> On May 29, 2014, 7:10 a.m., Ben Cooksley wrote:
> > Code wise, this change looks fine. In terms of renaming the desktop files - 
> > i'm fine with changing the filenames, but please don't change the name of 
> > the application itself. Ideally the KF5 based system settings will still be 
> > able to set configuration details relevant for KDE 4 applications.
> 
> Hrvoje Senjan wrote:
> >Ideally the KF5 based system settings will still be able to set 
> configuration details relevant for KDE 4 applications.
> 
> that sounds great to me - just that it would need work in every kcm 
> module. additional caveats:
> what if there's only 4.x variant of the kcm?
> an option is removed in KF5 variant?
> most importantly - how to implement it (different config locations, etc)? 
> =)
> 
> Ben Cooksley wrote:
> Indeed, that could complicate things quite a bit. I'm not sure what we 
> should do in that case then - but we can't have two "System Settings" 
> applications installed which do different things on the same system
> 
> Martin Gräßlin wrote:
> it's kind of the same situation as we had during the KDE3 -> 4 
> transition. We had kcontrol to configure KDE3 and systemsettings to configure 
> KDE4.
> 
> The big problem for the developers is that we don't have any access to 
> the KDE4 configuration files, thus it's difficult to adjust the 
> configuration. Now to make it even more complex: should adjusting e.g. the 
> widget style in a Plasma Next session really change the widget style of a 
> Plasma 4 session or just in Plasma Next?

I'm guessing that KDE4 applications probably won't be able to make full use of 
Plasma Next themes, assuming they keep full compatibility (elements over time 
may get new names, change format, etc).

The problem in this case is that the applications have the same name. Should we 
come up with a new name for the Plasma Next series, or does a mechanism exist 
to only show particular *.desktop files under Plasma Next / KDE4?

In any case, the changes to rename the binary and the filenames of the 
*.desktop files themselves can go ahead - they're independent of this 
discussion.


- Ben


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


On May 28, 2014, 7:32 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118388/
> ---
> 
> (Updated May 28, 2014, 7:32 p.m.)
> 
> 
> Review request for Plasma and Ben Cooksley.
> 
> 
> Repository: systemsettings
> 
> 
> Description
> ---
> 
> while workspace might not be targeted to co-exist with 4.x variant - 
> systemsettings should IMHO be able to co-exist. not only workspace components 
> are adjusting in there, and telling people to do kcmshell$notinstalledvariant 
> $wantedkcm is very user-unfriendly...
> one TODO if this gets a green light, is to rename desktop files, so people 
> know which variant they are opening.
> 
> 
> Diffs
> -
> 
>   app/systemsettings.desktop 5f27318 
>   app/kdesystemsettings.desktop 946d498 
>   app/CMakeLists.txt c45f7e7 
> 
> Diff: https://git.reviewboard.kde.org/r/118388/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118388: rename systemsettings binary to systemsettings5

[Ben Cooksley]

> On May 29, 2014, 7:10 a.m., Ben Cooksley wrote:
> > Code wise, this change looks fine. In terms of renaming the desktop files - 
> > i'm fine with changing the filenames, but please don't change the name of 
> > the application itself. Ideally the KF5 based system settings will still be 
> > able to set configuration details relevant for KDE 4 applications.
> 
> Hrvoje Senjan wrote:
> >Ideally the KF5 based system settings will still be able to set 
> configuration details relevant for KDE 4 applications.
> 
> that sounds great to me - just that it would need work in every kcm 
> module. additional caveats:
> what if there's only 4.x variant of the kcm?
> an option is removed in KF5 variant?
> most importantly - how to implement it (different config locations, etc)? 
> =)

Indeed, that could complicate things quite a bit. I'm not sure what we should 
do in that case then - but we can't have two "System Settings" applications 
installed which do different things on the same system


- Ben


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


On May 28, 2014, 7:32 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118388/
> -------
> 
> (Updated May 28, 2014, 7:32 p.m.)
> 
> 
> Review request for Plasma and Ben Cooksley.
> 
> 
> Repository: systemsettings
> 
> 
> Description
> ---
> 
> while workspace might not be targeted to co-exist with 4.x variant - 
> systemsettings should IMHO be able to co-exist. not only workspace components 
> are adjusting in there, and telling people to do kcmshell$notinstalledvariant 
> $wantedkcm is very user-unfriendly...
> one TODO if this gets a green light, is to rename desktop files, so people 
> know which variant they are opening.
> 
> 
> Diffs
> -
> 
>   app/systemsettings.desktop 5f27318 
>   app/kdesystemsettings.desktop 946d498 
>   app/CMakeLists.txt c45f7e7 
> 
> Diff: https://git.reviewboard.kde.org/r/118388/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118388: rename systemsettings binary to systemsettings5

[Ben Cooksley]

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


Code wise, this change looks fine. In terms of renaming the desktop files - i'm 
fine with changing the filenames, but please don't change the name of the 
application itself. Ideally the KF5 based system settings will still be able to 
set configuration details relevant for KDE 4 applications.

- Ben Cooksley


On May 28, 2014, 7:32 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118388/
> ---
> 
> (Updated May 28, 2014, 7:32 p.m.)
> 
> 
> Review request for Plasma and Ben Cooksley.
> 
> 
> Repository: systemsettings
> 
> 
> Description
> ---
> 
> while workspace might not be targeted to co-exist with 4.x variant - 
> systemsettings should IMHO be able to co-exist. not only workspace components 
> are adjusting in there, and telling people to do kcmshell$notinstalledvariant 
> $wantedkcm is very user-unfriendly...
> one TODO if this gets a green light, is to rename desktop files, so people 
> know which variant they are opening.
> 
> 
> Diffs
> -
> 
>   app/systemsettings.desktop 5f27318 
>   app/kdesystemsettings.desktop 946d498 
>   app/CMakeLists.txt c45f7e7 
> 
> Diff: https://git.reviewboard.kde.org/r/118388/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Problems found by the CI system

[Ben Cooksley]

On Tue, Mar 25, 2014 at 12:37 AM, Vishesh Handa  wrote:
> On Monday, March 24, 2014 06:59:24 PM Ben Cooksley wrote:
>>
>> Baloo developers, please take a look at the failure in this log -
>> http://build.kde.org/view/FAILED/job/baloo_stable/80/console. When
>> referencing projects outside your own, it is imperative the correct
>> include statements are used in the CMake logic.
>>
>
> I've pushed a commit. That should hopefully fix it.

Unfortunately it seems the build still fails -
http://build.kde.org/view/FAILED/job/baloo_stable/81/console
Please note that this is the stable build (KDE/4.13 branch).

Thanks for fixing the master branch though - all it's tests are now passing.

>
> Could you perhaps add some hook to email me about these failures? We don't
> have a dedicated mailing list for Baloo and I'm not sure if notifying kde-
> devel would be a good idea.

I've now configured it to send you emails for both the Baloo master
and stable builds.

>
> --
> Vishesh Handa

Thanks,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Problems found by the CI system

[Ben Cooksley]

Hi all,

It seems lately that people have been breaking builds and not fixing
the results, and some builds are extremely unreliable. It would be
appreciated if these could be fixed.

Frameworks folks, when pushing binary incompatible changes, please
ensure you push them to the frameworks in the correct order, and wait
for builds to complete before moving on to the next one.

I've now fixed, by issuing rebuilds, two recent Binary Compatability
breaches which caused kde-runtime among others to fail to build.

Bindings people, please investigate the failures in smokegen. This
tool is extremely unreliable in the CI environment and has failed many
times previously. It is currently causing smokekde to fail to build,
which in turn blocks perlkde, korundum and kimono.

If you need a backtrace, please let me know. From what I can tell,
this tool is incompatible with a Qt built in debug mode (ie. with
assertions enabled).

Baloo developers, please take a look at the failure in this log -
http://build.kde.org/view/FAILED/job/baloo_stable/80/console. When
referencing projects outside your own, it is imperative the correct
include statements are used in the CMake logic.

KDE Workspace devels, please do not attempt to host a framework within
a repository which then uses this framework. This prevents people
without a previous installation of it from being able to build it - an
environment the CI system provides. Packagers will be unable to build
it as well.

Thanks,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KActivities/master is now KF5/Qt5

[Ben Cooksley]

On Fri, Feb 28, 2014 at 9:50 PM, Ivan Čukić  wrote:
> Hi all,
>
> Now that the 4.13 has been branched out, the master branch of KActivities is
> for Qt5/KF5 development.
>
> I have updated the branch name in kf5-frameworks-build-include (I guess
> David had something else in mind, so I'm CC-ing him even though he is a
> member of every list I'm sending this to :) )
>
> The only things left to do are (I'm looking at Ben or Albert with hope in my
> eyes):
>  - update kde:kde-build-metadata - I don't dare to do this myself. It should
> use KDE/4.13 branch for Qt4, and master for Qt5.
>  - blacklist and delete the frameworks branch

The metadata has now been sorted.

>
> Cheerio,
> Ivan

Regards,
Ben

>
> --
> While you were hanging yourself on someone else's words
> Dying to believe in what you heard
> I was staring straight into the shining sun
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasma Mediacenter CI failure

[Ben Cooksley]

Hello all,

As nobody seems to have noticed, PMC has now been failing to build on
the CI system for some time.

Can someone please take a look?

The latest build failure log is at
http://build.kde.org/view/FAILED/job/plasma-mediacenter_master/217/consoleText

Thanks,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Setup build of kdeplasma-addons on CI system

[Ben Cooksley]

On Sat, Dec 28, 2013 at 5:36 PM, Bhushan Shah  wrote:
> Hello!

Hi,

>
> On Sat, Dec 28, 2013 at 10:05 AM, Ben Cooksley  wrote:
>>
>> Please see http://build.kde.org/job/kdeplasma-addons_master/ and
>> http://build.kde.org/job/kdeplasma-addons_stable/
>
> Sorry I should have mentioned about frameworks branch.

Please file a ticket at https://sysadmin.kde.org/tickets/ and we can
sort this out.

>
> Thanks!

Thanks,
Ben

>
> --
> Bhushan Shah
>
> http://bhush9.github.io
> IRC Nick : bshah on Freenode
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Setup build of kdeplasma-addons on CI system

[Ben Cooksley]

On Sat, Dec 28, 2013 at 5:33 PM, Bhushan Shah  wrote:
> Hello!
>
> Currently I am porting stuffs in kdeplasma-addons but as I see there
> is no build of kdeplasma-addons on CI system. If someone can setup it
> it will be very good. I know there are not much things in repo but it
> is moving forward. ;)

Please see http://build.kde.org/job/kdeplasma-addons_master/ and
http://build.kde.org/job/kdeplasma-addons_stable/

>
> Thanks!

Regards,
Ben

>
> --
> Bhushan Shah
>
> http://bhush9.github.io
> IRC Nick : bshah on Freenode
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Oxygen in QtQuickControls

[Ben Cooksley]

On Wed, Dec 4, 2013 at 4:09 AM, Yichao Yu  wrote:

> On Tue, Dec 3, 2013 at 10:06 AM, Yichao Yu  wrote:
> > On Tue, Dec 3, 2013 at 3:06 AM, Martin Klapetek
> >  wrote:
> >> On Tue, Dec 3, 2013 at 5:18 AM, Yichao Yu  wrote:
> >>>
> >>> On Mon, Dec 2, 2013 at 10:55 AM, Sebastian Kügler 
> wrote:
> >>> > On Monday, December 02, 2013 15:30:26 David Edmundson wrote:
> >>> >> I'm working to fix using QtQuickControls with Oxygen.
> >>> >>
> >>> >> The current state is far from perfect. Some of it is quirks in
> Oxygen
> >>> >> doing tricks that don't work here and some are just plain bugs in Qt
> >>> >> Controls desktop theme.
> >>> >>
> >>> >> I have a wiki page where I'm tracking progress of each component
> >>> >> http://community.kde.org/Plasma/OxygenQmlControls
> >>> >>
> >>> >> Ping me (d_ed) if you want to help out or have any questions.
> >>>
> >>> Thanks for pointing this out. I would like to test all these but do
> >>> you know if there are any "complete" example of QtQuick applications
> >>> that I can play with (sth like oxygen-demo).
> >>>
> >>> P.S. I will be mostly working on improving QtQuick support in QtCurve
> >>> and I hope you will not be too unhappy if I steal some of your work
> >>> for QtCurve ;-).
> >>
> >>
> >> You can use kde:scratch/davidedmundson/componentgallery - and run it
> with
> >> qmlscene main.qml. You can test different styles by passing -style, eg.
> >> qmlscene -style fusion main.qml
>
> BTW, it seems that I cannot clone this from anongit but its fine from
> quickgit. Is this normal or am I missing something?
>
> URLs I was using are:
> git://quickgit.kde.org/scratch/davidedmundson/componentgallery.git
> git://anongit.kde.org/scratch/davidedmundson/componentgallery.git (and
> this is the one listed on quickgit's web interface of this repo.)
>

The anongit network has now been checked over. One mirror as it turns out
was not updating correctly, which has now been repaired.
Please retry - it should now succeed.


>
> >
> > Thank you!! That's very helpful!!
> > And yeah... a number of things are broken in QtCurve as well..
> > especially those related to background, frames and masks...
> >
> > Yicao Yu
> >
> >>
> >> Cheers
> >> --
> >> Martin Klapetek | KDE Developer
> >>
> >> ___
> >> Plasma-devel mailing list
> >> Plasma-devel@kde.org
> >> https://mail.kde.org/mailman/listinfo/plasma-devel
> >>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>

Thanks,
Ben Cooksley
KDE Sysadmin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: kde-workspace git broken ?

[Ben Cooksley]

Hi everyone,

I have now force pushed kde-workspace to return it to a valid state.
 + 09ea308...008ac5e 008ac5efabfb99f04813e5dad29c2d0a92d13fc5 -> master
(forced update)
 + 8105121...f1b57a9 f1b57a9ca9193fb94d985b5cc6d739866c5c59d2 -> KDE/4.11
(forced update)

I have also blacklisted the following defective commits from re-entering
the repository:
- 8105121937a9d4727e6c8e4473f45f4cf0692175
- 092e385f018c5aea7996babb7b2c4d317e71a085
- 09ea308ab55505efe7aeaebcd4aef6292cd884e6

Any work after those commits has been discarded, and will need to be
reapplied by cherry-picking. Do NOT attempt to rebase or merge your work
across, you will simply reintroduce the defective commits.

In terms of a hook to block this - unfortunately while merges are
detectable, reverts are not, they simply look like ordinary commits.
Anything we add to attempt to block this would be very fragile and
vulnerable to failure (ie. looking in the commit message for "Revert" and
"merge")

Thanks,
Ben Cooksley
KDE Sysadmin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Use kde-runtime[frameworks]!

[Ben Cooksley]

On Fri, Nov 8, 2013 at 3:45 AM, Sebastian Kügler  wrote:

> Hey all,
>

Hi Sebas,


>
> In order to achieve more consistency across repositories, we've renamed the
> branch frameworks-scratch to frameworks in kde-runtime. Please do not push
> to
> frameworks-scratch anymore. (Ben, could you block this branch, if it hasn't
> already happened?).
>
> So, all commits go into the frameworks branch.
>

I have now blacklisted the 'frameworks-scratch' branch for the repositories
kdelibs, kde-runtime, kde-workspace and plasmate.
If there are any other repositories where frameworks development is taking
place, please let me know so the blacklisting rule can be extended to them
as well.

If for some reason that branch name still exists in one of the above
repositories, please let me know - only Sysadmin will be able to remove
them.


>
> Cheers,
> --
> sebas
>

Thanks,
Ben


>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Projects adding dependencies without clear indication of requirements

[Ben Cooksley]

On Tue, Oct 22, 2013 at 6:59 PM, Ivan Čukić  wrote:

> The dependency is kactivities/frameworks branch which does not depend on
> nepomuk-core nor soprano.
>
> Deps for kactivities are:
>
> -- The following OPTIONAL packages have been found:
>
>  * KDBusAddons
>  * KWindowSystem
>  * KCoreAddons
>  * KConfig
>
> -- The following REQUIRED packages have been found:
>
>  * ECM (required version >= 0.0.8)
>  * Qt5Sql
>  * KF5
>  * Qt5Test
>  * Qt5Core
>  * Qt5DBus
>  * Qt5
>
>
> Cheers,
> Ivan
>


Thanks for the clarification - this has now been resolved, and the build of
plasma-framework has now been fixed.

Cheers,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Projects adding dependencies without clear indication of requirements

[Ben Cooksley]

Hi all,

It seems that plasma-framework (a dependency of kde-workspace master) has
now added a dependency on kactivities. However kactivities itself depends
on nepomuk-core and soprano - and there is no frameworks / Qt 5 branch for
either of those.

How do we proceed here?

I'd appreciate it if more notice was given of these changes - and time was
given for the CI system to be prepared in advance of the changes going in.

Regards,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Can we drop kcontrol/workspaceoptions?

[Ben Cooksley]

On 21 Oct 2013 23:56, "Sebastian Kügler"  wrote:
>
> On Friday, October 18, 2013 16:45:29 Marco Martin wrote:
> > On Fri, Oct 18, 2013 at 3:19 PM, Martin Graesslin 
> wrote:
> > > is a global switch to enable and disable tooltips: also partially
managed
> > > automatically by the shell switching, but needs to be configurable by
the
> > > user somewhere
> >
> > does it? Is it really a valid usecase to disable tooltips? That would
be an
> >  interesting thing to see how many users changed that option at all...
> >
> > as far I remember, it was added due a quite big demand, several users
hate
> > tooltips like nothing else. I'm ok for trying to remove the option, but
may
> > be an haters gonna hate type of thing...
>
> I've actually disabled the tooltips, because they obstructed windows. I
only
> did that on my laptop, so it's not universal at least for me. I wouldn't
die
> without this option, but I still did find it pretty useful at a time in
the
> past. Just one small data point.

There have been a number of users (on the forums) who also had to turn off
the tooltips for various reasons, so I would definitely recommend keeping
this option.

> --
> sebas

Regards,
Ben

>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 113139: Try to export include targets for Plasma as well

[Ben Cooksley]

> On Oct. 7, 2013, 9:35 a.m., Stephen Kelly wrote:
> > src/plasma/CMakeLists.txt, line 173
> > <http://git.reviewboard.kde.org/r/113139/diff/1/?file=199605#file199605line173>
> >
> > The if-else shouldn't be needed. INSTALL_INTERFACE should already check 
> > if ${INCLUDE_INSTALL_DIR} is absolute.
> 
> Ben Cooksley wrote:
> I copied this code from KCoreAddons in kdelibs[frameworks]. Shall I 
> correct it there as well?
> 
> Stephen Kelly wrote:
> It appears in several other frameworks too. Actually your snippet is 
> needed until CMake 2.8.12. I'll remove it from them all when kde requires 
> that version.

Okay. I removed the IS_ABSOLUTE part when I committed though, so that might 
need to be adjusted back in then.


- Ben


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


On Oct. 7, 2013, 10:48 a.m., Ben Cooksley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113139/
> ---
> 
> (Updated Oct. 7, 2013, 10:48 a.m.)
> 
> 
> Review request for kdelibs, Plasma and Stephen Kelly.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Add include targets for KF5::plasma, which will hopefully contribute towards 
> fixing the kde-workspace[master] build on build.kde.org.
> Unfortunately it isn't entirely successful as it seems camelcase headers are 
> installed by KF5::plasma into include/KDE/Plasma/ but it should be a start...
> 
> 
> Diffs
> -
> 
>   src/plasma/CMakeLists.txt b21fd7b 
> 
> Diff: http://git.reviewboard.kde.org/r/113139/diff/
> 
> 
> Testing
> ---
> 
> In place on CI build system. Proper include path now given to compiler.
> 
> 
> Thanks,
> 
> Ben Cooksley
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 113139: Try to export include targets for Plasma as well

[Ben Cooksley]

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

(Updated Oct. 7, 2013, 10:48 a.m.)


Status
--

This change has been marked as submitted.


Review request for kdelibs, Plasma and Stephen Kelly.


Repository: plasma-framework


Description
---

Add include targets for KF5::plasma, which will hopefully contribute towards 
fixing the kde-workspace[master] build on build.kde.org.
Unfortunately it isn't entirely successful as it seems camelcase headers are 
installed by KF5::plasma into include/KDE/Plasma/ but it should be a start...


Diffs
-

  src/plasma/CMakeLists.txt b21fd7b 

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


Testing
---

In place on CI build system. Proper include path now given to compiler.


Thanks,

Ben Cooksley

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 113139: Try to export include targets for Plasma as well

[Ben Cooksley]

> On Oct. 7, 2013, 9:35 a.m., Stephen Kelly wrote:
> > Which kde-workspace branch should I use to test this?

Master branch.


> On Oct. 7, 2013, 9:35 a.m., Stephen Kelly wrote:
> > src/plasma/CMakeLists.txt, line 173
> > <http://git.reviewboard.kde.org/r/113139/diff/1/?file=199605#file199605line173>
> >
> > The if-else shouldn't be needed. INSTALL_INTERFACE should already check 
> > if ${INCLUDE_INSTALL_DIR} is absolute.

I copied this code from KCoreAddons in kdelibs[frameworks]. Shall I correct it 
there as well?


- Ben


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


On Oct. 7, 2013, 8:13 a.m., Ben Cooksley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113139/
> ---
> 
> (Updated Oct. 7, 2013, 8:13 a.m.)
> 
> 
> Review request for kdelibs, Plasma and Stephen Kelly.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Add include targets for KF5::plasma, which will hopefully contribute towards 
> fixing the kde-workspace[master] build on build.kde.org.
> Unfortunately it isn't entirely successful as it seems camelcase headers are 
> installed by KF5::plasma into include/KDE/Plasma/ but it should be a start...
> 
> 
> Diffs
> -
> 
>   src/plasma/CMakeLists.txt b21fd7b 
> 
> Diff: http://git.reviewboard.kde.org/r/113139/diff/
> 
> 
> Testing
> ---
> 
> In place on CI build system. Proper include path now given to compiler.
> 
> 
> Thanks,
> 
> Ben Cooksley
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 113139: Try to export include targets for Plasma as well

[Ben Cooksley]

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

Review request for kdelibs, Plasma and Stephen Kelly.


Repository: plasma-framework


Description
---

Add include targets for KF5::plasma, which will hopefully contribute towards 
fixing the kde-workspace[master] build on build.kde.org.
Unfortunately it isn't entirely successful as it seems camelcase headers are 
installed by KF5::plasma into include/KDE/Plasma/ but it should be a start...


Diffs
-

  src/plasma/CMakeLists.txt b21fd7b 

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


Testing
---

In place on CI build system. Proper include path now given to compiler.


Thanks,

Ben Cooksley

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Force push to plasma-framework

[Ben Cooksley]

Hi everyone,

Due to an unfortunate accident involving git merge, several branches
of the plasma-framework repository were rendered unusable.

To correct this, two branches have been forcibly rewound. They are:
- master: now at ea1b637
- ivan/shell-switching: now at f8c2ff5.

The following commits have also been blacklisted from entering the repository:
- 89894b9ce0347204b7835d476a11ae24ff77ed5c
- a793df3c7473b25879491163d622acd988c00a5b
- fbb2e749aeaeca987e901e2f0b8046c9f12b578b
- 1fc1fda8331254b01f752fb04a8575b051543fb5
- f68ee1a764513db268644365c7879d3bc9f942bd

If you have any of the above commits in your current checked out
branch, you will need to hard reset it to the upstream version of that
branch before continuing.

Any commits which you have not yet pushed will need to be cherry
picked to the reset branches, or reapplied manually. Do not attempt to
rebase your local branch to correct this under any circumstances.

Regards,
Ben Cooksley
KDE Sysadmin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 110626: Overhaul sunxi kickstart generation into a generic way

[Ben Cooksley]

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

(Updated Aug. 15, 2013, 10:41 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma and Marco Martin.


Description
---

Also made some clean-ups and changed the adaptation repo

kickstart file generated via 'mer-kickstarter -e . -c 
releases/plasma-active-4.yaml -o plasma-active' could be found here (renamed):

ftp://5.9.162.110/plasma-active/coby/tablet/MID7042/mer/stable/armv7hl/weekly/plasma-active-coby-tablet-MID7042-mer-stable-armv7hl-weekly-20130523-2327.ks


Diffs
-

  adaptations/sunxi-generic.yaml PRE-CREATION 
  adaptations/sunxi.yaml d6483c8 
  base.yaml 58f8f79 
  generic/repos.yaml 245b7b4 
  scripts/sunxi-generic-copy-boot-scr.post PRE-CREATION 
  scripts/sunxi-generic-feed-some-modules.post PRE-CREATION 
  scripts/sunxi-remove-swap-from-fstab-workaround.post PRE-CREATION 
  scripts/sunxi.partition 200bf5d 
  scripts/sunxi.post dbac4fa 

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


Testing
---


Thanks,

Maurice de la Ferté

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Media Center build failure

[Ben Cooksley]

On Mon, Jul 8, 2013 at 7:00 AM, Sinny Kumari  wrote:
> Hi,

HI Sinny,

>
> http://commits.kde.org/plasma-mediacenter/1176e15af7e07f47eeb8991b42ba72fa4b383d52
> should fix build failure now. Please let me know if it still fails

Thanks, I can confirm that has fixed the build.

>
> Thanks

Regards,
Ben

>
>
> On Sun, Jul 7, 2013 at 4:24 PM, Ben Cooksley  wrote:
>>
>> Hi all,
>>
>> It appears that since commit 58e32d0979920b2b6b03f9b8f91a68dc4f88e644
>> it is no longer possible for Jenkins (CI) to build plasma-mediacenter.
>>
>> A log of the error can be found at
>>
>> http://build.kde.org/view/FAILED/job/plasma-mediacenter_master/82/consoleText
>>
>> I'd appreciate it if someone could take a look - i'm not sure of the
>> nature of this build failure.
>>
>> Thanks,
>> Ben
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
>
>
> --
> http://www.sinny.in
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasma Media Center build failure

[Ben Cooksley]

Hi all,

It appears that since commit 58e32d0979920b2b6b03f9b8f91a68dc4f88e644
it is no longer possible for Jenkins (CI) to build plasma-mediacenter.

A log of the error can be found at
http://build.kde.org/view/FAILED/job/plasma-mediacenter_master/82/consoleText

I'd appreciate it if someone could take a look - i'm not sure of the
nature of this build failure.

Thanks,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Keyboard detection and a test request

[Ben Cooksley]

On Fri, Jun 21, 2013 at 10:01 PM, Ivan Čukić  wrote:
> Hi all,

Hi Ivan,

>
> I (think) I'm now properly detecting regular mice, touch-pads and touch-
> screens, based on some X properties of those.
>
> It would be very nice if people with touch-screens and touch-pads would do the
> following test - run xinput on your device (if not installed, you can ssh -X
> to a machine that has xinput)
>
> Take the id of the touch* device, and do this (replace 4 with an actual id)
> xinput list-props 4
>
> Post the output to pastebin and send me the output (if I pong you back on IRC,
> you send me the link there)

Here you go: http://paste.kde.org/780500/
Appears to be an Elantech touchpad, with Synaptics properties - as
found in my Asus laptop.

>
> --
>
> The keyboard is a problem.
>
> X always reports a keyboard present - the 'AT Translated Set 2 keyboard'
> device. The second thing is that it has no properties to distinguish a real
> keyboard from special button-keyboard devices like 'Sleep Button' etc.
>
> The approach that I am considering is the following - have a platform config
> (following the current approach we have in PA) file that will say whether the
> device has a keyboard by default. This will tell me whether the 'AT Transl...'
> is a real keyboard or not.
>
> The second step is ugly and a hopefully working heuristic that makes me laugh
> - if the name of the device contains the word 'Keyboard', then it is a
> keyboard. Otherwise, we'll need some kind of whitelist/blacklist system.
>
> It could probably be done via libusb or similar, by detecting whether
> something has Keyboard bInterfaceProtocol, but then again, a usb numpad would
> also (I guess, don't have one of those) use the same protocol.
>
> Cheerio,
> Ivan

Cheers,
Ben

>
>
>
> --
> You know, there are many people in the country today who,
> through no fault of their own, are sane. Some of them were born sane.
> Some of them became sane later in their lives...
>   -- Monty Python's Flying Circus
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 110843: Ensure we actually have Qwt 5 by looking for a header present only in Qwt 5

[Ben Cooksley]

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

Review request for Build System and Plasma.


Description
---

This fixes the build failures on Jenkins by looking for a header specific to 
Qwt 5, instead of a general Qwt header.


Diffs
-

  applets/kdeobservatory/cmake/modules/FindQwt.cmake 7045388 

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


Testing
---


Thanks,

Ben Cooksley

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: kdeobservatory seems to be missing a qwt min version check

[Ben Cooksley]

On Tue, Jun 4, 2013 at 12:22 PM, Sandro Andrade  wrote:
> Hi there,

Hi Sandro,

>
> That's actually intended to be moved to unmaintained, sorry for
> haven't done it yet, I'm in the last months of my thesis :( - or maybe
> :)
> Not sure if I can do that at this time in release schedule. I can fix
> it to use Qwt 6.1 or fully move it to maintained.

As the observatory plugin was shipped as part of KDE Plasma Addons in
KDE 4.9, we can't exactly remove it from stable - although this would
be an option for master (and is probably the best thing to do I
think).

I would suggest patching the build system to check the Qwt version to
ensure it is 6.0.x in the interim at least. Based on the message
"Found Qwt version 6.1.1 linked to Qt4" CMake seems to know which
version of Qwt it has found.

>
> What do you guys prefer ?
> --
> Sandro

Thanks,
Ben

>
>
> On Mon, Jun 3, 2013 at 5:22 PM, Ben Cooksley  wrote:
>> On Tue, Jun 4, 2013 at 8:09 AM, Albert Astals Cid  wrote:
>>> Hi guys, can anyone please have a look at
>>> kdeplasma-addons/applets/kdeobservatory and make sure it requires the qwt 
>>> min
>>> version it needs?
>>>
>>> The build is currently failing at build.kde.org (probably a too old qwt
>>> installed) instead of just skipping the applet from being built.
>>
>> I suspect it is actually a case of a too new Qwt being installed.
>> We recently upgraded from Qwt 6.0 to 6.1, which was necessary to allow
>> the smokeqt bindings to compile successfully.
>>
>>>
>>> http://build.kde.org/view/All/job/kdeplasma-addons_master/212/console
>>>
>>> Cheers,
>>>   Albert
>>
>> Regards,
>> Ben
>>
>>>
>>> P.S: I'm *not* subscribed to plasma-devel so CC me if you want to keep me in
>>> the loop
>>> ___
>>> Plasma-devel mailing list
>>> Plasma-devel@kde.org
>>> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: kdeobservatory seems to be missing a qwt min version check

[Ben Cooksley]

On Tue, Jun 4, 2013 at 8:09 AM, Albert Astals Cid  wrote:
> Hi guys, can anyone please have a look at
> kdeplasma-addons/applets/kdeobservatory and make sure it requires the qwt min
> version it needs?
>
> The build is currently failing at build.kde.org (probably a too old qwt
> installed) instead of just skipping the applet from being built.

I suspect it is actually a case of a too new Qwt being installed.
We recently upgraded from Qwt 6.0 to 6.1, which was necessary to allow
the smokeqt bindings to compile successfully.

>
> http://build.kde.org/view/All/job/kdeplasma-addons_master/212/console
>
> Cheers,
>   Albert

Regards,
Ben

>
> P.S: I'm *not* subscribed to plasma-devel so CC me if you want to keep me in
> the loop
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Calendar plasmoid

[Ben Cooksley]

On Jun 2, 2013 5:33 AM, "Antonis Tsiapaliokas"  wrote:
>
> Hello,
>
> On Sat, Jun 1, 2013 at 3:38 PM, Heena Mahour  wrote:
>>
>> Hey ,
>> I am having some problem here :P
>> 1. I tried to build framework refering :
http://community.kde.org/Frameworks/Building but I am getting a few error
http://pastebin.com/raw.php?i=6p1jbxqc
>
>
> 1) As regards the qt build error you could try the following
>
> It is recommended to build the Qt5 into the build subfolder.
> So instead of cd ~/qt5 && ./configure parameters
> you have to do the following
> cd ~/qt5 && mkdir build && cd build && ../configure parameters
>
> As regards the error, i don't really know what is wrong... I guess a
clean clone and ./init-repository will work.
>
> 2)For the git error
>
> kde has two type of git mirrors.
> 1)g...@git.kde.org:package, ex g...@git.kde.org:kdelibs (that works always
but you need to have a kde developer account)
> 2)git://anongit.kde.org/package, ex git://anongit.kde.org/kdelibs (that
doesn't require any kind of access)
>
> Sometimes the anongit server is down. So you where a bit unlucky. Try
again and you will not have that issue...

Please report faults in the anongit network to sysadmin, so we can
investigate and correct the issue. To my knowledge, all active anongit
servers are currentlky functioning properly.

>
> Regards,
> Antonis

Regards,
Ben

>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 110633: Don't report crashes if version is disabled in Bugzilla

[Ben Cooksley]

> On May 24, 2013, 9:44 p.m., Jekyll Wu wrote:
> > Bugzilla itself (since 4.2.5) already rejects any attempt against disabled 
> > versions. So even without this patch, DrKonqi users won't be able to create 
> > crash report against disabled versions in the end. From developers POV, you 
> > don't need to worry about that.
> > 
> > The problem is usability for users. I'm not sure this reused error dialog 
> > is more informative than the existing one in 
> > https://bugs.kde.org/attachment.cgi?id=78600&action=edit. So I'm against 
> > this patch in its current simple form.
> > 
> > As said in [1][2], I'm working on a patch for the usability improvement and 
> > plan to make it into 4.11. I will create a review request today or 
> > tomorrow. 
> > 
> > 
> > [1] https://bugs.kde.org/show_bug.cgi?id=315073#c3
> > [2] https://bugs.kde.org/show_bug.cgi?id=318769#c1
> 
> Martin Gräßlin wrote:
> > Bugzilla itself (since 4.2.5) already rejects any attempt against 
> disabled versions.
> Bugzilla does blcok, but DrKonqi still reports them as "unknown" version. 
> I know it because I see the crash reports coming in
> 
> Martin Gräßlin wrote:
> > So I'm against this patch in its current simple form.
> Are you also against into backporting it to prevent that we stop getting 
> useless crash reports? I worked on this for fixing a real world problem. Just 
> look at: 
> 
> https://bugs.kde.org/buglist.cgi?list_id=661927&bug_severity=crash&chfieldto=Now&query_format=advanced&chfield=[Bug%20creation]&chfieldfrom=2013-01-01&version=unspecified&longdesc=kwin%20%284.8&product=kwin&longdesc_type=allwordssubstr
> 
> All crashes reported this year against KWin 4.8.
> 
> Yes the dialog might not be best, but I cannot change it because it's in 
> string freeze. I agree that for 4.11 something better should be done, but 
> this is more for 4.10 and older (especially older).
> 
> Ben Cooksley wrote:
> Perhaps it might be worth requesting a string freeze exemption here?
> 
> Martin Gräßlin wrote:
> > Perhaps it might be worth requesting a string freeze exemption here?
> We would need that from each and every distribution. It doesn't help that 
> KDE did the freeze exception and Debian is then not accepting the patch 
> because it violates their policy.
> 
> Jekyll Wu wrote:
> Those reports are all from KDE SC 4.8.5, where kwin version (using 
> KDE_VERSION_STRING) was in the strange form of "4.8.5 (4.8.5)" . For some 
> strange reason I'm still not aware of, bugs.kde.org fails to reject reports 
> with that kind of version (probably due the space in the version) as it 
> should have. I'm well aware of those reports which shouldn't have been 
> accepted at the first place (since I'm subscribed to kde-bugs-dist@), but I 
> haven't got the time to do a good investigation. Anyway, those "escaped" 
> crash reports are definitely the race cases.
> 
> 
> I understand you are annoyed by those kwin crash reports from 4.8.5, but 
> backporting this simple patch won't help you much: the DrKonqi from KDE SC 
> 4.8.x simply don't contain the code of fetching version info from 
> bugs.kde.org through the Product.get webservice API, so backing this simple 
> patch to 4.8.x is useless.  I added those code not long time ago, as the 
> necessary base of my final goal of preventing outdated crash reports.
> 
> So if your goal is not seeing those kwin 4.8.5 crash reports anymore, 
> there are two quick solutions: 
>
>1. apply this simple drkonqi patch to 4.10.x, then ask distribution 
> packagers(I'm think of Debian Stable) to ship DrKonqi from KDE SC 4.10.4 
> together with other components from KDE SC 4.8.4/5. I'm not sure how 
> distribution packagers will think of this kind of mixture.
>
>2. prepare a one-line patch to make kwin from KDE 4.8.5 use version 
> "4.8.5" explicitly,  instead of using KDE_VERSION_STRING. That way, 
> bugs.kde.org itself will reject those crash reports as it has done for 
> 4.9.{0,1,2,3} . Then ask distribution packers to apply this kwin one-line 
> patch. I think this is more acceptable for distribution packagers. Or maybe 
> that one line patch should be created against kdelibs, changing 
> KDE_VERSION_STRING to the plain "4.8.5" ?
>
> 
> Martin Gräßlin wrote:
> > Or maybe that one line patch should be created against kdelibs, 
> changing KDE_VERSION_STRING to the plain "4.8.5" ?
> That's

Re: Review Request 110633: Don't report crashes if version is disabled in Bugzilla

[Ben Cooksley]

> On May 24, 2013, 9:44 p.m., Jekyll Wu wrote:
> > Bugzilla itself (since 4.2.5) already rejects any attempt against disabled 
> > versions. So even without this patch, DrKonqi users won't be able to create 
> > crash report against disabled versions in the end. From developers POV, you 
> > don't need to worry about that.
> > 
> > The problem is usability for users. I'm not sure this reused error dialog 
> > is more informative than the existing one in 
> > https://bugs.kde.org/attachment.cgi?id=78600&action=edit. So I'm against 
> > this patch in its current simple form.
> > 
> > As said in [1][2], I'm working on a patch for the usability improvement and 
> > plan to make it into 4.11. I will create a review request today or 
> > tomorrow. 
> > 
> > 
> > [1] https://bugs.kde.org/show_bug.cgi?id=315073#c3
> > [2] https://bugs.kde.org/show_bug.cgi?id=318769#c1
> 
> Martin Gräßlin wrote:
> > Bugzilla itself (since 4.2.5) already rejects any attempt against 
> disabled versions.
> Bugzilla does blcok, but DrKonqi still reports them as "unknown" version. 
> I know it because I see the crash reports coming in
> 
> Martin Gräßlin wrote:
> > So I'm against this patch in its current simple form.
> Are you also against into backporting it to prevent that we stop getting 
> useless crash reports? I worked on this for fixing a real world problem. Just 
> look at: 
> 
> https://bugs.kde.org/buglist.cgi?list_id=661927&bug_severity=crash&chfieldto=Now&query_format=advanced&chfield=[Bug%20creation]&chfieldfrom=2013-01-01&version=unspecified&longdesc=kwin%20%284.8&product=kwin&longdesc_type=allwordssubstr
> 
> All crashes reported this year against KWin 4.8.
> 
> Yes the dialog might not be best, but I cannot change it because it's in 
> string freeze. I agree that for 4.11 something better should be done, but 
> this is more for 4.10 and older (especially older).
> 
> Ben Cooksley wrote:
> Perhaps it might be worth requesting a string freeze exemption here?
> 
> Martin Gräßlin wrote:
> > Perhaps it might be worth requesting a string freeze exemption here?
> We would need that from each and every distribution. It doesn't help that 
> KDE did the freeze exception and Debian is then not accepting the patch 
> because it violates their policy.
> 
> Jekyll Wu wrote:
> Those reports are all from KDE SC 4.8.5, where kwin version (using 
> KDE_VERSION_STRING) was in the strange form of "4.8.5 (4.8.5)" . For some 
> strange reason I'm still not aware of, bugs.kde.org fails to reject reports 
> with that kind of version (probably due the space in the version) as it 
> should have. I'm well aware of those reports which shouldn't have been 
> accepted at the first place (since I'm subscribed to kde-bugs-dist@), but I 
> haven't got the time to do a good investigation. Anyway, those "escaped" 
> crash reports are definitely the race cases.
> 
> 
> I understand you are annoyed by those kwin crash reports from 4.8.5, but 
> backporting this simple patch won't help you much: the DrKonqi from KDE SC 
> 4.8.x simply don't contain the code of fetching version info from 
> bugs.kde.org through the Product.get webservice API, so backing this simple 
> patch to 4.8.x is useless.  I added those code not long time ago, as the 
> necessary base of my final goal of preventing outdated crash reports.
> 
> So if your goal is not seeing those kwin 4.8.5 crash reports anymore, 
> there are two quick solutions: 
>
>1. apply this simple drkonqi patch to 4.10.x, then ask distribution 
> packagers(I'm think of Debian Stable) to ship DrKonqi from KDE SC 4.10.4 
> together with other components from KDE SC 4.8.4/5. I'm not sure how 
> distribution packagers will think of this kind of mixture.
>
>2. prepare a one-line patch to make kwin from KDE 4.8.5 use version 
> "4.8.5" explicitly,  instead of using KDE_VERSION_STRING. That way, 
> bugs.kde.org itself will reject those crash reports as it has done for 
> 4.9.{0,1,2,3} . Then ask distribution packers to apply this kwin one-line 
> patch. I think this is more acceptable for distribution packagers. Or maybe 
> that one line patch should be created against kdelibs, changing 
> KDE_VERSION_STRING to the plain "4.8.5" ?
>
> 
> Martin Gräßlin wrote:
> > Or maybe that one line patch should be created against kdelibs, 
> changing KDE_VERSION_STRING to the plain "4.8.5" ?
> That's

Re: Review Request 110633: Don't report crashes if version is disabled in Bugzilla

[Ben Cooksley]

> On May 24, 2013, 9:44 p.m., Jekyll Wu wrote:
> > Bugzilla itself (since 4.2.5) already rejects any attempt against disabled 
> > versions. So even without this patch, DrKonqi users won't be able to create 
> > crash report against disabled versions in the end. From developers POV, you 
> > don't need to worry about that.
> > 
> > The problem is usability for users. I'm not sure this reused error dialog 
> > is more informative than the existing one in 
> > https://bugs.kde.org/attachment.cgi?id=78600&action=edit. So I'm against 
> > this patch in its current simple form.
> > 
> > As said in [1][2], I'm working on a patch for the usability improvement and 
> > plan to make it into 4.11. I will create a review request today or 
> > tomorrow. 
> > 
> > 
> > [1] https://bugs.kde.org/show_bug.cgi?id=315073#c3
> > [2] https://bugs.kde.org/show_bug.cgi?id=318769#c1
> 
> Martin Gräßlin wrote:
> > Bugzilla itself (since 4.2.5) already rejects any attempt against 
> disabled versions.
> Bugzilla does blcok, but DrKonqi still reports them as "unknown" version. 
> I know it because I see the crash reports coming in
> 
> Martin Gräßlin wrote:
> > So I'm against this patch in its current simple form.
> Are you also against into backporting it to prevent that we stop getting 
> useless crash reports? I worked on this for fixing a real world problem. Just 
> look at: 
> 
> https://bugs.kde.org/buglist.cgi?list_id=661927&bug_severity=crash&chfieldto=Now&query_format=advanced&chfield=[Bug%20creation]&chfieldfrom=2013-01-01&version=unspecified&longdesc=kwin%20%284.8&product=kwin&longdesc_type=allwordssubstr
> 
> All crashes reported this year against KWin 4.8.
> 
> Yes the dialog might not be best, but I cannot change it because it's in 
> string freeze. I agree that for 4.11 something better should be done, but 
> this is more for 4.10 and older (especially older).

Perhaps it might be worth requesting a string freeze exemption here?


- Ben


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


On May 24, 2013, 2:54 p.m., Martin Gräßlin wrote:
> 
> -------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/110633/
> ---
> 
> (Updated May 24, 2013, 2:54 p.m.)
> 
> 
> Review request for KDE Runtime, Plasma, Ben Cooksley, and Myriam 
> Schweingruber.
> 
> 
> Description
> ---
> 
> Bugzilla provides a feature to disable versions. This means that the 
> developers do not want to have further reports for this version. Any crash 
> report is by that not helpful any more. So let's just disable reporting 
> crashes for such bugs.
> 
> If this change gets accepted I intend to backport it to 4.10 and to inform 
> kde-packagers about it to ship it as an update to *all* version they support. 
> This would automatically prevent most duplicates report we get e.g. for KWin.
> 
> 
> Diffs
> -
> 
>   drkonqi/reportinterface.cpp 4190c40 
> 
> Diff: http://git.reviewboard.kde.org/r/110633/diff/
> 
> 
> Testing
> ---
> 
> See https://bugs.kde.org/show_bug.cgi?id=320217 - the bug was created with 
> version 4.10.60. Afterward the version got disabled and DrKonqi doesn't allow 
> me to report crashes for this version anymore.
> 
> 
> File Attachments
> 
> 
> With it disabled
>   
> http://git.reviewboard.kde.org/media/uploaded/files/2013/05/24/drkonqi-disabled.png
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[plasma-mediacenter] /: Fix build on CI.

[Ben Cooksley]

Git commit caf55beb2be97aa722510c8a38d266319c2c390b by Ben Cooksley.
Committed on 25/05/2013 at 08:55.
Pushed by bcooksley into branch 'master'.

Fix build on CI.
CCMAIL: plasma-devel@kde.org

M  +7-0CMakeLists.txt
M  +0-2
browsingbackends/metadatabackends/metadatamusicbackend/CMakeLists.txt
M  +4-2libs/mediacenter/CMakeLists.txt

http://commits.kde.org/plasma-mediacenter/caf55beb2be97aa722510c8a38d266319c2c390b

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8b860d3..5a8929e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -3,11 +3,18 @@ project(MediaCenterComponents)
 find_package(KDE4 REQUIRED)
 include(KDE4Defaults)
 
+find_package(KDE4Workspace REQUIRED)
+find_package(NepomukCore REQUIRED)
+find_package(Soprano)
+
 add_definitions(${QT_DEFINITIONS} ${KDE4_DEFINITIONS})
 include_directories(
 ${CMAKE_CURRENT_SOURCE_DIR}
 ${CMAKE_BINARY_DIR}
 ${KDE4_INCLUDES}
+${KDE4WORKSPACE_INCLUDE_DIR}
+${NEPOMUK_CORE_INCLUDE_DIR}
+${SOPRANO_INCLUDE_DIR}
 libs/
 )
 
diff --git 
a/browsingbackends/metadatabackends/metadatamusicbackend/CMakeLists.txt 
b/browsingbackends/metadatabackends/metadatamusicbackend/CMakeLists.txt
index b7bc59c..4bf6f67 100644
--- a/browsingbackends/metadatabackends/metadatamusicbackend/CMakeLists.txt
+++ b/browsingbackends/metadatabackends/metadatamusicbackend/CMakeLists.txt
@@ -1,5 +1,3 @@
-find_package(NepomukCore REQUIRED)
-
 set(metadatamusicbackend_SRCS
 categoriesmodel.cpp
 ../abstractmetadatabackend.cpp
diff --git a/libs/mediacenter/CMakeLists.txt b/libs/mediacenter/CMakeLists.txt
index eb287c5..6ffd5de 100644
--- a/libs/mediacenter/CMakeLists.txt
+++ b/libs/mediacenter/CMakeLists.txt
@@ -1,6 +1,8 @@
-find_package(NepomukCore REQUIRED)
 find_package(Taglib REQUIRED)
-include_directories (${TAGLIB_INCLUDES})
+
+include_directories(
+${TAGLIB_INCLUDES}
+)
 
 set (plasmamediacenter_SRCS
 mediainfoserviceproxy.cpp
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Downtime Notification: Git and Subversion

[Ben Cooksley]

Hi all,

git.kde.org should now be online and operational again.

As the canonical copy of the repositories stored by it was corrupted
in certain parts, we have restored all repositories from another
system.
To the best of our knowledge no commits have been lost, however it is
still possible they were lost. In this case, please repush the
commits.

Please be aware that the anongit mirrors will need time to rebuild, as
will KDE Projects and Quickgit.
If you find any problems with git.kde.org, please inform us immediately.

Our apologies for the inconvenience, we will be analysing the causes
of this to avoid repeats in the future.

Regards,
Ben Cooksley
KDE Sysadmin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [frameworks] QML2_IMPORT_PATH now needed for Plasma imports

[Ben Cooksley]

On Wed, Feb 13, 2013 at 12:50 AM, Sebastian Kügler  wrote:
> Hi,
>
> I've just pushed a change to plasma-frameworks which introduces a change to
> the installation path for your QtQuick2 imports, moving it under
> $PREFIX/lib/qml basically. (They previously went into $PREFIX/qml, which is a
> bit ugly.) It also means you have to update extra-cmake-modules.
>
> This means, in order to make these imports found, you have to point your
> environment to it, for example:
>
> export QML2_IMPORT_PATH=$KF5/lib/qml

The CI system has now been updated to ensure this variable is set
appropriately for any combination of $prefix/{lib,lib32,lib64}/qml

>
> otherwise you'll get errors that plugins such as org.kde.plasma.core and
> org.kde.plasma.components can not be found.
>
> Matching patch to extra-cmake-modules has just gone in, updated docs on
> the wiki are next.
>
> (notmart: CC:ing you explicitely so you don't lose any hairs when suddenly
> your environment doesn't work, you get stale plugins, or simply not found
> plugins.)
>
> Cheers,
> --
> sebas

Regards,
Ben

>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> ___
> Kde-frameworks-devel mailing list
> kde-frameworks-de...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plans for SVN infrastructure shutdown

[Ben Cooksley]

On Fri, Feb 8, 2013 at 1:38 AM, Gilles Caulier  wrote:
> Hi all,

Hi Gilles,

>
> What's about user home dir hosted in SVN repository which must be moved
> somewhere is GIT.
>
> Typically, mine is here :
>
> http://websvn.kde.org/branches/work/~cgilles/

You should migrate those to repositories under your scratch namespace
on git.kde.org.

>
> Best
>
> Gilles Caulier

Regards,
Ben Cooksley
KDE Sysadmin

>
>
>
> 2013/2/7 Marco Martin 
>>
>> On Wednesday 02 January 2013, Nicolás Alvarez wrote:
>> > The initial draft of the SVN shutdown plan is available on the community
>> > wiki: http://community.kde.org/Sysadmin/SVNInfrastructureShutdown
>> >
>> > As you can see this is a long-term plan. None of this is written in
>> > stone; any feedback is welcome!
>>
>> Is this still the active plan?
>> in plasma we have some stuff into svn, kept here because git doesn't work
>> that
>> well, basically artwork:
>> kde-artwork
>> kde-wallpapers
>> kde-artwork-active
>>
>> all of that can be moved, but will probably be among most problematic
>> repositories that still have to be migrated.. suggestions for those?
>>
>> Cheers,
>> Marco Martin
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plans for SVN infrastructure shutdown

[Ben Cooksley]

On Fri, Feb 8, 2013 at 1:26 AM, Marco Martin  wrote:
> On Wednesday 02 January 2013, Nicolás Alvarez wrote:
>> The initial draft of the SVN shutdown plan is available on the community
>> wiki: http://community.kde.org/Sysadmin/SVNInfrastructureShutdown
>>
>> As you can see this is a long-term plan. None of this is written in
>> stone; any feedback is welcome!
>
> Is this still the active plan?
> in plasma we have some stuff into svn, kept here because git doesn't work that
> well, basically artwork:
> kde-artwork
> kde-wallpapers
> kde-artwork-active
>
> all of that can be moved, but will probably be among most problematic
> repositories that still have to be migrated.. suggestions for those?

At this time this is the current plan.

With regards to any and all binary data: watch this space. At this
time it is known that Git support for binary data is quite poor,
however any final decisions in regard to their future have not yet
been made (as support in Git could potentially improve..)

>
> Cheers,
> Marco Martin

Regards,
Ben Cooksley
KDE Sysadmin

> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDEREVIEW: share like connect and plasmate

[Ben Cooksley]

On Thu, Jan 31, 2013 at 12:47 PM, Aaron J. Seigo  wrote:
> On Thursday, January 31, 2013 10:43:29 Ben Cooksley wrote:
>> > as it has been mentioned plasmate is ready to go into the extragear.
>> > Can you move it to the extragear?
>>
>> Where precisely in Extragear is Plasmate
>
> SDK
>
>> and Share-Like-Connect headed?
>
> Base
>
> thanks :)

Both Plasmate and Share-Like-Connect have now been moved to the
appropriate locations.

>
> --
> Aaron J. Seigo

Regards,
Ben Cooksley
KDE Sysadmin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDEREVIEW: share like connect and plasmate

[Ben Cooksley]

On Wed, Jan 30, 2013 at 11:23 PM, Giorgos Tsiapaliokas
 wrote:
> Hello,

Hi Giorgos,

>
> as it has been mentioned plasmate is ready to go into the extragear.
> Can you move it to the extragear?

Where precisely in Extragear is Plasmate and Share-Like-Connect headed?
They are both overdue to be moved from KDE Review.

Note: Moves into and out of KDE Review must *always* be CC'ed to kde-core-devel.

On that note: any last objections?

>
> Regards,
> Giorgos

Regards,
Ben Cooksley
KDE Sysadmin

>
>
> --
> Giorgos Tsiapaliokas (terietor)
> KDE Developer
>
> terietor.gr
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: pruning branches in kde-workspace

[Ben Cooksley]

On Thu, Jan 31, 2013 at 12:42 AM, Aaron J. Seigo  wrote:
> hi all ..
>
> we have quite a few devel branches in kde-workspace, and i'd like to prune
> some of them. branches that i am unsure of are listed below.
>
> if they "belong" to you, please speak up (in this thread :) and note whether
> they should be removed, are ready for merging or are still used for
> development.

Just in case anyone is concerned about losing work that may be needed
later, all deleted branches will continue to live forever under
refs/backups/ in the Git repository (this applies to all repositories,
even those in scratch or clones on git.kde.org - and also covers when
a force push is performed)

>
> thanks :)
>
>   activitiesInTaskmanager
>   amourphiouskb
>   belem/Active/1.0
>   bettio/qml-calendar-gsoc
>   dafre/new-powerdevil
>   focus
>   help
>   hpereira/oxygen-shadows
>   ivan/activity-window-rule
>   kdm-plasma
>   kickoff-qml
>   ksmserver/qml-shutdowndlg
>   kwin-wayland
>   kwin/mart/tabboxFixes
>   libplasma2
>   login1-patch
>   master
>   multiscreenScreenlockFix
>   munknex/kio_soc
>   noKephal
>   oxygen/background-pixmap
>   oxygen/extended-splitters
>   plasma/bookmarksrunner-chrome-gulino
>   plasma/brummbq/digital-clock
>   plasma/dmitrya/systemtray-qml
>   plasma/iwesp/quicklaunch
>   plasma/keyboard_applet_svgtext/mart
>   plasma/luisgabriellima/pager-qml
>   plasma/mart/declarativeWidgetsExplorer
>   plasma/mart/notifications-qml
>   plasma/mart/wac-appletscript
>   plasma/sebas/desktop-qml
>   plasma/sreich/applet/hdd-activity
>   plasma/sreich/plasmasvgviewer
>   plasma/sreich/plasmoidviewer-use-kpart
>   plasma/sreich/qml2-system-monitors
>   plasma/sreich/sal-lenses
>   plasma/sreich/sal-qml
>   plasma/sreich/tasks-qml
>   plasma/viranch/analogclock
>   plasma/viranch/powermanagementservices
>   plasma/viranch/tasks
>   qt3support
>   qt3supportlocal
>   screenlocker
>   sebas/active-lock-splash
>   sergio/calendarcleanup
>
> --
> Aaron J. Seigo
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>

Regards,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Thoughts about a better Quality Management process for Plasma

[Ben Cooksley]

On Tue, Jan 15, 2013 at 5:11 AM, Martin Gräßlin  wrote:
> On Monday 14 January 2013 16:24:28 Aaron J. Seigo wrote:
>> > Whoever is maintainer of a component, should become the
>> > default assignee for bugs in that component. No longer a one address for
>> > all assignee.
>>
>> i think the maintainer should be added as a default CC, but if each
>> component goes to a single person's inbox, then it means we rely on them to
>> watch it. it also means that when maintainers change, we have to go through
>> and change ownership of tons of bugs .. meh.
> you are lacking knowledge about some bugzilla features :-)
> * add a default CC - just because the bugs go to one person, doesn't mean we
> cannot have the existing address as a CC, so bugs won't get lost
> * search features of bugzilla: you really don't want to use the inbox to watch
> for bugs. It's not like it used to be. Our bko search is damn fast nowadays.
> And you can save your searches you need often
> * Change multiple bugs at once: if a maintainer changes it's just the correct
> query, change the assignee, click save. Process of max five minutes (note: I
> use this feature to move bugs to different target milestones. It is easy).

If you are changing more than 150 bugs please do ask sysadmin to
perform this.  We have methods available which allow the changes to be
made without sending out emails.

The reason I ask is because the last time someone changed a large
number of bugs we were temporarily blacklisted by GMX and Yahoo (due
to exceeding delivery quantity limits), and it took several days to
drain the queue of mails to the recipients, which interfered in their
mailing list subscriptions.

>>
>> i think it also discourages participation by people other than the
>> maintainer: all the bugs are already assigned to someone, after all.
> I can understand your reasoning. But how often does it happen that someone
> from the non core dev team goes to the bug tracker to pick a bug to work on?
> And inside the team it doesn't matter - everybody knows how to read the
> assignee state.
>
> I really would like to have the person set on it, as I hope that this
> increases the feeling of being responsible for it. Instead of an anonymous
> mailing list it becomes a person.
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>

Regards,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDEREVIEW: share like connect and plasmate

[Ben Cooksley]

On Sun, Jan 6, 2013 at 2:10 PM, Aaron J. Seigo  wrote:
> On Thursday, January 3, 2013 09:56:47 Ben Cooksley wrote:
>> What about Share-Like-Connect?
>
> i was waiting until i was back in the office with time to work on it again
> before requesting the move. :)
>
> so ... yes, SLC is ready to be moved out of kdereview.

Where is it destined? This was never stated it seems.

>
> we have it working properly on desktop as well as for touch devices and while
> not all of our (internal) API modifications are where we want them to be, it 
> is
> sufficiently developed for another proper release ... (we've already made 3
> releases of it with Plasma Active, fww)
>
> thanks in advance :)

Regards,
Ben

>
> --
> Aaron J. Seigo
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDEREVIEW: share like connect and plasmate

[Ben Cooksley]

On Thu, Jan 3, 2013 at 10:38 AM, Pino Toscano  wrote:
> Hi,
>
> apparently some people consider that all the issues of this review have
> been fixed, but really they were not.
>
> Alle sabato 3 novembre 2012, Pino Toscano ha scritto:
>> - PasswordAsker sounds like could be implemented on top of
>> KPasswordDialog
>
> Still there.
>
>> - BranchDialog sounds like could be replaced with
>> KInputDialog::getText with a custom validator
>
> Still there.
>
>> - CommitDialog, other than being a KDialog, should better be use
>> layouts instead of placing widgets manually
>
> Still there.
>
>> - a numer of .ui files sets bold/bigger texts, but using a qt rich
>> text which forces a font size (and in few cases also the font face)
>
> Still there.
>
>> - RemoteInstaller uses "/var/tmp/plasmaremoteinstaller/" as
>> destination directory, which is a bit too generic (at least
>> appending the user name and chmod'ing it 600 would help); also there
>> is a race between the KIO exists and the mkdir calls
>
> Still there, and it is even worse now: KStandardDirs is used to get a
> path for a _remote_ location.
>
>> - TimeLine::loadTimeLine does a funky job in putting translated bits
>> among the git output; a better way would be parsing the output
>> extracting the various details, and composing a new ad-hoc string
>> (and the date would need localization, as the FIXME say)
>
> Still there; the only change here was just using KLocale for the date
> output.
>
>> -  StartPage::saveNewProjectPreferences saves the status of all the
>> js/py/etc radio buttons separately... saving the index or the name of
>> the active one would be much easier
>
> Still there.
>
>> - EditPage::showTreeContextMenu uses the internalPointer() of the
>> model, which makes it prone to break if the model changes
>> implementation internally
>
> Still there.
>
>> - why ImageLoader::run forces the formats?
>
> Still there.
>
>> - why KConfigXtWriter writes  prologue/epilogue by hand?
>
> Now it writes the namespaces in a wrong way, closing the quoting
> manually and adding attributes by hand in a single string...
>
>> - TextEditor::modifyToolBar does a big no-no job in looking for
>> actions (never ever compare to translated strings, especially when
>> coming from other components)
>
> What about just finding the actions in the actionCollection() of the
> KTextEditor::View, and hiding them, instead of messing up with the
> XMLGUI document?

Due to this review issue, Plasmate has been returned to KDE Review. My
query regarding Share-Like-Connect still stands as well.

>
> --
> Pino Toscano
>

Regards,
Ben

> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDEREVIEW: share like connect and plasmate

[Ben Cooksley]

On Thu, Jan 3, 2013 at 7:56 AM, Sebastian Kügler  wrote:
> On Tuesday, January 01, 2013 15:39:27 Ben Cooksley wrote:
>> On Tue, Jan 1, 2013 at 3:31 AM, Antonis Tsiapaliokas 
> wrote:
>> > Hello,
>> >
>> > We would like to inform you that all the above issues of the plasmate has
>> > been fixed.
>> > Can someone move it to extragear?
>>
>> Which project(s) does this concern?
>> Also, does anyone have any final reviews to make before I perform the move?
>
> We've been reviewing all individual patches on the plasma list. If someone
> wants to have another go, feel free, but I consider it good quality.

Plasmate has now been moved to Extragear/SDK.
What about Share-Like-Connect?

> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9

Regards,
Ben
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDEREVIEW: share like connect and plasmate

[Ben Cooksley]

On Tue, Jan 1, 2013 at 3:31 AM, Antonis Tsiapaliokas  wrote:
> Hello,
>
> We would like to inform you that all the above issues of the plasmate has
> been fixed.
> Can someone move it to extragear?

Which project(s) does this concern?
Also, does anyone have any final reviews to make before I perform the move?

>
> Cheers,
> Antonis

Thanks,
Ben Cooksley
KDE Sysadmin

>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Fix battery applet screen power management

[Ben Cooksley]

> On Nov. 1, 2012, 3:18 p.m., Commit Hook wrote:
> > This review has been submitted with commit 
> > e1bf8805b3d0c8ddf22805f334faec8bd678742e by Oliver Henshaw to branch 
> > push/4.9.
> 
> Christoph Feck wrote:
> "push/4.9" is not a valid branch name for kde-workspace. If these commits 
> should be part of KDE 4.9.3 release, you need to push or cherry-pick them to 
> branch "KDE/4.9". Please ask maintainers how to proceed.
> 
> Oliver Henshaw wrote:
> Ah yes, my embarassing mistake. The commits did eventually reach KDE/4.9 
> as intended, not sure why reviewboard didn't register that.

KDE's Git Hooks will only process a commit once (recognition is done by the 
SHA-1 hash of the commit).
If you did a plain merge or just pushed to the wrong destination then the hooks 
would not have done reprocessed the commit when it landed in KDE/4.9.


- Ben


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


On Oct. 10, 2012, 3:13 p.m., Oliver Henshaw wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106784/
> ---
> 
> (Updated Oct. 10, 2012, 3:13 p.m.)
> 
> 
> Review request for Plasma and Solid.
> 
> 
> Description
> ---
> 
> Fix battery applet screen power management
> 
> Connect to the correct job when beginning/stopping
> SuppressingScreenPowerManagement. The pasto in the "stop" case was
> probably harmless; in the "begin" case we need to store the correct
> cookie in order to later stop the suppression.
> 
> 
> Diffs
> -
> 
>   plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml 
> 72bb8ec8f9339f2d639267bbc435c1f0f76ecac7 
> 
> Diff: http://git.reviewboard.kde.org/r/106784/diff/
> 
> 
> Testing
> ---
> 
> Tested timed screen & session power management before, during and after 
> inhibit with battery applet.
> 
> 
> Thanks,
> 
> Oliver Henshaw
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request: Fix build when NepomukCore and KDELibs reside in different locations

[Ben Cooksley]

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

Review request for Plasma.


Description
---

This patch is required if your NepomukCore installation exists in a seperate 
installation prefix to KDELibs, which is the case on build.kde.org.
Otherwise, NepomukCore headers are not found, causing the build to fail.


Diffs
-

  applications/webbrowser/src/CMakeLists.txt 850ad8c 
  applications/webbrowser/src/ontologies/CMakeLists.txt d4a3dcb 
  components/metadatamodel/CMakeLists.txt cda517e 
  dataengines/metadata/CMakeLists.txt 9cd002a 
  shell/CMakeLists.txt 911dd1d 

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


Testing
---

Build now succeeds.


Thanks,

Ben Cooksley

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Git policy for kde-baseapps?

[Ben Cooksley]

On Fri, Sep 28, 2012 at 2:28 AM, Frank Reininghaus
 wrote:
> Hi Ben,

Hi Frank,

>
> 2012/9/27 Ben Cooksley:
> [...]
>>>> Well, I found an answer to my own question at [1]. Basically, it says doing
>>>> a rebase of the branch with the master and merging afterwards will prevent
>>>> the duplicate log message:
>>>>
>>>> $ git co -b 4.9 origin/KDE/4.9
>>>> $ git co -b master origin/master
>>>> $ git rebase master 4.9
>>>> $ git co master
>>>> $ git merge 4.9
>>>>
>>>> Perhaps people with more intimate knowledge of git than I want to comment 
>>>> on
>>>> the validity of above steps ? However, it seems to work just fine when I
>>>> tested it against kde-baseapps:
>>>
>>> I think that this approach works fine for local branches, but can lead
>>> to serious problems when used for branches which exist already on the
>>> remote server.
>>>
>>> The problem is that "git rebase" changes the SHA1 hashes of all
>>> commits that are rebased. When this rebased branch is then pushed to
>>> the server (I don't know if that actually works without admin
>>> permissions), the hashes of the commits in the remote branch on the
>>> server and the hashes that the users who pulled earlier have in their
>>> local clones of the repository don't match any more. I think that
>>> users cannot pull the branch any more then without some manual hacking
>>> of the repository state.
>>
>> Due to this issue, mainline KDE git repositories do not permit force
>> pushes, unless a special exemption has been granted.
>> Force pushes also create issues for our commit hooks, which depend on
>> the sha hash not changing to detect commits already in the repository.
>
> Thanks for this information! Quick question: Could it be that some
> commit hooks are nonetheless executed when someone tries a force push,
> even though the commits do not reach the remote repository at all?
> This might explain why I sometimes receive commit mails for commits
> which do not exist at all, see, e.g.,

There are 3 different hooks which run on KDE repositories:
- Gitolite
- Our own auditing and notification hook
- A post-update hook which triggers the anongit update and build.kde.org builds

In the case of force pushes, Gitolite will stop them. A push will only
be successful once the first two hooks are completed (as the 3rd is a
post-update hook).

>
> http://lists.kde.org/?l=kde-commits&m=134632916023074&w=2
>
> Try clicking the link in that mail to see that the commit really does not 
> exist.

That is concerning, I will have to talk to Vishesh to find out what
happened there. I cannot think of too many scenarios where an email is
sent, but the commit does not actually end up in the repository. As
emails are sent before the commits are accepted into the repository,
this is definitely a plausible scenario however.

>
> Best regards,
> Frank

Regards,
Ben

> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel