Re: Python bindings using cppyy (was: An update on Python bindings)

[Albert Astals Cid]

El dissabte, 13 de gener de 2018, a les 18:05:45 CET, Shaheed Haque va 
escriure:
> Thanks to some upstream fixes, I have the cppyy-based bindings for KF5 and
> also Qt5 (see below) showing signs of life. 
> Notes:

This is awesome, i'm really happy we're in a point that framework-by-framework 
is possible and that it all seems to be upstream so it's a "hopefully bigger 
group of people" maintaining it :)

Keep it up!

Cheers,
  Albert

> 
> 
>1. The packaging has advanced to the point where I think ECM-based
>framework-by-framework bindings are a real possibility, with both Py2 and
> Py3. AFAICS, this addresses the main feedback received to date. 2. With
> reference to the remark about tracking dependencies between frameworks,
> apologies for the delayed response as I somehow missed the email. I note
> that the dependencies currently in CMake often seem incomplete. I'll bring
> that to the community separately.
>3. There is one issue still open upstream (
>   
> https://bitbucket.org/wlav/cppyy/issues/16/pragma-link-defined_in-seems-to-> 
> select). However, I don't consider this to be a showstopper...we might even
> be able to live with it as is.
>4. For me, the jury is still out on PyQt versus a new set of cppyy-based
>Qt bindings. Clearly PyQt is solid and mature, but the limitations really
> concern me (if anybody wants to know more, I'm happy to discuss, but let's
> do that in another thread please). Now, given that there are examples in
> the wild of interoperating cppyy/cling/ROOT with PyQt, I'm going to
> sidestep this question but am playing with a cppyy-based approach. At this
> point, all of Qt has basic cppyy-based bindings, and the next step is to
> tackle things like finding a way to express the object
>ownership/destruction rules in a more-or-less systematic way.
>5. On the P2/P3 question, I'm presently still committed to both P2 and
>P3. I *have* had a couple of minor occasions where P3-only might have
> been nice *for my code*, but if I do find an issue that tips the balance,
> or I find some serious benefit *for the bindings*, I'll drop P2. One
> possible such benefit would be if I can see a sane way to address PEP484
> type hints.
> 
> To get here, I had to build a subset of the tooling I previously had
> developed for the SIP-based approach. The big difference is the absence of
> any need to support customisation of the generated bindings. I am hopeful
> that in the worst case, there might be some minimal customisation (known as
> Pythonisations in cppyy parlance) such as for #4 above, but nothing like
> the scale needed for SIP.
> 
> The core tooling is not specific to KF5 or KDE or Qt5, and is developed in
> upstream cppyy over on bitbucket.org. The core tooling is built around
> CMake, notably for the generation phase and the C++ library build.
> 
> The PoC extends the core tooling with Pythonic packaging and installation
> using pip/wheels, also from CMake. As before I would look for help to get
> an ECM equivalent, possibly based on the same approach but perhaps
> including CI and distribution via PyPi.
> 
> Finally, now would be a good time for anybody else who wants to get
> involved to step up, especially as a new job limits my free time.
> 
> Thanks, Shaheed
> 
> P.S. Not to stoke the the P2/P3 wars unnecessarily, but while I know that
> upstream Clang just added P3 support in the clang 5.0 release, current
> Ubuntu only packages it for 2.7.14. So I won't be moving yet...
> 
> On 5 November 2017 at 13:23, Boudewijn Rempt  wrote:
> > On Sat, 4 Nov 2017, Chris Burel wrote:
> > > I think this is a remarkably short sighted statement. It assumes that
> > 
> > people that would use these bindings have no existing Python codebase at
> > all, and can afford to start a brand new project. The reality is much
> > different.
> > 
> > > Let's take a specific example. I have 6 years experience writing Python
> > 
> > for the visual effects industry. We have a 10 year old Python 2 codebase.
> > We also use an application from Autodesk called Maya. It has been a Qt 4
> > application with Python 2 embedded since 2012. In 2016 they jumped to qt 5
> > and pyside2. Now Autodesk knows that companies have built large codebase
> > around their product that requires Python 2. What would've happened if
> > pyside2 did not support Python 2.7? They'd be stuck either forcing all
> > their customers to move to Python 3 and risk people not wanting the new
> > version of the software, or they'd be prevented from moving to Qt 5.
> > 
> > 
> > You will have to switch to Python 3 by 2019, since that's what the VFX
> > Reference Platform says. If you haven't started on the migration yet,
> > you're very late. And the VFX Refernece Platform is basically Autodesk
> > telling the rest of the industry what to use, including their weird
> > patchset for Qt...
> > 
> > > So no, Python 2 is not dead. Not by a long shot.
> > 
> > For VFX, it will be dead in 2019. See http://www.vfxplatfo

D9880: Fix build with >=attr-2.4.48

[Andreas Sturmlechner]

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

REVISION SUMMARY
  It was looking for long deprecated attr/xattr.h header.

TEST PLAN
  Built fine with attr-2.4.47 and 2.4.48.

REPOSITORY
  R286 KFileMetaData

BRANCH
  master

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

AFFECTED FILES
  cmake/FindXattr.cmake
  src/xattr_p.h

To: asturmlechner, #frameworks, mgallien

D9871: Add partial busy-widget support

[Aleix Pol Gonzalez]

apol added a reviewer: andreask.

REPOSITORY
  R266 Breeze Icons

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

To: Kanedias, apol, colomar, andreask
Cc: #frameworks

D9871: Add partial busy-widget support

[Aleix Pol Gonzalez]

apol requested changes to this revision.
apol added a comment.
This revision now requires changes to proceed.


  Please remove the changes in the *.sh files.

REPOSITORY
  R266 Breeze Icons

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

To: Kanedias, apol, colomar
Cc: #frameworks

Re: KHolidays as Framework (redux)

[Volker Krause]

On Sunday, 14 January 2018 16:50:08 CET Sandro Knauß wrote:
> @Volker:  Is there a need to rush releasing KHolidays it under frameworks?

this request is pending since more than 24 month, not exactly my definition of 
rushing things ;-)

We should do the move reasonably early before the next application release 
IMHO, so we don't collide with the pre-releases there. Apart from that I don't 
see any particular timing constraints.

> As far I see it, the include mechanism do not change find_package do not
> need to change and also the target_libraries do not need to changed also
> the API is fixed so far -> no changes in kdepim needed.

Exactly, it's all ready to go since two years.

> The only thing that
> changes is the big bump of the version number and there will be some BIC
> cleanup, so there will be BIC breakage with that move. Distributions need
> to rebuild everything against the new framework. With only BIC changes
> there should be no big issue for distributions to ship a uptodate kdepim
> (17.12.X) with a uptodate KDE frameworks.

Which BIC changes do you have in mind? The ABI has been stable since August 
2015 from what I can see.

