Re: Tests still failing in 4.13
El Dilluns, 31 de març de 2014, a les 13:03:47, Vishesh Handa va escriure: On Monday, March 31, 2014 01:42:01 AM Albert Astals Cid wrote: Hello people, at the moment we have various 4.13 projects failing. Hello I am also open to be convinced that the test is right and that it's unfixable to run correctly on jenkins, but make sure you are really convincing if you resort to that ;-) nepomuk-core (1 failing test) http://build.kde.org/view/KDE%20SC%20stable/job/nepomuk-core_stable/323/t es tReport/ The failing test is actually passing, but setting up the entire test environment and running the test doesn't always seem to work. Could we have an exception for this? I'm not too inclined on trying to fix it considering that there have been no changes in Nepomuk for 4.13 I increased the timeout time and seems it now passes. Cheers, Albert
Re: Review Request 117091: Force the screen locker's greeter to show the password input field in case of immediateLock
On March 26, 2014, 11:07 p.m., Thomas Lübking wrote: you could sighup or sigusr the greeter process and have it setImmediateLock(true); desktopResized(); in return Wolfgang Bauer wrote: I agree, this would be a bit nicer... But I tried it and cannot get it to work. My signal handler is called, and both setImmediateLock(true) and desktopResized() are called, (I verified this with debug output statements) but the password dialog still doesn't show. Wolfgang Bauer wrote: Oops, sorry. I just noticed that the signal handler is apparently only called when I run kscreenlocker_greet manually (and do kill -USR1), but not when the locker runs it. Will have to investigate this. Forget my previous comment. The signal handler was actually called all the time. But setImmediateLock(true); followed by desktopResized(); DOES NOT have any (visual) effect. I have yet to find out what else to call to make that dialog appear. Any idea maybe? Calling exit(1) does work, but that's not much different to killing the greeter I suppose... ;-) - Wolfgang --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117091/#review54247 --- On March 26, 2014, 5:58 p.m., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117091/ --- (Updated March 26, 2014, 5:58 p.m.) Review request for kde-workspace and Aaron J. Seigo. Bugs: 327947 and 329076 http://bugs.kde.org/show_bug.cgi?id=327947 http://bugs.kde.org/show_bug.cgi?id=329076 Repository: kde-workspace Description --- If the screen locker is set to not require a password to unlock, it will not show the password input field even when the powermanagement settings suspend the system and are set to require a password after resume (when it was already running at that point). This locks people out of their system. As there seems to be no way to switch the already running greeter to immediateLock mode, it is killed in that case by this patch. It gets restarted immediately with the --immediatelock option in KSldApp::lockProcessFinished() and shows the password input field then. Diffs - ksmserver/screenlocker/ksldapp.cpp 3dfcc9e Diff: https://git.reviewboard.kde.org/r/117091/diff/ Testing --- Disable Require password after in the screen locker settings (the default), set it to start after 1 min. (for easier testing). Enable Suspend session after and set it to 2 minutes. (set the action to Suspend, Hibernate, or Lock Screen, doesn't matter) Make sure Lock screen on resume is enabled in the powermanagements Advanced Options (it is by default). After 1 minute the screen locker kicks in, and doesn't require a password. After 2 minutes the session gets suspended, hibernated or locked, and requires a password to resume. Without this patch no password dialog is shown, the user cannot resume the session by entering the password. With this patch this works: there is a password input field, the session is unlocked when the user enters the password. Other openSUSE users have tested this as well, see f.e. https://bugzilla.novell.com/show_bug.cgi?id=864305#c4 Thanks, Wolfgang Bauer
kde-workspace has been split (for frameworks)
Hi there. kde-workspace has been successfully split into the following repositories: powerdevil khotkeys kinfocenter kmenuedit ksysguard kwin kwrited libksysguard oxygen plasma-desktop plasma-workspace systemsettings All repositories but powerdevil are under kde/workspace, powerdevil is in extragear. kde-build-structure has been updated so all tools should work as usual. To get kdesrc-build working make sure you use at least 4c435231cb490 Finally, the CI is still not setup it will be done as soon as possible. Cheers! signature.asc Description: This is a digitally signed message part.
KF5 Update Meeting Minutes 2014-w14
Hello everyone, This is the minutes of the Week 14 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: afiestas, agateau, alexmerry, apol, notmart, Riddell, tosky and myself. * afiestas will push the branch with removed interfaces; * he's first making sure no breakage will happen anywhere and will also put some bits in kde4support; * he'll then add async APIs for a couple of classes; * agateau has been working on translation support for tr based frameworks; * he created new script for l10n-kde4 and added Messages.sh scripts where missing; * he also added ecm_create_qm_from_po_files; * alexmerry got the SIC changes he wanted in before beta 1... but found more; * he's still working on removing the kde4 references although at a slower pace; * apol has been moving kde-runtime bits in several frameworks; * he should be all done by the end of this week; * notmart renamed qtextracomponents to kquickcontrolsaddons and adjusted its users; * Riddell still has to sort out the entry.desktop files; * he also got a volunteer working on the kf5options and qtoptions manpages; * he did some co-installing patches, more to come; * tosky is still working on kdoctools; * ervin has been mostly reviewing. If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Review Request 117174: Fix installing and removing desktop plasma theme packages.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117174/ --- (Updated April 1, 2014, 6:06 p.m.) Review request for kdelibs, Albert Astals Cid, Aaron J. Seigo, David Faure, and Ian Monroe. Bugs: 149479 http://bugs.kde.org/show_bug.cgi?id=149479 Repository: kdelibs Description --- Even though the bug appears RESOLVED it is not. Minor hack to packagestructure.cpp to search for the metadata.desktop file recursively. This helps with installing desktop themes and removing them. I have tested this on kdelibs 4.13 compiled with kdesrc-build. When testing themes ignore SoftSand for example, it's metadata.desktop is not properly formatted. There are others too which are not formatted which I guess could be fixed by setting a new format standard, maybe even a check package script to check new uploads on kde-look.org. Diffs (updated) - plasma/packagestructure.cpp 71148e1 Diff: https://git.reviewboard.kde.org/r/117174/diff/ Testing --- Compiled, run systemsettings, go to Desktop Themes, install / remove away. Some themes are broken so they won't work (not install). File Attachments Limit the extra search to first subdirectory.patch https://git.reviewboard.kde.org/media/uploaded/files/2014/04/01/c9b4a3ee-bd3b-498a-b18c-a4eb13b349d3__0002-Limit-the-search-to-include-the-first-directory-only.patch Thanks, Andrei Amuraritei
Re: Review Request 117174: Fix installing and removing desktop plasma theme packages.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117174/ --- (Updated April 1, 2014, 6:07 p.m.) Review request for kdelibs, Albert Astals Cid, Aaron J. Seigo, David Faure, and Ian Monroe. Bugs: 149479 http://bugs.kde.org/show_bug.cgi?id=149479 Repository: kdelibs Description --- Even though the bug appears RESOLVED it is not. Minor hack to packagestructure.cpp to search for the metadata.desktop file recursively. This helps with installing desktop themes and removing them. I have tested this on kdelibs 4.13 compiled with kdesrc-build. When testing themes ignore SoftSand for example, it's metadata.desktop is not properly formatted. There are others too which are not formatted which I guess could be fixed by setting a new format standard, maybe even a check package script to check new uploads on kde-look.org. Diffs - plasma/packagestructure.cpp 71148e1 Diff: https://git.reviewboard.kde.org/r/117174/diff/ Testing --- Compiled, run systemsettings, go to Desktop Themes, install / remove away. Some themes are broken so they won't work (not install). Thanks, Andrei Amuraritei
Re: Review Request 117174: Fix installing and removing desktop plasma theme packages.
On April 1, 2014, 10:49 a.m., Sebastian Kügler wrote: I'm OK with this last version, except for one whitespace issue, before filename, please. Also, you can update the patch shown in Reviewboard, that makes it way easier to read. Don't just upload a file, but Update diff from the top menu instead. Someone else should have a look over it and ship it, I'll be unavailable in the next days. Added whitespace, and updated diff. Thanks for the help. - Andrei --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117174/#review54754 --- On April 1, 2014, 6:07 p.m., Andrei Amuraritei wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117174/ --- (Updated April 1, 2014, 6:07 p.m.) Review request for kdelibs, Albert Astals Cid, Aaron J. Seigo, David Faure, and Ian Monroe. Bugs: 149479 http://bugs.kde.org/show_bug.cgi?id=149479 Repository: kdelibs Description --- Even though the bug appears RESOLVED it is not. Minor hack to packagestructure.cpp to search for the metadata.desktop file recursively. This helps with installing desktop themes and removing them. I have tested this on kdelibs 4.13 compiled with kdesrc-build. When testing themes ignore SoftSand for example, it's metadata.desktop is not properly formatted. There are others too which are not formatted which I guess could be fixed by setting a new format standard, maybe even a check package script to check new uploads on kde-look.org. Diffs - plasma/packagestructure.cpp 71148e1 Diff: https://git.reviewboard.kde.org/r/117174/diff/ Testing --- Compiled, run systemsettings, go to Desktop Themes, install / remove away. Some themes are broken so they won't work (not install). Thanks, Andrei Amuraritei
Re: Review Request 117091: Force the screen locker's greeter to show the password input field in case of immediateLock
On March 26, 2014, 10:07 p.m., Thomas Lübking wrote:
you could sighup or sigusr the greeter process and have it
setImmediateLock(true);
desktopResized();
in return
Wolfgang Bauer wrote:
I agree, this would be a bit nicer...
But I tried it and cannot get it to work.
My signal handler is called, and both setImmediateLock(true) and
desktopResized() are called, (I verified this with debug output statements)
but the password dialog still doesn't show.
Wolfgang Bauer wrote:
Oops, sorry. I just noticed that the signal handler is apparently only
called when I run kscreenlocker_greet manually (and do kill -USR1), but not
when the locker runs it.
Will have to investigate this.
Wolfgang Bauer wrote:
Forget my previous comment.
The signal handler was actually called all the time.
But setImmediateLock(true); followed by desktopResized(); DOES NOT
have any (visual) effect.
I have yet to find out what else to call to make that dialog appear. Any
idea maybe?
Calling exit(1) does work, but that's not much different to killing the
greeter I suppose... ;-)
Ahhh... me was too smart in the multiscreen code ;-)
the for loop in desktopResized() (which is relevant for the m_immediateLock
handling) won't be entered since no screen changed.
Instead you'd run
for (int i = 0; i desktop()-screenCount(); ++i) {
QDeclarativeProperty(m_views.at(i)-rootObject(), locked).write(true);
}
aside fixing the m_immediateLock value.
Sorry for the false information.
- Thomas
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117091/#review54247
---
On March 26, 2014, 4:58 p.m., Wolfgang Bauer wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117091/
---
(Updated March 26, 2014, 4:58 p.m.)
Review request for kde-workspace and Aaron J. Seigo.
Bugs: 327947 and 329076
http://bugs.kde.org/show_bug.cgi?id=327947
http://bugs.kde.org/show_bug.cgi?id=329076
Repository: kde-workspace
Description
---
If the screen locker is set to not require a password to unlock, it will not
show the password input field even when the powermanagement settings suspend
the system and are set to require a password after resume (when it was
already running at that point).
This locks people out of their system.
As there seems to be no way to switch the already running greeter to
immediateLock mode, it is killed in that case by this patch. It gets
restarted immediately with the --immediatelock option in
KSldApp::lockProcessFinished() and shows the password input field then.
Diffs
-
ksmserver/screenlocker/ksldapp.cpp 3dfcc9e
Diff: https://git.reviewboard.kde.org/r/117091/diff/
Testing
---
Disable Require password after in the screen locker settings (the default),
set it to start after 1 min. (for easier testing).
Enable Suspend session after and set it to 2 minutes. (set the action to
Suspend, Hibernate, or Lock Screen, doesn't matter)
Make sure Lock screen on resume is enabled in the powermanagements
Advanced Options (it is by default).
After 1 minute the screen locker kicks in, and doesn't require a password.
After 2 minutes the session gets suspended, hibernated or locked, and
requires a password to resume.
Without this patch no password dialog is shown, the user cannot resume the
session by entering the password.
With this patch this works: there is a password input field, the session is
unlocked when the user enters the password.
Other openSUSE users have tested this as well, see f.e.
https://bugzilla.novell.com/show_bug.cgi?id=864305#c4
Thanks,
Wolfgang Bauer
Re: Review Request 116602: fix setting ssl_was_in_use metadata
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116602/#review54820 --- This review has been submitted with commit 0d90552e3f3b9a4a13212391db48ed392b455411 by Andrea Iacovitti to branch master. - Commit Hook On March 27, 2014, 6:19 a.m., Andrea Iacovitti wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116602/ --- (Updated March 27, 2014, 6:19 a.m.) Review request for kdelibs and Dawit Alemayehu. Repository: kdelibs Description --- If incomingMetaData doesn't contain item with key ssl_in_use (and i verified this happen) using [] operator results in inserting a new item with key ssl_in_use and NullString value in incomingMetaData map and, as a consequence, a new item with key ssl_was_in_use and NullString value in outgoingMetaData map. This patch aims to avoid this situation by looking up the key using queryMetadata(). Diffs - kio/kio/job.cpp edc5fed Diff: https://git.reviewboard.kde.org/r/116602/diff/ Testing --- Thanks, Andrea Iacovitti