Regards,
Volker

> PS: please also inform distributi...@kde.org, if the switch has a fixed
> date.
> On Sonntag, 14. Januar 2018 15:59:46 CET Allen Winter wrote:
> > I don't object to making KHolidays a framework.
> > I kinda object to the short timeline.
> > 
> > I wanted to finish up some BIC cleaning.  No API changes planned at this
> > time. I'll try to hurry.
> > 
> > On Sunday, January 14, 2018 4:20:38 AM EST Volker Krause wrote:
> > > On Tuesday, 6 September 2016 12:03:15 CET Volker Krause wrote:
> > > > On Friday 01 January 2016 18:24:17 David Faure wrote:
> > > > > On Thursday 24 December 2015 12:28:13 John Layt wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > It's xmas holidays, so it must be time to poke a stick at
> > > > > > KHolidays
> > > > > > again
> > > > > > for inclusion as a Framework. As far as I am aware there are no
> > > > > > outstanding
> > > > > > porting issues with KHolidays and it is ready for review to be
> > > > > > included
> > > > > > as
> > > > > > a Tier 1 Framework in the next possible release. What's the next
> > > > > > step?
> > > > > 
> > > > > Please make sure it passes all of the items in this checklist
> > > > > https://community.kde.org/Frameworks/CreationGuidelines
> > > > 
> > > > AFAICS this is followed, apart from using the KF5 version number and
> > > > actually being marked as a framework, which I guess is pending
> > > > framework
> > > > approval.
> > > 
> > > This got lost somehow, any objection to executing the move to frameworks
> > > for 5.43, say end of this week?
> > > 
> > > Regards,
> > > Volker


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

Re: KHolidays as Framework (redux)

[Sandro Knauß]

Hey,

@Volker:  Is there a need to rush releasing KHolidays it under frameworks?

As far I see it, the include mechanism do not change find_package do not need 
to change and also the target_libraries do not need to changed also the API is 
fixed so far -> no changes in kdepim needed. The only thing that changes is 
the big bump of the version number and there will be some BIC cleanup, so 
there will be BIC breakage with that move. Distributions need to rebuild 
everything against the new framework. With only BIC changes there should be no 
big issue for distributions to ship a uptodate kdepim (17.12.X) with a 
uptodate KDE frameworks.

sandro

PS: please also inform distributi...@kde.org, if the switch has a fixed date. 

On Sonntag, 14. Januar 2018 15:59:46 CET Allen Winter wrote:
> I don't object to making KHolidays a framework.
> I kinda object to the short timeline.
> 
> I wanted to finish up some BIC cleaning.  No API changes planned at this
> time. I'll try to hurry.
> 
> On Sunday, January 14, 2018 4:20:38 AM EST Volker Krause wrote:
> > On Tuesday, 6 September 2016 12:03:15 CET Volker Krause wrote:
> > > On Friday 01 January 2016 18:24:17 David Faure wrote:
> > > > On Thursday 24 December 2015 12:28:13 John Layt wrote:
> > > > > Hi,
> > > > > 
> > > > > It's xmas holidays, so it must be time to poke a stick at KHolidays
> > > > > again
> > > > > for inclusion as a Framework. As far as I am aware there are no
> > > > > outstanding
> > > > > porting issues with KHolidays and it is ready for review to be
> > > > > included
> > > > > as
> > > > > a Tier 1 Framework in the next possible release. What's the next
> > > > > step?
> > > > 
> > > > Please make sure it passes all of the items in this checklist
> > > > https://community.kde.org/Frameworks/CreationGuidelines
> > > 
> > > AFAICS this is followed, apart from using the KF5 version number and
> > > actually being marked as a framework, which I guess is pending framework
> > > approval.
> > 
> > This got lost somehow, any objection to executing the move to frameworks
> > for 5.43, say end of this week?
> > 
> > Regards,
> > Volker




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

D9793: Fall back to language name for translations lookup if locale name fails

[Albert Astals Cid]

aacid added inline comments.

INLINE COMMENTS

> ECMQmLoader.cpp.in:68
>  if (!loadTranslation(locale.name())) {
> -loadTranslation(locale.bcp47Name());
> +int i = locale.name().indexOf(QLatin1Char('_'));
> +if (i > 0) {

I agree that locale.bcp47Name() is most probably not want we want, but since 
it's there, some third party user of extra-cmake-modules may be depending on 
it, so us removing will break them·

So please leave that line in and turn it into a

if (!loadTranslation(locale.bcp47Name())) {

  ... your new code.

}

Also very small nitpick, make i const

REPOSITORY
  R240 Extra CMake Modules

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

To: wbauer, #frameworks
Cc: aacid, safaalfulaij, #build_system

KDE CI: Frameworks qqc2-desktop-style kf5-qt5 FreeBSDQt5.9 - Build # 11 - Failure!

[CI System]

BUILD FAILURE
 Build URL
https://build.kde.org/job/Frameworks%20qqc2-desktop-style%20kf5-qt5%20FreeBSDQt5.9/11/
 Project:
Frameworks qqc2-desktop-style kf5-qt5 FreeBSDQt5.9
 Date of build:
Sun, 14 Jan 2018 16:26:33 +
 Build duration:
58 sec and counting
   CONSOLE OUTPUT
  [...truncated 79.65 KB...] * Qt5 (required version >= 5.7.0) * KF5Kirigami2 (required version >= 5.42.0) * KF5 (required version >= 5.42.0)-- Configuring done-- Generating done-- Build files have been written to: /usr/home/jenkins/workspace/Frameworks qqc2-desktop-style kf5-qt5 FreeBSDQt5.9/build[Pipeline] }[Pipeline] // stage[Pipeline] stage[Pipeline] { (Compiling)[Pipeline] sh[Frameworks qqc2-desktop-style kf5-qt5 FreeBSDQt5.9] Running shell script+ python3.5 -u ci-tooling/helpers/compile-build.py --product Frameworks --project qqc2-desktop-style --branchGroup kf5-qt5 --platform FreeBSDQt5.9 --usingInstall /usr/home/jenkins/install-prefix/Scanning dependencies of target org.kde.desktop_autogenScanning dependencies of target qqc2desktopstyleplugin_autogen[ 10%] Automatic MOC for target qqc2desktopstyleplugin[ 20%] Automatic MOC for target org.kde.desktop[ 20%] Built target qqc2desktopstyleplugin_autogenScanning dependencies of target qqc2desktopstyleplugin[ 30%] Building CXX object plugin/CMakeFiles/qqc2desktopstyleplugin.dir/qqc2desktopstyleplugin.cpp.oIn file included from /usr/home/jenkins/workspace/Frameworks qqc2-desktop-style kf5-qt5 FreeBSDQt5.9/plugin/qqc2desktopstyleplugin.cpp:20:In file included from /usr/home/jenkins/workspace/Frameworks qqc2-desktop-style kf5-qt5 FreeBSDQt5.9/plugin/qqc2desktopstyleplugin.h:24:In file included from /usr/local/include/qt5/QtQml/QQmlExtensionPlugin:1:In file included from /usr/local/include/qt5/QtQml/qqmlextensionplugin.h:43:In file included from /usr/local/include/qt5/QtCore/qplugin.h:43:In file included from /usr/local/include/qt5/QtCore/qobject.h:46:In file included from /usr/local/include/qt5/QtCore/qobjectdefs.h:48:In file included from /usr/local/include/qt5/QtCore/qnamespace.h:43:In file included from /usr/local/include/qt5/QtCore/qglobal.h:64:In file included from /usr/local/include/qt5/QtCore/qconfig.h:1:/usr/local/include/qt5/QtCore/qconfig-modules.h:9:10: fatal error: 'QtCore/modules/qconfig-multimedia.h' file not found#include  ^[ 30%] Built target org.kde.desktop_autogen[ 40%] Building CXX object plugin/CMakeFiles/qqc2desktopstyleplugin.dir/kquickstyleitem.cpp.oIn file included from /usr/home/jenkins/workspace/Frameworks qqc2-desktop-style kf5-qt5 FreeBSDQt5.9/plugin/kquickstyleitem.cpp:42:In file included from /usr/home/jenkins/workspace/Frameworks qqc2-desktop-style kf5-qt5 FreeBSDQt5.9/plugin/kquickstyleitem_p.h:45:In file included from /usr/local/include/qt5/QtGui/qimage.h:43:In file included from /usr/local/include/qt5/QtGui/qtguiglobal.h:43:In file included from /usr/local/include/qt5/QtCore/qglobal.h:64:In file included from /usr/local/include/qt5/QtCore/qconfig.h:1:/usr/local/include/qt5/QtCore/qconfig-modules.h:9:10: fatal error: 'QtCore/modules/qconfig-multimedia.h' file not found#include  ^1 error generated.gmake[2]: *** [plugin/CMakeFiles/qqc2desktopstyleplugin.dir/build.make:63: plugin/CMakeFiles/qqc2desktopstyleplugin.dir/qqc2desktopstyleplugin.cpp.o] Error 1gmake[2]: *** Waiting for unfinished jobsScanning dependencies of target org.kde.desktop[ 50%] Building CXX object kirigami-plasmadesktop-integration/CMakeFiles/org.kde.desktop.dir/plasmadesktoptheme.cpp.oIn file included from /usr/home/jenkins/workspace/Frameworks qqc2-desktop-style kf5-qt5 FreeBSDQt5.9/kirigami-plasmadesktop-integration/plasmadesktoptheme.cpp:20:In file included from /usr/home/jenkins/workspace/Frameworks qqc2-desktop-style kf5-qt5 FreeBSDQt5.9/kirigami-plasmadesktop-integration/plasmadesktoptheme.h:23:In file included from /usr/home/jenkins/install-prefix/include/KF5/Kirigami2/PlatformTheme:1:In file included from /usr/home/jenkins/install-prefix/include/KF5/Kirigami2/platformtheme.h:23:In file included from /usr/local/include/qt5/QtCore/QObject:1:In file included from /usr/local/include/qt5/QtCore/qobject.h:46:In file included from /usr/local/include/qt5/QtCore/qobjectdefs.h:48:In file included from /usr/local/include/qt5/QtCore/qnamespace.h:43:In file included from /usr/local/include/qt5/QtCore/qglobal.h:64:In file included from /usr/local/include/qt5/QtCore/qconfig.h:1:/usr/local/include/qt5/QtCore/qconfig-modules.h:9:10: fatal error: 'QtCore/modules/qconfig-multimedia.h' file not found#include  ^1 error generated.gmake[2]: *** [plugin/CMakeFiles/qqc2desktopstyleplugin.dir/build.make:87: plugin/CMakeFiles/qqc2desktopstyleplugin.dir/kquickstyleitem.cpp.o] Error 1gmake[1]: *** [CMakeFiles/Makefile2:151: plugin/CMakeFiles/qqc2desktopstyleplugin.dir/all] Error 2gmake[1]: *** Waiting for unfinished jobs[ 60%] Building CXX object kirigami-plasmadesktop-integration/CMakeFiles/org.kde.desktop.dir/kirigamiplasmafactory.cpp.o

Re: KHolidays as Framework (redux)

[Allen Winter]

I don't object to making KHolidays a framework.
I kinda object to the short timeline.

I wanted to finish up some BIC cleaning.  No API changes planned at this time.
I'll try to hurry.



On Sunday, January 14, 2018 4:20:38 AM EST Volker Krause wrote:
> On Tuesday, 6 September 2016 12:03:15 CET Volker Krause wrote:
> > On Friday 01 January 2016 18:24:17 David Faure wrote:
> > > On Thursday 24 December 2015 12:28:13 John Layt wrote:
> > > > Hi,
> > > > 
> > > > It's xmas holidays, so it must be time to poke a stick at KHolidays
> > > > again
> > > > for inclusion as a Framework. As far as I am aware there are no
> > > > outstanding
> > > > porting issues with KHolidays and it is ready for review to be included
> > > > as
> > > > a Tier 1 Framework in the next possible release. What's the next step?
> > > 
> > > Please make sure it passes all of the items in this checklist
> > > https://community.kde.org/Frameworks/CreationGuidelines
> > 
> > AFAICS this is followed, apart from using the KF5 version number and
> > actually being marked as a framework, which I guess is pending framework
> > approval.
> 
> This got lost somehow, any objection to executing the move to frameworks for 
> 5.43, say end of this week?
> 
> Regards,
> Volker

D9770: Optimization of byteSize(double size)

[Nathaniel Graham]

ngraham added a comment.


  Is anything else needed here before we can land this?

REPOSITORY
  R288 KJobWidgets

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

To: jtamate, #frameworks, mwolff
Cc: ngraham, cfeck, mwolff, broulik

D9275: fix RTL appearance for ComboBox

[Safa Alfulaij]

safaalfulaij added inline comments.

INLINE COMMENTS

> ComboBox.qml:113
>  highlightMoveDuration: 0
> +LayoutMirroring.enabled: true
> +LayoutMirroring.childrenInherit: true

So it is true even for LTR locales?

REPOSITORY
  R242 Plasma Framework (Library)

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

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

D9275: fix RTL appearance for ComboBox

[Safa Alfulaij]

safaalfulaij added a comment.


  In https://phabricator.kde.org/D9275#190606, @mvourlakos wrote:
  
  > To test it in Latte I added in the head of 
/shell/package/contents/configuration/AppearanceConfig.qml
  >
  >   import org.kde.plasma.components 3.0 as PlasmaComponents3
  >
  >
  > and I set up the ComboBox in that file to:
  >
  >   PlasmaComponents3.ComboBox
  >
  >
  >
  >
  > > But I can't understand how changing this V3 solved V2..
  >
  > V2 components are based totally at Qt Styles, V3 are reimplementing the 
behavior
  >  PlasmaComponents2.ComboBox is a ComboBoxStyle  but
  >  PlasmaComponents3.ComboBox is a real ComboBox
  
  
  Did you test this with your LTR layout with only `--reverse`?
  I can say now that the popup box (that is a `Popup`) takes its direction from 
the locale used and not from the application, since it doesn't inhert `Item`, 
and `LayoutMirroring` doesn't affect it
  
  It is similar to this  issue 
with the `Slider`.
  I'll add more info to that soon.

REPOSITORY
  R242 Plasma Framework (Library)

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

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

KDE CI: Frameworks kio kf5-qt5 SUSEQt5.10 - Build # 85 - Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kio%20kf5-qt5%20SUSEQt5.10/85/
 Project:
Frameworks kio kf5-qt5 SUSEQt5.10
 Date of build:
Sun, 14 Jan 2018 12:55:16 +
 Build duration:
14 min and counting
   JUnit Tests
  Name: (root) Failed: 3 test(s), Passed: 55 test(s), Skipped: 0 test(s), Total: 58 test(s)Failed: TestSuite.kiowidgets-dropjobtestFailed: TestSuite.kiowidgets-fileundomanagertestFailed: TestSuite.testtrash
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report64%
(23/36)66%
(291/442)66%
(291/442)52%
(30637/59368)37%
(17906/48460)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests97%
(71/73)97%
(71/73)91%
(8193/9030)48%
(5093/10603)autotests.http100%
(9/9)100%
(9/9)100%
(586/587)59%
(217/368)autotests.kcookiejar100%
(1/1)100%
(1/1)91%
(180/198)67%
(63/94)src100%
(1/1)100%
(1/1)100%
(5/5)75%
(3/4)src.core83%
(99/120)83%
(99/120)58%
(8342/14345)50%
(4812/9704)src.core.kssl100%
(1/1)100%
(1/1)40%
(35/88)50%
(3/6)src.filewidgets79%
(30/38)79%
(30/38)49%
(3851/7797)33%
(1617/4880)src.gui100%
(2/2)100%
(2/2)95%
(104/110)77%
(57/74)src.ioslaves.file100%
(5/5)100%
(5/5)53%
(518/975)42%
(397/938)src.ioslaves.file.kauth0%
(0/3)0%
(0/3)0%
(0/104)0%
(0/75)src.ioslaves.ftp0%
(0/2)0%
(0/2)0%
(0/1364)0%
(0/1513)src.ioslaves.help0%
(0/5)0%
(0/5)0%
(0/247)0%
(0/184)src.ioslaves.http89%
(8/9)89%
(8/9)41%
(1797/4339)35%
(1376/3979)src.ioslaves.http.kcookiejar33%
(2/6)33%
(2/6)47%
(631/1333)55%
(649/1174)src.ioslaves.remote100%
(2/2)100%
(2/2)28%
(71/258)8%
(17/220)src.ioslaves.remote.kdedmodule0%
(0/4)0%
(0/4)0%
(0/14)100%
(0/0)src.ioslaves.telnet0%
(0/1)0%
(0/1)0%
(0/43)0%
(0/30)src.ioslaves.trash67%
(8/1

KDE CI: Frameworks kio kf5-qt5 SUSEQt5.7 - Build # 85 - Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kio%20kf5-qt5%20SUSEQt5.7/85/
 Project:
Frameworks kio kf5-qt5 SUSEQt5.7
 Date of build:
Sun, 14 Jan 2018 12:54:37 +
 Build duration:
11 min and counting
   JUnit Tests
  Name: (root) Failed: 3 test(s), Passed: 55 test(s), Skipped: 0 test(s), Total: 58 test(s)Failed: TestSuite.kiowidgets-dropjobtestFailed: TestSuite.kiowidgets-fileundomanagertestFailed: TestSuite.testtrash
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report64%
(23/36)66%
(293/442)66%
(293/442)52%
(31162/59388)37%
(18158/48536)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests100%
(73/73)100%
(73/73)95%
(8569/9037)50%
(5272/10603)autotests.http100%
(9/9)100%
(9/9)100%
(586/587)59%
(217/368)autotests.kcookiejar100%
(1/1)100%
(1/1)91%
(180/198)67%
(63/94)src100%
(1/1)100%
(1/1)100%
(5/5)75%
(3/4)src.core83%
(99/120)83%
(99/120)59%
(8409/14346)50%
(4867/9708)src.core.kssl100%
(1/1)100%
(1/1)40%
(35/88)50%
(3/6)src.filewidgets79%
(30/38)79%
(30/38)49%
(3852/7797)33%
(1618/4880)src.gui100%
(2/2)100%
(2/2)95%
(104/110)77%
(57/74)src.ioslaves.file100%
(5/5)100%
(5/5)53%
(517/975)42%
(396/938)src.ioslaves.file.kauth0%
(0/3)0%
(0/3)0%
(0/104)0%
(0/75)src.ioslaves.ftp0%
(0/2)0%
(0/2)0%
(0/1364)0%
(0/1513)src.ioslaves.help0%
(0/5)0%
(0/5)0%
(0/247)0%
(0/184)src.ioslaves.http89%
(8/9)89%
(8/9)41%
(1797/4339)35%
(1376/3979)src.ioslaves.http.kcookiejar33%
(2/6)33%
(2/6)47%
(631/1333)55%
(649/1174)src.ioslaves.remote100%
(2/2)100%
(2/2)28%
(71/258)8%
(17/220)src.ioslaves.remote.kdedmodule0%
(0/4)0%
(0/4)0%
(0/14)100%
(0/0)src.ioslaves.telnet0%
(0/1)0%
(0/1)0%
(0/43)0%
(0/30)src.ioslaves.trash67%
(8/1

KDE CI: Frameworks kio kf5-qt5 FreeBSDQt5.9 - Build # 65 - Still Failing!

[CI System]

BUILD FAILURE
 Build URL
https://build.kde.org/job/Frameworks%20kio%20kf5-qt5%20FreeBSDQt5.9/65/
 Project:
Frameworks kio kf5-qt5 FreeBSDQt5.9
 Date of build:
Sun, 14 Jan 2018 12:54:37 +
 Build duration:
6 min 48 sec and counting
   CONSOLE OUTPUT
  [...truncated 186.40 KB...]Scanning dependencies of target ktelnetservice5_autogen[  5%] Automatic MOC for target kded_kcookiejar[  5%] Built target org.kde.kio.file.policy-customtarget[  5%] Automatic MOC for target kcookiejar5[  5%] Automatic MOC for target ktelnetservice5Scanning dependencies of target lockingtest_autogen[  5%] Built target kcookiejar5_autogen[  5%] Built target ktelnetservice5_autogen[  5%] Automatic MOC for target lockingtestScanning dependencies of target kpac_dhcp_helper_autogenScanning dependencies of target httpfiltertest_autogen[  6%] Automatic MOC for target kpac_dhcp_helper[  6%] Automatic MOC for target httpfiltertest[  6%] Built target kpac_dhcp_helper_autogenScanning dependencies of target httpheaderdispositiontest_autogen[  6%] Automatic MOC for target httpheaderdispositiontest[  6%] Built target lockingtest_autogenScanning dependencies of target httpheadertokenizetest_autogen[  6%] Automatic MOC for target httpheadertokenizetest[  6%] Built target httpheaderdispositiontest_autogen[  6%] Built target httpheadertokenizetest_autogen[  6%] Built target docs-kcontrol5-webshortcuts-index-cache-bz2Scanning dependencies of target protocoltojson[  6%] Generating org.kde.KCookieServer.xmlScanning dependencies of target KF5KIONTLM[  6%] Building CXX object src/protocoltojson/CMakeFiles/protocoltojson.dir/main.cpp.o[  6%] Building CXX object src/kntlm/CMakeFiles/KF5KIONTLM.dir/kntlm.cpp.oIn file included from /usr/home/jenkins/workspace/Frameworks kio kf5-qt5 FreeBSDQt5.9/src/protocoltojson/main.cpp:21:In file included from /usr/local/include/qt5/QtCore/QCoreApplication:1:In file included from /usr/local/include/qt5/QtCore/qcoreapplication.h:43:In file included from /usr/local/include/qt5/QtCore/qglobal.h:64:In file included from /usr/local/include/qt5/QtCore/qconfig.h:1:/usr/local/include/qt5/QtCore/qconfig-modules.h:9:10: fatal error: 'QtCore/modules/qconfig-multimedia.h' file not found#include  ^In file included from /usr/home/jenkins/workspace/Frameworks kio kf5-qt5 FreeBSDQt5.9/src/kntlm/kntlm.cpp:24:In file included from /usr/home/jenkins/workspace/Frameworks kio kf5-qt5 FreeBSDQt5.9/src/kntlm/kntlm.h:23:In file included from /usr/local/include/qt5/QtCore/QString:1:In file included from /usr/local/include/qt5/QtCore/qstring.h:48:In file included from /usr/local/include/qt5/QtCore/qchar.h:43:In file included from /usr/local/include/qt5/QtCore/qglobal.h:64:In file included from /usr/local/include/qt5/QtCore/qconfig.h:1:/usr/local/include/qt5/QtCore/qconfig-modules.h:9:10: fatal error: 'QtCore/modules/qconfig-multimedia.h' file not found#include  ^[  6%] Generating kcookieserverinterface.cpp, kcookieserverinterface.h[  6%] Generating kcookieserverinterface.moc1 error generated.gmake[2]: *** [src/kntlm/CMakeFiles/KF5KIONTLM.dir/build.make:63: src/kntlm/CMakeFiles/KF5KIONTLM.dir/kntlm.cpp.o] Error 1gmake[1]: *** [CMakeFiles/Makefile2:1481: src/kntlm/CMakeFiles/KF5KIONTLM.dir/all] Error 2gmake[1]: *** Waiting for unfinished jobs[  6%] Building CXX object src/protocoltojson/CMakeFiles/protocoltojson.dir/protocoltojson_autogen/mocs_compilation.cpp.oScanning dependencies of target kcookiejar5[  6%] Built target kded_kcookiejar_autogen[  6%] Building CXX object src/ioslaves/http/kcookiejar/CMakeFiles/kcookiejar5.dir/kcookieserverinterface.cpp.o[  6%] Building CXX object src/ioslaves/http/kcookiejar/CMakeFiles/kcookiejar5.dir/main.cpp.o1 error generated.[  7%] Building CXX object src/ioslaves/http/kcookiejar/CMakeFiles/kcookiejar5.dir/kcookiejar5_autogen/mocs_compilation.cpp.ogmake[2]: *** [src/protocoltojson/CMakeFiles/protocoltojson.dir/build.make:63: src/protocoltojson/CMakeFiles/protocoltojson.dir/main.cpp.o] Error 1gmake[1]: *** [CMakeFiles/Makefile2:1393: src/protocoltojson/CMakeFiles/protocoltojson.dir/all] Error 2In file included from /usr/home/jenkins/workspace/Frameworks kio kf5-qt5 FreeBSDQt5.9/build/src/ioslaves/http/kcookiejar/kcookieserverinterface.cpp:12:In file included from /usr/home/jenkins/workspace/Frameworks kio kf5-qt5 FreeBSDQt5.9/build/src/ioslaves/http/kcookiejar/kcookieserverinterface.h:14:In file included from /usr/local/include/qt5/QtCore/QObject:1:In file included from /usr/local/include/qt5/QtCore/qobject.h:46:In file included from /usr/local/include/qt5/QtCore/qobjectdefs.h:48:In file included from /usr/local/include/qt5/QtCore/qnamespace.h:43:In file included from /usr/local/include/qt5/QtCore/qglobal.h:64:In file included from /usr/local/include/qt5/QtCore/qconfig.h:1:/usr/local/include/qt5/QtCore/qconfig-modules.h:9:10: fatal error: 'QtCore/modules/qconfig-multimedia.h' file not found#include  ^In file included from /usr/home/jenkins/worksp

D9844: Don't stat(/etc/localtime) between read() and write() copying files

[Jaime Torres Amate]

jtamate marked an inline comment as done.

REPOSITORY
  R241 KIO

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

To: jtamate, #frameworks, dfaure
Cc: broulik, ngraham, #dolphin

D9844: Don't stat(/etc/localtime) between read() and write() copying files

[Kai Uwe Broulik]

broulik added inline comments.

INLINE COMMENTS

> jtamate wrote in slavebase.cpp:117
> Could it be done without a review? I was busy doing arc land (with some 
> problems) and I didn't notice.

Sure

REPOSITORY
  R241 KIO

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

To: jtamate, #frameworks, dfaure
Cc: broulik, ngraham, #dolphin

D9844: Don't stat(/etc/localtime) between read() and write() copying files

[Jaime Torres Amate]

jtamate added inline comments.

INLINE COMMENTS

> broulik wrote in slavebase.cpp:117
> Init with 0 in the constructor?

Could it be done without a review? I was busy doing arc land (with some 
problems) and I didn't notice.

REPOSITORY
  R241 KIO

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

To: jtamate, #frameworks, dfaure
Cc: broulik, ngraham, #dolphin

KDE CI: Frameworks kio kf5-qt5 FreeBSDQt5.9 - Build # 64 - Failure!

[CI System]

BUILD FAILURE
 Build URL
https://build.kde.org/job/Frameworks%20kio%20kf5-qt5%20FreeBSDQt5.9/64/
 Project:
Frameworks kio kf5-qt5 FreeBSDQt5.9
 Date of build:
Sun, 14 Jan 2018 12:40:12 +
 Build duration:
2 min 38 sec and counting
   CONSOLE OUTPUT
  [...truncated 167.50 KB...][  1%] Generating index.cache.bz2[  1%] Built target docs-kioslave5-help-documentationnotfound-index-cache-bz2Scanning dependencies of target docs-kioslave5-mailto-index-cache-bz2[  2%] Generating index.cache.bz2[  2%] Built target docs-kioslave5-http-index-cache-bz2Scanning dependencies of target docs-kioslave5-telnet-index-cache-bz2[  2%] Generating index.cache.bz2[  2%] Built target docs-kioslave5-mailto-index-cache-bz2Scanning dependencies of target docs-kioslave5-webdav-index-cache-bz2[  2%] Generating index.cache.bz2[  2%] Built target docs-kioslave5-telnet-index-cache-bz2Scanning dependencies of target docs-kcontrol5-cache-index-cache-bz2[  3%] Generating index.cache.bz2[  3%] Built target docs-kioslave5-webdav-index-cache-bz2Scanning dependencies of target docs-kcontrol5-cookies-index-cache-bz2[  3%] Generating index.cache.bz2[  3%] Built target docs-kcontrol5-cache-index-cache-bz2Scanning dependencies of target docs-kcontrol5-netpref-index-cache-bz2[  3%] Generating index.cache.bz2[  3%] Built target docs-kcontrol5-cookies-index-cache-bz2Scanning dependencies of target docs-kcontrol5-proxy-index-cache-bz2[  3%] Generating index.cache.bz2[  3%] Built target docs-kcontrol5-netpref-index-cache-bz2Scanning dependencies of target docs-kcontrol5-smb-index-cache-bz2[  3%] Generating index.cache.bz2[  3%] Built target docs-kcontrol5-proxy-index-cache-bz2Scanning dependencies of target docs-kcontrol5-trash-index-cache-bz2[  3%] Generating index.cache.bz2[  3%] Built target docs-kcontrol5-smb-index-cache-bz2Scanning dependencies of target docs-kcontrol5-useragent-index-cache-bz2[  3%] Generating index.cache.bz2[  3%] Built target docs-kcontrol5-trash-index-cache-bz2Scanning dependencies of target docs-kcontrol5-webshortcuts-index-cache-bz2[  3%] Generating index.cache.bz2[  3%] Built target docs-kcontrol5-useragent-index-cache-bz2Scanning dependencies of target KF5KIOCore_autogen[  3%] Generating moc_predefs.h[  4%] Automatic MOC for target KF5KIOCore[  4%] Built target docs-kcontrol5-webshortcuts-index-cache-bz2Scanning dependencies of target protocoltojson_autogen[  4%] Automatic MOC for target protocoltojson[  4%] Built target protocoltojson_autogenScanning dependencies of target KF5KIONTLM_autogen[  4%] Automatic MOC for target KF5KIONTLM[  4%] Built target KF5KIONTLM_autogenScanning dependencies of target org.kde.kio.file.policy-customtarget[  5%] Generating org.kde.kio.file.policy[  5%] actions for org.kde.kio.file[  5%] Built target org.kde.kio.file.policy-customtargetScanning dependencies of target kded_kcookiejar_autogen[  5%] Automatic MOC for target kded_kcookiejar[  5%] Built target kded_kcookiejar_autogenScanning dependencies of target kcookiejar5_autogen[  5%] Automatic MOC for target kcookiejar5[  5%] Built target kcookiejar5_autogenScanning dependencies of target ktelnetservice5_autogen[  5%] Automatic MOC for target ktelnetservice5[  5%] Built target ktelnetservice5_autogenScanning dependencies of target lockingtest_autogen[  5%] Automatic MOC for target lockingtest[  5%] Built target lockingtest_autogenScanning dependencies of target kpac_dhcp_helper_autogen[  6%] Automatic MOC for target kpac_dhcp_helper[  6%] Built target kpac_dhcp_helper_autogenScanning dependencies of target httpfiltertest_autogen[  6%] Automatic MOC for target httpfiltertest[  6%] Built target httpfiltertest_autogenScanning dependencies of target httpheaderdispositiontest_autogen[  6%] Automatic MOC for target httpheaderdispositiontest[  6%] Built target httpheaderdispositiontest_autogenScanning dependencies of target httpheadertokenizetest_autogen[  6%] Automatic MOC for target httpheadertokenizetest[  6%] Built target httpheadertokenizetest_autogenScanning dependencies of target protocoltojson[  6%] Building CXX object src/protocoltojson/CMakeFiles/protocoltojson.dir/main.cpp.oIn file included from /usr/home/jenkins/workspace/Frameworks kio kf5-qt5 FreeBSDQt5.9/src/protocoltojson/main.cpp:21:In file included from /usr/local/include/qt5/QtCore/QCoreApplication:1:In file included from /usr/local/include/qt5/QtCore/qcoreapplication.h:43:In file included from /usr/local/include/qt5/QtCore/qglobal.h:64:In file included from /usr/local/include/qt5/QtCore/qconfig.h:1:/usr/local/include/qt5/QtCore/qconfig-modules.h:9:10: fatal error: 'QtCore/modules/qconfig-multimedia.h' file not found#include  ^1 error generated.gmake[2]: *** [src/protocoltojson/CMakeFiles/protocoltojson.dir/build.make:63: src/protocoltojson/CMakeFiles/protocoltojson.dir/main.cpp.o] Error 1gmake[1]: *** [CMakeFiles/Makefile2:1393: src/protocoltojson/CMakeFiles/protocoltojson.dir/all] Error 2gmake[1]: *** Waiting for unfinished jobs..

D9844: Don't stat(/etc/localtime) between read() and write() copying files

[Jaime Torres Amate]

This revision was automatically updated to reflect the committed changes.
Closed by commit R241:f7e00b40a6d3: Don't stat(/etc/localtime) between 
read() and write() copying files (authored by jtamate).

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D9844?vs=25242&id=25310

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

AFFECTED FILES
  src/core/slavebase.cpp

To: jtamate, #frameworks, dfaure
Cc: broulik, ngraham, #dolphin

D9844: Don't stat(/etc/localtime) between read() and write() copying files

[Kai Uwe Broulik]

broulik added inline comments.

INLINE COMMENTS

> slavebase.cpp:117
> +QElapsedTimer nextTimeout;
> +qint64 nextTimeoutMsecs;
>  KIO::filesize_t totalSize;

Init with 0 in the constructor?

REPOSITORY
  R241 KIO

BRANCH
  elapsedtimer (branched from master)

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

To: jtamate, #frameworks, dfaure
Cc: broulik, ngraham, #dolphin

D9844: Don't stat(/etc/localtime) between read() and write() copying files

[David Faure]

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


  Well spotted!

REPOSITORY
  R241 KIO

BRANCH
  elapsedtimer (branched from master)

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

To: jtamate, #frameworks, dfaure
Cc: ngraham, #dolphin

D9844: Don't stat(/etc/localtime) between read() and write() copying files

[Elvis Angelaccio]

elvisangelaccio added a reviewer: dfaure.

REPOSITORY
  R241 KIO

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

To: jtamate, #frameworks, dfaure
Cc: ngraham, #dolphin

D9840: Tentative patch to reduce I/O overhead of plasmashell when copying files

[David Faure]

dfaure requested changes to this revision.
dfaure added a comment.
This revision now requires changes to proceed.


  This goes against the whole redesign of ksycoca that I did some time ago. 
It's supposed to check timestamps on dirs, to rebuild the cache on demand, much 
like many other caches out there. Did you run the unittests in kservice after 
this change? I strongly doubt they pass.
  
  I don't understand why a copy triggered by the user (so, I assume, not 
related to ~/.local) would trigger an unusual effort on the part of ksycoca? 
How can this be related?
  It's just the I/O of the copying happening at the same time as the I/O from 
ksycoca when using the K menu or something?

REPOSITORY
  R309 KService

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

To: jtamate, #frameworks, dfaure
Cc: ngraham, mmustac

Re: Current security issues with KAuth support in KIO

[chinmoy ranjan]

> Is someone already working on fixes for the above issues?

Currently I am looking into the issues.

Re: KHolidays as Framework (redux)

[David Faure]

On dimanche 14 janvier 2018 10:20:38 CET Volker Krause wrote:
> On Tuesday, 6 September 2016 12:03:15 CET Volker Krause wrote:
> > On Friday 01 January 2016 18:24:17 David Faure wrote:
> > > On Thursday 24 December 2015 12:28:13 John Layt wrote:
> > > > Hi,
> > > > 
> > > > It's xmas holidays, so it must be time to poke a stick at KHolidays
> > > > again
> > > > for inclusion as a Framework. As far as I am aware there are no
> > > > outstanding
> > > > porting issues with KHolidays and it is ready for review to be
> > > > included
> > > > as
> > > > a Tier 1 Framework in the next possible release. What's the next step?
> > > 
> > > Please make sure it passes all of the items in this checklist
> > > https://community.kde.org/Frameworks/CreationGuidelines
> > 
> > AFAICS this is followed, apart from using the KF5 version number and
> > actually being marked as a framework, which I guess is pending framework
> > approval.
> 
> This got lost somehow, any objection to executing the move to frameworks for
> 5.43, say end of this week?

Go ahead.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: [kio] src/ioslaves/file/kauth: Do not cache root password for the whole session

[Elvis Angelaccio]

On venerdì 12 gennaio 2018 17:35:30 CET, chinmoy ranjan wrote:

I just tested this in my session:

kioclient5 copy  /mnt

Prompt appears, all OK.

Now I do this again in the same session, after removing the file:

kioclient5 copy  /mnt

No password prompt and the file is copied anyway.


I executed the commands in the same order on a new VM and I am 
getting proper prompts (with persistence=session).


There's one thing I don't understand, how did you execute two 
kioclient commands in one session? I mean, as soon as one 
kioclient5 command finishes the session ends and for the next 
command there will be a new session. Am I wrong? If not then 
there should be a password prompt (persistence value doesn't 
matter) shown right after every call to kioclient5. 
Since you didn't get  a password prompt the second time, it 
seems to me its more likely a issue with your setup. Is there 
any way we can confirm if this depends on local setup or not? 
Meanwhile, can you try using kioslavetest. Maybe that will work 
properly. 


I can confirm Chinmoy's behavior:

$ kioclient5 copy /home/elvis/test.tar.gz /mnt => KAuth prompt
$ sudo rm /mnt/test.tar.gz
$ kioclient5 copy /home/elvis/test.tar.gz /mnt => another KAuth prompt

This is on Archlinux, FWIW.

Cheers,
Elvis

Re: Current security issues with KAuth support in KIO

[Luca Beltrame]

Il giorno Sun, 14 Jan 2018 11:12:15 +0100
Elvis Angelaccio  ha scritto:

> No, it's not. Despite the name, 'Persistence=session' just means the 
> privilege is kept for a few minutes.

As discussed on IRC, this is an "issue" due to the fact that KIO can do
much more than other KAuth-enabled programs. I'm fully aware that
removing it is not an option in the long run as it kills usability.

> Why 029da62886e0 was committed without code review?

That was me, sorry. I thought it was better to bring this to attention
rather than let it lie until the next Frameworks release.

> Is someone already working on fixes for the above issues?

At the moment, I think not (this stuff was found out properly
yesterday). 

Re: Using KWallet from non-KDE apps (G.Chrome...)

[Valentin Rusu]

Hey,

Sorry for the apparent late reply - I started to have some spare time so
I'm back looking the KDE e-mails :-)

* René J.V. Bertin  [2017-12-20 10:37:07 +0100]:

> Hi,
> 
> Is it still possible to query a KWallet for the existence of specific 
> credentials without having to unlock it first?

It was never possible to query a KWallet without unlocking it, AFAICT.

> 
> The reason I'm asking (not entirely on-topic here, apologies) is that Google 
> Chrome has been putting up wallet unlock dialogs for a long time now, 
> apparently as soon as it detects a login/authentification mechanism on a page 
> that just got (re)loaded. I've filed a bug report about that (a long time 
> ago), but it never got picked up or even closed as invalid.

I remember Google Chrome correctly detected KWallet and interacted with
it when present. But lately I returned to Firefox so don't know more.
For that to work, you need to have a KDE session going in the
background.  That session will initialize the dbus services and among
them the kwalletd service. From that point on, the client-side libraries
will talk to it.


-- 
Valentin Rusu
IRC: valir

D9871: Add partial busy-widget support

[Oleg Chernovskiy]

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

REVISION SUMMARY
  - added busy-widget icon 32-px action variant
  - centered actual curve, removed additional shapes from 
breeze-plymouth/sources

REPOSITORY
  R266 Breeze Icons

BRANCH
  master

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

AFFECTED FILES
  icons-dark/actions/32/busy-widget.svg
  icons/actions/32/busy-widget.svg
  optimize-svg.sh
  validate_svg.sh

To: Kanedias, apol, colomar
Cc: #frameworks

D9840: Tentative patch to reduce I/O overhead of plasmashell when copying files

[Elvis Angelaccio]

elvisangelaccio added a reviewer: dfaure.

REPOSITORY
  R309 KService

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

To: jtamate, #frameworks, dfaure
Cc: ngraham, mmustac

Re: [kio] src/ioslaves/file/kauth: Do not cache root password for the whole session

[Elvis Angelaccio]

On venerdì 12 gennaio 2018 19:40:50 CET, David Edmundson wrote:
Can we keep all messages on the ML. We can only see half a 
conversation on here.



TBH I can't see how any application will bypass the prompt


A rogue plugin can call org.kde.kio.file.exec directly with 
kauth.  Or even just use DBus directly.


Right, even though if you have plugins that execute random code is already 
game over.


I'm sure we can find another solution for this problem, rather than 
removing the Persistence attribute altogether (which kills the usability of 
the feature).


Cheers,
Elvis

Re: Current security issues with KAuth support in KIO

[Elvis Angelaccio]

On sabato 13 gennaio 2018 23:55:16 CET, Luca Beltrame wrote:
(please keep Fabian in CC, he's not subscribed and found out most of the 
issues reported here)


At openSUSE we have to request reviews by the security team before
new polkit services get accepted. This is the case for the kio 
kauth helper as 
well.
While the security team raised concerns with the wide capabilities of the 
helper (it can easily be used to do literally everything), we had a look at 
the implementation itself to find some obvious security issues:


- The privilege is persistent for the entire session


No, it's not. Despite the name, 'Persistence=session' just means the 
privilege is kept for a few minutes.



(already fixed).


Why 029da62886e0 was committed without code review?

- The confirmation prompt for the kauth action use does not 
tell what is going
  to happen. So you might open a file dialog and then instead of opening a 
file, write to /bin/sh.

- Trivial stack-based buffer overflow in the kauth helper:
  https://cgit.kde.org/kio.git/tree/src/ioslaves/file/sharefd_p.h#n57
- The socket used to send and receive file descriptors does not 
have any kind 
of permission check. You can easily send fds to and receive fds 
from users of 
the  kauth helper on the same machine.   (BTW, SocketAddress::length should 
return the actual length of the buffer,  currently it adds ~100 
'\0' bytes to 
the end)


In its current state we can not recommend anyone to enable this.
However, we hope that those issues can be addressed, it does provide some 
useful functionality.


Is someone already working on fixes for the above issues?



Luca Beltrame
on behalf of the openSUSE KDE Team


Cheers,
Elvis

D9275: fix RTL appearance for ComboBox

[Michail Vourlakos]

mvourlakos added a comment.


  In https://phabricator.kde.org/D9275#190594, @safaalfulaij wrote:
  
  > In https://phabricator.kde.org/D9275#190569, @mvourlakos wrote:
  >
  > > with your example me I cant reproduce it either...
  > >  I can only reproduce it with Latte Settings window, all other components 
are aligned correctly except the PlasmaComponent3.Combobox list items.
  > >
  > > you are right, this might be a downstream bug...
  > >
  > > Do you want to revert it 
  > >  I can do it
  >
  >
  > I checked out the source of latte-dock and it seems that it is using the 
old QQC1-based controls, which are problematic, especially with RTL :)
  >  This is a change for QQC2-based controls (version 3.0 of 
org.kde.plasma.components).
  
  
  To test it in Latte I added in the head of 
/shell/package/contents/configuration/AppearanceConfig.qml
  
import org.kde.plasma.components 3.0 as PlasmaComponents3
  
  and I set up the ComboBox in that file to:
  
PlasmaComponents3.ComboBox
  
  
  
  > But I can't understand how changing this V3 solved V2..
  
  V2 components are based totally at Qt Styles, V3 are reimplementing the 
behavior
  PlasmaComponents2.ComboBox is a ComboBoxStyle  but
  PlasmaComponents3.ComboBox is a real ComboBox

REPOSITORY
  R242 Plasma Framework (Library)

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

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

Re: KHolidays as Framework (redux)

[Volker Krause]

On Tuesday, 6 September 2016 12:03:15 CET Volker Krause wrote:
> On Friday 01 January 2016 18:24:17 David Faure wrote:
> > On Thursday 24 December 2015 12:28:13 John Layt wrote:
> > > Hi,
> > > 
> > > It's xmas holidays, so it must be time to poke a stick at KHolidays
> > > again
> > > for inclusion as a Framework. As far as I am aware there are no
> > > outstanding
> > > porting issues with KHolidays and it is ready for review to be included
> > > as
> > > a Tier 1 Framework in the next possible release. What's the next step?
> > 
> > Please make sure it passes all of the items in this checklist
> > https://community.kde.org/Frameworks/CreationGuidelines
> 
> AFAICS this is followed, apart from using the KF5 version number and
> actually being marked as a framework, which I guess is pending framework
> approval.

This got lost somehow, any objection to executing the move to frameworks for 
5.43, say end of this week?

Regards,
Volker

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

D9275: fix RTL appearance for ComboBox

[Safa Alfulaij]

safaalfulaij added a comment.


  In https://phabricator.kde.org/D9275#190569, @mvourlakos wrote:
  
  > with your example me I cant reproduce it either...
  >  I can only reproduce it with Latte Settings window, all other components 
are aligned correctly except the PlasmaComponent3.Combobox list items.
  >
  > you are right, this might be a downstream bug...
  >
  > Do you want to revert it 
  >  I can do it
  
  
  I checked out the source of latte-dock and it seems that it is using the old 
QQC1-based controls, which are problematic, especially with RTL :)
  This is a change for QQC2-based controls (version 3.0 of 
org.kde.plasma.components).
  
  But I can't understand how changing this V3 solved V2..

REPOSITORY
  R242 Plasma Framework (Library)

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

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

D9275: fix RTL appearance for ComboBox

[Michail Vourlakos]

mvourlakos added a comment.


  In https://phabricator.kde.org/D9275#190547, @safaalfulaij wrote:
  
  > In https://phabricator.kde.org/D9275#190497, @mvourlakos wrote:
  >
  > > how did you test it?
  > >
  > > I tried in an qml app (Latte dock) by passing the parameter "--reverse"...
  > >  If your system is already using in RTL language, have you tried with 
--reverse?
  >
  >
  > I am using this with qmlsence-qt5.
  >  `plasma` folder is the ones before this, and `plasmacomponents3` is the 
one after this.
  >  Using C locale, everything aligned to left. Using --reverse will align 
everything to right.
  >  Using ar locale, everything aligned to right. Using --reverse will **not** 
reverse it to LTR layout and it makes everything aligned to left.
  >
  > Can't see the problem really.
  
  
  with your example me I cant reproduce it either...
  I can only reproduce it with Latte Settings window, all other components are 
aligned correctly except the PlasmaComponent3.Combobox list items.
  
  you are right, this might be a downstream bug...
  
  Do you want to revert it 
  I can do it

REPOSITORY
  R242 Plasma Framework (Library)

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

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