Re: KDE Frameworks & Plasma 5.8 LTS

2016-10-23 Thread šumski 
On Sunday 23 of October 2016 22:50:13 Albert Astals Cid wrote:
> El diumenge, 23 d’octubre de 2016, a les 14:03:28 CEST, Luca Beltrame va
> 
> escriure:
> > Il giorno Sun, 23 Oct 2016 12:14:51 +0200
> > 
> > Dominik Haumann  ha scritto:
> > > Do we have any knowledge on whether distributions that ship Plasma 5.8
> > > LTS still provide updates to KDE Frameworks 5.27 etc?
> > 
> > openSUSE Tumbleweed will always have the last version of everything
> > (barring issues). openSUSE Leap 42.2 will *not* get any major version
> > update, so it will stick with Plasma 5.8 and KF 5.26.
> 
> I don't really understand why you would want to stay with a KF version that
> has known bugs fixed in later versions, but i guess that's what stability
> means nowadays :)

I don't really understand why you would want to upgrade to a KF5 version which 
has known bugs not present in earlier version -> is what the release managers 
are thinking =)


Cheers,
Hrvoje

> Cheers,
>   Albert

Re: lib/x86_64-linux-gnu/libKF5FileMetaData.so | lib/libKF5FileMetaData.3.dylib

2015-12-17 Thread šumski 
On Thursday 17 of December 2015 12:51:42 René J. V. Bertin wrote:
> šumski wrote:
> >> Yes, bug fixes can do that ;)
> > 
> > Yes, but frameworks are under BC guarantee.
> 
> So how are bugs supposed to be fixed if they break ABI compatibility?

Certainly not by breaking one of core policies. 

> 
> If I'm not mistaken Linux will not check beyond shared library file names.
> If that's correct, the build system can install a libKF5FMD.so.3 file that
> links to libKF5FMD.so.5 then applications that haven't been relinked
> should load and run.
> 
> This isn't a typical version of ABI breakage, btw. And I have a hunch that
> users who build from source won't even notice the change because
> libKF5FMD.so.3 and libKF5FMD.so.5.16.0 will not be uninstalled when you
> install KFileMetaData 5.17.0 . It will be different for users who get
> their binaries from an upstream packager/distribution ... and it'll be
> trivial for those to provide relinked dependent packages. (MacPorts will
> scan for and pick up this kind of change, queuing affected dependents for
> a rebuild; I cannot imagine that Linux packaging systems do not have such
> a convenience feature.)

That's not relevant at all. Yeah it can we workarounded though i don't think 
fixing a cosmetic bug is better than introducing a grave bug.


Cheers,
Hrvoje
> 
> R.
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: lib/x86_64-linux-gnu/libKF5FileMetaData.so | lib/libKF5FileMetaData.3.dylib

2015-12-16 Thread šumski 
On Wednesday 16 of December 2015 09:08:03 David Faure wrote:
> Fixed, it was an oversight when converting the lib into a KF5 framework.

But this is a BiC change...


Cheers,
Hrvoje

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KDE Frameworks 5.8

2015-03-07 Thread šumski 
On Saturday 07 of March 2015 17:24:17 David Faure wrote:
 Dear packagers,
 
 Here's KF 5.8.0
 
 New frameworks: kpeople and kxmlrpcclient.

A few things regarding kpeople:
It requires Qt 5.3, rest of KF5 5.2;
it uses strange version 0.5.0, rest of KF5 uses the same version as release; 
it uses DATA_INSTALL_DIR/$wanted_dir, rest of KF5 uses 
KDE_INSTALL_DATADIR_KF5/$wanted_dir (this is not about variable name, but 
location on the filesystem)


Cheers,
Hrvoje
 Public release on Thursday.
 
 Changelog will come later.
 
 Thanks for the packaging!


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: backwards compatibility how namespacing might help or not

2015-01-26 Thread šumski 
On Monday 26 of January 2015 17:22:49 Harald Sitter wrote:
 ahoy ahoy
 
 so...
 kf5.7 will contain kglobalacceld5
 plasma5.2 will also contain kglobalacceld5 if it was built with kf5.6
 
 this poses a binary conflict which makes kf5.7 not a simple drop-in
 replacement for kf5.6 without recompiling plasma, which effectively
 makes this new construct just like the old construct (kde sc) but with
 more repos :'
 
 problem:
 this presents a compatibility problem as (for example) kubuntu
 couldn't drop kf5.7 into an update of a released system without also
 rebuilding plasma-workspace.
 add on top of that the fact that plasma-workspace might do any
 arbitrary amount of things when built against kf5.7 (disable features,
 add features, explode, whatever) and it effectively disqualifies any
 frameworks release after 5.6 being landed in a manner where one can
 somewhat tightly control regression impact (at least to the
 understanding of ubuntu on how to make the scope as small as
 possible).
 this is not the advertised compatibility :P
 
 solution:
 everything ever should be namespaced somehow. kglobalacceld5 should
 have a kf5 suffix or prefix, headers should go into a kf5 directory,
 cmake packages should have kf5 somewhere in their name etc. etc.
 
 while discussing this on IRC the issue was raised that the artifacts
 installed by a framework couldn't possibly be kept 100% conflict free
 with the outside world. while that is of course true I propose that
 rigorous namespacing on our side kicks the ball to whoever conflicts
 with us and in general renders the likelihood rather small altogether.
 
 there are of course various additional considerations to be made and
 in particular when moving bits from plasma or even applications into
 frameworks a proper backwards compatible transition path ought to be
 worked out for each case specifically. so even with namespacing the
 grey cells need some exercise for sure.
 
 
 at the end of the day I suppose the question we need to answer is do
 we want to strive for 100% compatibility or is a best-effort
 compatibility good enough.
 
 best-effort sure is cheaper, it does however also mean that I doubt at
 least kubuntu will ever put frameworks releases into the regular
 updates procedure, preventing a good chunk of users from getting these
 releases. this is in of itself not a bad thing, but it does mean that
 a third party developer who wishes to target for example Ubuntu will
 have to jump through hoops to get the latest and greatest frameworks
 to the user.
 
 thoughts?
(not direct solution for the 'principle' of question, but at least in this 
case, we've had kglobalaccel5 daemon in a separate subpackage of the plasma-
workspace source on openSUSE, precisely as it was hinted already some time ago 
the merge might happen. we did the same with drkonqi.)

Cheers,
Hrvoje
 HS
 ___
 Kde-frameworks-devel mailing list
 Kde-frameworks-devel@kde.org
 https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework

2014-12-19 Thread šumski 
On Thursday 18 of December 2014 20:15:52 Martin Klapetek wrote:
 On Wed, Dec 17, 2014 at 9:11 PM, šumski hrvoje.sen...@gmail.com wrote:
  Hi,
  i've checked your clone, and what new requirements will that bring, and
  if the
  CMakeLists there are accurate, that will create a problem.
  We will have a dependency circle between kglobalaccel, kinit, kio and
  kxmlgui.
 
 Bah, I think you're correct. Basically the only link in this dep circle is
 KBookmarks
 using KActionCollection from xmlgui if I'm reading it correctly. If this is
 removed,
 then I think the circle would be gone.
KIO requires both KBookmarks and KXMLGui, so i am not sure how changing 
something in KBookmarks only would change the cycle...
One possible solution, but no idea would that be OK, is to make the 
kglobalaccel 'regular' executable, instead of a kdeinit one...


Cheers,
Hrvoje
 I checked the usage and it's not too much. Should it be attempted? Or what
 other
 options do we have?
 
 Cheers


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework

2014-12-17 Thread šumski 
On Monday 15 of December 2014 13:55:04 Martin Gräßlin wrote:
 On Friday 12 December 2014 12:38:20 Martin Klapetek wrote:
  On Fri, Oct 3, 2014 at 1:16 PM, Alex Merry alex.me...@kde.org wrote:
   On 2014-09-17 10:47, Martin Gräßlin wrote:
   Hi all,
   
   I just prepared moving kglobalacceld from plasma-workspace into
   kglobalaccel.
   You can find the code in my personal clone of kglobalaccel at [1] in
   branch
   master.
   
   The following steps were performed so far:
   * filter-branch on plasma-workspace to just have all kglobalacceld
   commits
   * move all files to src/runtime
   * merge code in kglobalaccel
   * adjust CMakeLists to find additionally needed dependencies for
   runtime part
   * raise tier to 3 in metadata
   
   Please have a look at it, whether I have forgotten something or should
   do something differently.
   
   Git history looks sensible.
   
Things I'm unsure about is:
   * how does the raise of framework needs to be reflected in cmake
   
   It doesn't.
   
* how do one expose the different licences?
   
   A License section in README.md?
   
* is it needed to export the new dependencies? After all they are just

   runtime
   deps?
   
   No, because they are not needed at compile-time by software that uses
   KGlobalAccel.
   
   Do we want an option to disable compilation of the runtime? Is the
   runtime needed on all platforms? I seem to remember some discussion
   suggesting it either wasn't or needn't be, but I can't remember the
   details.
   
   Alex
  
  Quoting from IRC just now: jleclanche we'd like to use it
  [kglobalaccel] in lxqt, but the framework is useless without its client
  atm
  
  Martin - what's the status of this? Is any help needed? Can we get this
  into Frameworks 5.6?
 
 Given the basically non-existing feedback on the thread (modulo Alex's
 reply) I would assume that everything is fine and we can just move the
 code. If you want to take care of it, I would certainly appreciate this.
Hi,
i've checked your clone, and what new requirements will that bring, and if the 
CMakeLists there are accurate, that will create a problem.
We will have a dependency circle between kglobalaccel, kinit, kio and kxmlgui.


Cheers,
Hrvoje

 Cheers
 Martin


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Move of kglobalacceld from plasma-workspace to kglobalaccel framework

2014-12-17 Thread šumski 
On Wednesday 17 of December 2014 21:11:04 šumski wrote:
 On Monday 15 of December 2014 13:55:04 Martin Gräßlin wrote:
  On Friday 12 December 2014 12:38:20 Martin Klapetek wrote:
   On Fri, Oct 3, 2014 at 1:16 PM, Alex Merry alex.me...@kde.org wrote:
On 2014-09-17 10:47, Martin Gräßlin wrote:
Hi all,

I just prepared moving kglobalacceld from plasma-workspace into
kglobalaccel.
You can find the code in my personal clone of kglobalaccel at [1] in
branch
master.

The following steps were performed so far:
* filter-branch on plasma-workspace to just have all kglobalacceld
commits
* move all files to src/runtime
* merge code in kglobalaccel
* adjust CMakeLists to find additionally needed dependencies for
runtime part
* raise tier to 3 in metadata

Please have a look at it, whether I have forgotten something or
should do something differently.

Git history looks sensible.

 Things I'm unsure about is:
* how does the raise of framework needs to be reflected in cmake

It doesn't.

 * how do one expose the different licences?

A License section in README.md?

 * is it needed to export the new dependencies? After all they are
 just
 
runtime
deps?

No, because they are not needed at compile-time by software that uses
KGlobalAccel.

Do we want an option to disable compilation of the runtime? Is the
runtime needed on all platforms? I seem to remember some discussion
suggesting it either wasn't or needn't be, but I can't remember the
details.

Alex
   
   Quoting from IRC just now: jleclanche we'd like to use it
   [kglobalaccel] in lxqt, but the framework is useless without its client
   atm
   
   Martin - what's the status of this? Is any help needed? Can we get this
   into Frameworks 5.6?
  
  Given the basically non-existing feedback on the thread (modulo Alex's
  reply) I would assume that everything is fine and we can just move the
  code. If you want to take care of it, I would certainly appreciate this.
 
 Hi,
 i've checked your clone, and what new requirements will that bring, and if
 the CMakeLists there are accurate, that will create a problem.
 We will have a dependency circle between kglobalaccel, kinit, kio and
 kxmlgui.

Another issue is the translation domain. It collides with kde-runtime's 
kglobalaccel translations, which would break KF5 co-installability...
 
 Cheers,
 Hrvoje
 
  Cheers
  Martin


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Build failed in Jenkins: kdelibs4support_master_qt5 #288

2014-10-23 Thread šumski 
On Tuesday 21 of October 2014 20:33:41 šumski wrote:
 On Tuesday 21 of October 2014 19:58:55 KDE CI System wrote:
  See http://build.kde.org/job/kdelibs4support_master_qt5/288/changes
 
 
 
  In file included from
  http://build.kde.org/job/kdelibs4support_master_qt5/ws/src/kssl/kssl.cpp
  
  
  :21:0:
  http://build.kde.org/job/kdelibs4support_master_qt5/ws/src/kssl/kssl.h:
  2 4:26: fatal error: ksslsettings.h: No such file or directory #include
  ksslsettings.h
  
^
  
  compilation terminated.
 
 Looks like somehow at least the last KIO build didn't install KSSLSettings
 header(s). Could be a new CMake regression?
 
So CMake release branch has a problem with ECMGenerateHeaders...
In particular, things go wrong when EGH_HEADER_NAMES matches 
EGH_REQUIRED_HEADERS. E.g. attached patch resolves the problem with 
KCoreAddons. Sending it, if it helps someone more familiar with CMake 
internals and/or ECMGenerateHeaders

 Cheers,
 Hrvoje
 
  ___
  Kde-frameworks-devel mailing list
  Kde-frameworks-devel@kde.org
  https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
diff --git a/src/lib/CMakeLists.txt b/src/lib/CMakeLists.txt
index 1dc5627..306a7c3 100644
--- a/src/lib/CMakeLists.txt
+++ b/src/lib/CMakeLists.txt
@@ -121,16 +121,16 @@ set_target_properties(KF5CoreAddons PROPERTIES VERSION   ${KCOREADDONS_VERSION_S
EXPORT_NAME CoreAddons
 )
 
-ecm_generate_headers(KCoreAddons_HEADERS
+ecm_generate_headers(KCoreAddons_CamelCase_HEADERS
 HEADER_NAMES KAboutData
 REQUIRED_HEADERS KCoreAddons_HEADERS
 )
-ecm_generate_headers(KCoreAddons_HEADERS
+ecm_generate_headers(KCoreAddons_CamelCase_HEADERS
 HEADER_NAMES KSharedDataCache
 RELATIVE caching
 REQUIRED_HEADERS KCoreAddons_HEADERS
 )
-ecm_generate_headers(KCoreAddons_HEADERS
+ecm_generate_headers(KCoreAddons_CamelCase_HEADERS
 HEADER_NAMES
 KAutoSaveFile
 KDirWatch
@@ -142,7 +142,7 @@ ecm_generate_headers(KCoreAddons_HEADERS
 RELATIVE io
 REQUIRED_HEADERS KCoreAddons_HEADERS
 )
-ecm_generate_headers(KCoreAddons_HEADERS
+ecm_generate_headers(KCoreAddons_CamelCase_HEADERS
 HEADER_NAMES
 KCompositeJob
 KJob
@@ -151,7 +151,7 @@ ecm_generate_headers(KCoreAddons_HEADERS
 RELATIVE jobs
 REQUIRED_HEADERS KCoreAddons_HEADERS
 )
-ecm_generate_headers(KCoreAddons_HEADERS
+ecm_generate_headers(KCoreAddons_CamelCase_HEADERS
 HEADER_NAMES
 KExportPlugin
 KPluginFactory
@@ -160,21 +160,21 @@ ecm_generate_headers(KCoreAddons_HEADERS
 RELATIVE plugin
 REQUIRED_HEADERS KCoreAddons_HEADERS
 )
-ecm_generate_headers(KCoreAddons_HEADERS
+ecm_generate_headers(KCoreAddons_CamelCase_HEADERS
 HEADER_NAMES
 KRandom
 KRandomSequence
 RELATIVE randomness
 REQUIRED_HEADERS KCoreAddons_HEADERS
 )
-ecm_generate_headers(KCoreAddons_HEADERS
+ecm_generate_headers(KCoreAddons_CamelCase_HEADERS
 HEADER_NAMES
 KMacroExpander
 KStringHandler
 RELATIVE text
 REQUIRED_HEADERS KCoreAddons_HEADERS
 )
-ecm_generate_headers(KCoreAddons_HEADERS
+ecm_generate_headers(KCoreAddons_CamelCase_HEADERS
 HEADER_NAMES
 KFormat
 KUser
@@ -189,6 +189,7 @@ install(TARGETS KF5CoreAddons EXPORT KF5CoreAddonsTargets ${KF5_INSTALL_TARGETS_
 
 install(FILES
 ${KCoreAddons_HEADERS}
+${KCoreAddons_CamelCase_HEADERS}
 ${CMAKE_CURRENT_BINARY_DIR}/kcoreaddons_export.h
 DESTINATION ${KF5_INCLUDE_INSTALL_DIR}/KCoreAddons COMPONENT Devel
 )


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Build failed in Jenkins: kdelibs4support_master_qt5 #288

2014-10-21 Thread šumski 
On Tuesday 21 of October 2014 19:58:55 KDE CI System wrote:
 See http://build.kde.org/job/kdelibs4support_master_qt5/288/changes

 In file included from
 http://build.kde.org/job/kdelibs4support_master_qt5/ws/src/kssl/kssl.cpp
 :21:0:
 http://build.kde.org/job/kdelibs4support_master_qt5/ws/src/kssl/kssl.h:2
 4:26: fatal error: ksslsettings.h: No such file or directory #include
 ksslsettings.h
   ^
 compilation terminated.

Looks like somehow at least the last KIO build didn't install KSSLSettings 
header(s). Could be a new CMake regression?


Cheers,
Hrvoje
 ___
 Kde-frameworks-devel mailing list
 Kde-frameworks-devel@kde.org
 https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KAuth and KF5

2014-06-30 Thread šumski 
On Monday 30 of June 2014 17:31:39 Thiago Macieira wrote:
 Em seg 30 jun 2014, às 14:14:10, Milian Wolff escreveu:
  On Monday 30 June 2014 00:05:10 šumski wrote:
   On Thursday 26 of June 2014 12:14:49 Milian Wolff wrote:
Hey,

did you run it through valgrind?
   
   Here's what valgrind says:
  Sounds like a bug in Qt to me, I have to say. Looking at the code,
  QDBusConnectionPrivate::objectDestroyed looks pretty fragile, I mean it
  does this at the end:
  
  obj-disconnect(this);
  
  But from the code in QDBusConnectionPrivate::disconnectSignal nothing
  jumps out as dangerous directly. The fact, that valgrind is getting
  confused in the stack trace is not helping either ;-) Could you maybe
  try to compile qtbase in debug mode and reproduce the issue, such that
  we get a full stacktrace without optimizations etc.?
  
  Anyways, maybe Thiago (CC'ed) can give us some insight on whats going on
  here.
 
 This is happening in a global destructor during the use of a global static.
 My guess would be that the global static has already been destroyed, hence
 the issue.
 
 Try this patch, which removes it. We have QStringLiteral nowadays.
Confirming that segfault no longer happens with the patch!


Cheers,
Hrvoje


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KAuth and KF5

2014-06-29 Thread šumski 
On Thursday 26 of June 2014 12:14:49 Milian Wolff wrote:
 Hey,
 
 did you run it through valgrind?
Here's what valgrind says:

==30114== Invalid read of size 8
==30114==at 0xDF080C1: 
QDBusConnectionPrivate::disconnectSignal(QHashQString, 
QDBusConnectionPrivate::SignalHook::iterator) (qstring.h:814)
==30114==by 0xDF08430: QDBusConnectionPrivate::objectDestroyed(QObject*) 
(qdbusintegrator.cpp:1227)
==30114==by 0xDF4F37B: 
QDBusConnectionPrivate::qt_static_metacall(QObject*, QMetaObject::Call, int, 
void**) (moc_qdbusconnection_p.cpp:131)
==30114==by 0x52F601D: QMetaObject::activate(QObject*, int, int, void**) 
(qobject.cpp:3680)
==30114==by 0x52F656E: QObject::destroyed(QObject*) (moc_qobject.cpp:205)
==30114==by 0x52FDA07: QObject::~QObject() (qobject.cpp:901)
==30114==by 0xDCD5228: PolkitQt1::Authority::~Authority() (polkitqt1-
authority.cpp:164)
==30114==by 0xDCD4DE1: PolkitQt1::(anonymous 
namespace)::Q_QGS_s_globalAuthority::innerFunction()::Holder::~Holder() 
(polkitqt1-authority.cpp:40)
==30114==by 0x5C62F78: __run_exit_handlers (in /lib64/libc-2.19.so)
==30114==by 0x5C62FC4: exit (in /lib64/libc-2.19.so)
==30114==by 0x5C4CB0B: (below main) (in /lib64/libc-2.19.so)
==30114==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==30114== 
==30114== 
==30114== Process terminating with default action of signal 11 (SIGSEGV)
==30114==  Access not within mapped region at address 0x0
==30114==at 0xDF080C1: 
QDBusConnectionPrivate::disconnectSignal(QHashQString, 
QDBusConnectionPrivate::SignalHook::iterator) (qstring.h:814)
==30114==by 0xDF08430: QDBusConnectionPrivate::objectDestroyed(QObject*) 
(qdbusintegrator.cpp:1227)
==30114==by 0xDF4F37B: 
QDBusConnectionPrivate::qt_static_metacall(QObject*, QMetaObject::Call, int, 
void**) (moc_qdbusconnection_p.cpp:131)
==30114==by 0x52F601D: QMetaObject::activate(QObject*, int, int, void**) 
(qobject.cpp:3680)
==30114==by 0x52F656E: QObject::destroyed(QObject*) (moc_qobject.cpp:205)
==30114==by 0x52FDA07: QObject::~QObject() (qobject.cpp:901)
==30114==by 0xDCD5228: PolkitQt1::Authority::~Authority() (polkitqt1-
authority.cpp:164)
==30114==by 0xDCD4DE1: PolkitQt1::(anonymous 
namespace)::Q_QGS_s_globalAuthority::innerFunction()::Holder::~Holder() 
(polkitqt1-authority.cpp:40)
==30114==by 0x5C62F78: __run_exit_handlers (in /lib64/libc-2.19.so)
==30114==by 0x5C62FC4: exit (in /lib64/libc-2.19.so)
==30114==by 0x5C4CB0B: (below main) (in /lib64/libc-2.19.so)


 On Wednesday 25 June 2014 23:17:29 Luca Beltrame wrote:
  šumski wrote:
   http://paste.opensuse.org/view/raw/45956382
  
  In case the pastebin link expires:
  
  #0  QString (other=..., this=0x7fff18fa23b0) at
  ../../src/corelib/tools/qstring.h:814
  #1  dbusInterfaceString () at qdbusintegrator.cpp:87
  #2  QDBusConnectionPrivate::disconnectSignal (this=this@entry=0xa93640,
  it=...) at qdbusintegrator.cpp:2270
  #3  0x7fde826414b1 in QDBusConnectionPrivate::objectDestroyed
  (this=0xa93640, obj=0xa6f720) at qdbusintegrator.cpp:1228
  #4  0x7fde826883bc in QDBusConnectionPrivate::qt_static_metacall
  (_o=optimized out, _c=optimized out, _id=optimized out,
  _a=optimized out)
  
  at .moc/moc_qdbusconnection_p.cpp:131
  
  #5  0x7fde83ebcd7e in QMetaObject::activate
  (sender=sender@entry=0xa6f720, signalOffset=optimized out,
  local_signal_index=local_signal_index@entry=0,
  
  argv=argv@entry=0x7fff18fa2610) at kernel/qobject.cpp:3680
  
  #6  0x7fde83ebd237 in QMetaObject::activate
  (sender=sender@entry=0xa6f720, m=m@entry=0x7fde842caf00
  QObject::staticMetaObject,
  
  local_signal_index=local_signal_index@entry=0,
  
  argv=argv@entry=0x7fff18fa2610) at kernel/qobject.cpp:3546
  #7  0x7fde83ebd2cf in QObject::destroyed (this=this@entry=0xa6f720,
  _t1=_t1@entry=0xa6f720) at .moc/moc_qobject.cpp:205
  #8  0x7fde83ec4768 in QObject::~QObject (this=0xa6f720,
  __in_chrg=optimized out) at kernel/qobject.cpp:901
  #9  0x7fde7b36ae39 in PolkitQt1::Authority::~Authority
  (this=0xa6f720, __in_chrg=optimized out)
  
  at
  /usr/src/debug/polkit-qt-1-0.103.0/core/polkitqt1-authority.cpp:164
  
  #10 0x7fde7b36aa62 in PolkitQt1::(anonymous
  namespace)::Q_QGS_s_globalAuthority::innerFunction()::Holder::~Holder()
  ()
  
  at /usr/src/debug/polkit-qt-1-0.103.0/core/polkitqt1-authority.cpp:40
  
  #11 0x7fde8337df99 in __run_exit_handlers () from /lib64/libc.so.6
  #12 0x7fde8337dfe5 in exit () from /lib64/libc.so.6
  #13 0x7fde83367b0c in __libc_start_main () from /lib64/libc.so.6
  #14 0x00402021 in _start () at ../sysdeps/x86_64/start.S:122


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KAuth and KF5

2014-06-25 Thread šumski 
On Wednesday 25 of June 2014 11:40:35 Milian Wolff wrote:
 On Tuesday 24 June 2014 23:44:12 Luca Beltrame wrote:
  Hello,
  
  currently, the KF5 version of KAuth is not quite usable as any helper
  used by KAuth segfaults: the most notable is backlighthelper, which
  always crashes at login.
  
  According to some investigations made by a fellow openSUSE Community KDE
  member, it crashes somewhere in Qt, in dbusInterfaceString().
  I've tried myself to get a backtrace but gdb offers no stack
  
  Given that the release is so close by and that KAuth is used by a lot of
  pieces in the upcoming workspace release:
  
  1. How can this be debugged further?
  2. Has anyone been able to reproduce this?
  3. Is this something different entirely?
  
  Basically this makes KAuth non-functional.
  
  I'm hoping this is only a local issue, though, ;)
 
 Just a quick question to make sure this is not the issue: Have you ruled
 out ABI/linker issues? I've seen a case where a kf5 app tried to load a
 Qt4 plugin/library, which lead to _very_ strange crashes. You can make
 sure that's not the case by doing something like ldd on any exe/lib
 involved. Furthermore, try info shared in gdb on crash.

Is not in this case. ATM we're using r118264 to avoid above situation...
Anyways, got now a better trace, seems it's comming from polkitqt1-authority 
destructor:
http://paste.opensuse.org/view/raw/45956382


Cheers,
Hrvoje
 Bye


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Plasma 5 Beta 2 tars

2014-06-12 Thread šumski 
On Thursday 12 of June 2014 14:53:57 Marco Martin wrote:
 On Wednesday 11 June 2014, šumski wrote:
  Unfortunately, we cannot touch the buildhost, only sources which are
  built (and i'm running x86_64 OS).
  You might be right about kde_file, though seems to be a namespace
  clash/mixup. The attached patch resolves the failure here (basically
  renaming stat method to statFont)
  Might not be the best way to go forward, but might provide some clues
  what's wrong.
 
 Hrvoje,
 I think that patch is the way to go, can you push it?
Sure,
i was only concerned about having two similar names, before where FontStat and 
stat methods, now would be FontStat and StatFont =)


Cheers,
Hrvoje


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Plasma 5 Beta 2 tars

2014-06-11 Thread šumski 
On Wednesday 11 of June 2014 17:07:04 Sebastian Kügler wrote:
 [CC:ing frameworks-devel, hoping for additional input]
 
 On Friday, June 06, 2014 23:24:50 šumski wrote:
  On Friday 06 of June 2014 21:32:48 Eric Hameleers wrote:
   On Fri, 6 Jun 2014, ?umski wrote:
On Thursday 05 of June 2014 16:47:59 Jonathan Riddell wrote:
Tars are up for Plasma 5 Beta 2, please try them out and let me know
of problems.  I'd especially like to know if translations
successfully install as I noticed some not doing so last time.

khotkeys also don't build, they have one
ecm_optional_add_subdirectory(doc)
too many ;-)


Cheers,
Hrvoje
   
   I got that error too in khelpcenter kinfocenter and kio-extras. That's
   where I stopped trying to compile this until the tarballs get fixed.
  
  Other then these issues present in tarball only (not git), there is an
  ongoing problem with plasma-desktop which blocks creating proper 32bit
  packages: http://paste.opensuse.org/25338349
  
  build succeeds on 64bit builds. with our daily packages we've just used:
  sed -i 's|add_subdirectory( dbus )|#add_subdirectory( dbus )|g'
  kcms/kfontinst/CMakeLists.txt
  but this cannot go in distributions...
 
 It seems that the #defines in
 frameworks/kdelibs4support/src/kdecore/kde_file.h get mixed up, but I have
 to say I'm not portability guy enough to know which defines should
 trigger when. Input is most welcome here...
 
 Hrvoje, Jonathan: Could you perhaps try modifying it there locally, and see
 if the build succeeds then? (Should be enough to make sure the #else /*
 unix */ branch is evaluated, instead of the ones that point the KDE_lstat,
 KDE_stat, etc. to *64 versions.
Unfortunately, we cannot touch the buildhost, only sources which are built 
(and i'm running x86_64 OS).
You might be right about kde_file, though seems to be a namespace clash/mixup.
The attached patch resolves the failure here (basically renaming stat method 
to statFont)
Might not be the best way to go forward, but might provide some clues what's 
wrong.


Cheers,
Hrvoje

 Cheers,
diff --git a/kcms/kfontinst/dbus/FontInst.cpp b/kcms/kfontinst/dbus/FontInst.cpp
index 637d7a2..42413c1 100644
--- a/kcms/kfontinst/dbus/FontInst.cpp
+++ b/kcms/kfontinst/dbus/FontInst.cpp
@@ -157,7 +157,7 @@ void FontInst::list(int folders, int pid)
 emit fontList(pid, fonts);
 }
 
-void FontInst::stat(const QString name, int folders, int pid)
+void FontInst::statFont(const QString name, int folders, int pid)
 {
 KFI_DBUG  name  folders  pid;
 
diff --git a/kcms/kfontinst/dbus/FontInst.h b/kcms/kfontinst/dbus/FontInst.h
index 1365efd..01183db 100644
--- a/kcms/kfontinst/dbus/FontInst.h
+++ b/kcms/kfontinst/dbus/FontInst.h
@@ -104,7 +104,7 @@ class KFONTINST_EXPORT FontInst : public QObject
 public Q_SLOTS:
 
 Q_NOREPLYvoidlist(int folders, int pid);
-Q_NOREPLYvoidstat(const QString font, int folders, int pid);
+Q_NOREPLYvoidstatFont(const QString font, int folders, int pid);
 Q_NOREPLYvoidinstall(const QString file, bool createAfm, bool toSystem, int pid, bool checkConfig);
 Q_NOREPLYvoiduninstall(const QString family, quint32 style, bool fromSystem, int pid, bool checkConfig);
 Q_NOREPLYvoiduninstall(const QString name, bool fromSystem, int pid, bool checkConfig);
diff --git a/kcms/kfontinst/dbus/FontinstIface.cpp b/kcms/kfontinst/dbus/FontinstIface.cpp
index e27cbbb..174ac51 100644
--- a/kcms/kfontinst/dbus/FontinstIface.cpp
+++ b/kcms/kfontinst/dbus/FontinstIface.cpp
@@ -1,8 +1,8 @@
 /*
- * This file was generated by qdbusxml2cpp version 0.7
+ * This file was generated by qdbusxml2cpp version 0.8
  * Command line was: qdbusxml2cpp -m -p FontinstIface org.kde.fontinst.xml -i Family.h
  *
- * qdbusxml2cpp is Copyright (C) 2011 Nokia Corporation and/or its subsidiary(-ies).
+ * qdbusxml2cpp is Copyright (C) 2014 Digia Plc and/or its subsidiary(-ies).
  *
  * This is an auto-generated file.
  * This file may have been hand-edited. Look for HAND-EDIT comments
diff --git a/kcms/kfontinst/dbus/FontinstIface.h b/kcms/kfontinst/dbus/FontinstIface.h
index 2a59cbe..cb1b9ce 100644
--- a/kcms/kfontinst/dbus/FontinstIface.h
+++ b/kcms/kfontinst/dbus/FontinstIface.h
@@ -1,15 +1,15 @@
 /*
- * This file was generated by qdbusxml2cpp version 0.7
+ * This file was generated by qdbusxml2cpp version 0.8
  * Command line was: qdbusxml2cpp -m -p FontinstIface org.kde.fontinst.xml -i Family.h
  *
- * qdbusxml2cpp is Copyright (C) 2011 Nokia Corporation and/or its subsidiary(-ies).
+ * qdbusxml2cpp is Copyright (C) 2014 Digia Plc and/or its subsidiary(-ies).
  *
  * This is an auto-generated file.
  * Do not edit! All changes made to it will be lost.
  */
 
-#ifndef FONTINSTIFACE_H
-#define FONTINSTIFACE_H
+#ifndef FONTINSTIFACE_H_1402519768
+#define FONTINSTIFACE_H_1402519768
 
 #include QtCore/QObject
 #include QtCore/QByteArray
@@ -40,56 +40,56 @@ public Q_SLOTS: // METHODS

Re: Update your copy of extra-cmake-modules

2014-04-21 Thread šumski 
On Friday 18 of April 2014 10:37:50 Aurélien Gâteau wrote:
...
 I made it that way intentionally because I consider it bad to have different
 code generated depending on whether you have the framework is built from a
 release tarball or from git.
 
 I understand this means more build dependencies for packagers, but I don't
 see any other way.

Understood. Wrt the packaging, that can be more or less bypassed (and i've 
done so already with openSUSE Qt5 packages), but i was also curious about 
additional dependencies in general. E.g. with KArchive, previously only QtCore 
was needed to get it built. Now people will need to build e.g. qtdeclarative 
and qtwebkit to get qttools, which is now hard requirement for KArchive (note 
that i haven't checked is ECMCreateQmFromPoFiles added specifically to 
KArchive, but this is applied to any such Framework).

Cheers,
Hrvoje
 Aurélien
 
 ___
 Kde-frameworks-devel mailing list
 Kde-frameworks-devel@kde.org
 https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Update your copy of extra-cmake-modules

2014-04-16 Thread šumski 
On Wednesday 16 of April 2014 07:36:57 Aurélien Gâteau wrote:
 Hi,
 
 I just pushed some changes to frameworks using Qt for translations which
 requires a recent version of extra-cmake-modules (you need to have
 071581a3f899c881c9938efd082fd32589822b45). If you get build failures
 complaining about an unknown ecm_create_qm_loader, then you need to
 update.
Hi Aurélien,
would it be possible to leave the previous logic in Frameworks? With these 
changes all frameworks always include ECMCreateQmFromPoFiles, which require 
development files for qttools, which then requires QtGui and QtWidgets 
development files, which require ... etc ;-)
Just curious.

Cheers,
Hrvoje

 Aurélien
 ___
 Kde-frameworks-devel mailing list
 Kde-frameworks-devel@kde.org
 https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KItemModels, Solid KJS licenses

2014-04-07 Thread šumski 
On Wednesday 19 of February 2014 21:18:31 šumski wrote:
 Hi all,
 
 i've started pushing Frameworks to openSUSE Factory (i.e. next openSUSE
 release), and our legal review found some issues[1][2][3] with mentioned
 frameworks licenses.
 ...

Last items =)
KRunner and KActivities are missing COPYING(.LIB), but the 'biggest' remaining 
issue is kde4support, quote:

The spec file states only that the package is LGPL-2.1+ licensed. Indeed, the
predominant license in the source code files does appear to be LGPL-2.1.
However, there are instances of other licenses. If this cpp code is compiled 
with the rest of the LGPL-2.1+ licensed kde4support code, it could be said 
that the resulting work must be licensed under the GPL-2.0 - this would have a 
material effect on the overall license of kdesupport4.

Should kde4support be declared as GPL-2.0?

TIA, and cheers,
Hrvoje

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KItemModels, Solid KJS licenses

2014-04-07 Thread šumski 
On Monday 07 of April 2014 22:30:43 Albert Astals Cid wrote:
 El Dilluns, 7 d'abril de 2014, a les 22:24:44, šumski va escriure:
  On Wednesday 19 of February 2014 21:18:31 šumski wrote:
   Hi all,
   
   i've started pushing Frameworks to openSUSE Factory (i.e. next openSUSE
   release), and our legal review found some issues[1][2][3] with mentioned
   frameworks licenses.
   ...
  
  Last items =)
  KRunner and KActivities are missing COPYING(.LIB), but the 'biggest'
  remaining issue is kde4support, quote:
  
  The spec file states only that the package is LGPL-2.1+ licensed. Indeed,
  the predominant license in the source code files does appear to be
  LGPL-2.1. However, there are instances of other licenses. If this cpp code
  is compiled with the rest of the LGPL-2.1+ licensed kde4support code, it
  could be said that the resulting work must be licensed under the GPL-2.0 -
  this would have a material effect on the overall license of kdesupport4.
  
  Should kde4support be declared as GPL-2.0?
 
 That's a bit weird, kdelibs has always (afaicr) been LGPL-compatible (i.e.
 LPGL or BSD/MIT, etc). so why would we have to declare kde4support (a subset
 of kdelibs) GPL-2?

I haven't checked all files, neither in kdelibs neither in kde4support. Our 
legal came with the indication about src/kssl/kssl/cert_extract.cpp.
Quick grep showed me that they are only a few files in there (in src/kssl/) 
with GPL-2, and they produce a kcm plugin, and ca-bundle/calist. So yeah, 
declaring kde4support as GPL-2 indeed doesn't make sense ;-)


Cheers,
Hrvoje

 Cheers,
   Albert
 
  TIA, and cheers,
  Hrvoje
 
 ___
 Kde-frameworks-devel mailing list
 Kde-frameworks-devel@kde.org
 https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KItemModels, Solid KJS licenses

2014-03-17 Thread šumski 
On Wednesday 19 of February 2014 21:18:31 šumski wrote:
 Hi all,
 
 i've started pushing Frameworks to openSUSE Factory (i.e. next openSUSE
 release), and our legal review found some issues[1][2][3] with mentioned
 frameworks licenses.
...

Next one, kinit[1]:
src/kdeinit/proctitle.cpp and src/kdeinit/proctitle.h are GPL-2.0+ licensed. 
This could mean the license of kinit must be GPL-2.0+, not LGPL-2.1+, which 
could be _very_ unexpected. Please check with upstream

Alex, this one seems 'yours', could you take a look at the two files?


Cheers,
Hrvoje

[1] https://build.opensuse.org/request/show/226082


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KItemModels, Solid KJS licenses

2014-03-03 Thread šumski 
On Wednesday 19 of February 2014 21:18:31 šumski wrote:
 Hi all,
 
 i've started pushing Frameworks to openSUSE Factory (i.e. next openSUSE
 release), and our legal review found some issues[1][2][3] with mentioned
 frameworks licenses.



Ok, after next batch, issue came up with kwallet[1], @Valentin, George, what 
say you? Can those files be relicensed, or shall they be left as-is?

Cheers,
Hrvoje


[1] https://build.opensuse.org/request/show/224300


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KItemModels, Solid KJS licenses

2014-03-03 Thread šumski 
On Monday 03 of March 2014 16:20:20 George Staikos wrote:
 What license are you asking for? Sorry I haven't read the back info and
 don't feel like digging. :)
 

Quote:
kwallet-framework-4.96.0/src/runtime/kwalletd/kbetterthankdialog.(cpp|h) and 
kwallet-framework-4.96.0/src/runtime/kwalletd/kwalletwizard.(.cpp|.h) are both 
GPL-2.0+ licensed. Can you check with upstream if this is known/intended. If 
intended, the license should be LGPL-2.1+ and GPL-2.0+ (unless the GPL-2.0+ 
files are linked with the LGPL-2.1+ files so as that a resulting derived work 
is 
created - which should be GPL-2.0+ licensed).

Question is now, can those files be relicensed to LGPL-2.1+ ?


Cheers,
Hrvoje

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KItemModels, Solid KJS licenses

2014-02-26 Thread šumski 
On Thursday 20 of February 2014 11:41:48 Alex Merry wrote:
 CC'd people: please can you confirm that you would be happy to have the
 files listed below relicensed from GPL to LGPLv2+?

Small ping :)
It would be awesome if we could get this sorted for alpha2


Cheers,
Hrvoje
 ___
 Kde-frameworks-devel mailing list
 Kde-frameworks-devel@kde.org
 https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: setting SOVERSION to 5

2014-02-25 Thread šumski 
On Tuesday 25 of February 2014 18:45:15 Kevin Ottens wrote:
 On Tuesday 25 February 2014 17:12:37 Jonathan Riddell wrote:
  On Tue, Feb 25, 2014 at 04:55:43PM +0100, Kevin Ottens wrote:
   OK, but then the said change is either in the packaging or in our own
   cmake
   files as we'd have to drop the SOVERSION later on when our version
   becomes
   5.0.0. So it's really a question of which is more error prone.
  
  No change would be needed in the KF5 sources, SOVERSION would be set to 5
  now and until KF6 comes along.
 
 I'm not fond of keeping duplicated information like that... but indeed
 that's an option as well. Now I wonder though: what was Hrvoje's objection
 exactly?

After reading all replies, i guess it does makes sense to have soversion at 5 
(already). 
(i.e. it 'shouldn't' have been downgraded to 4 for first alpha - but just the 
soversion ;-), even though the soversion is kinda contained in library names)
My objection was based on that we'll have a 4.96.0 release with so.4, and then 
suddenly with 4.97.0 at 5...


Cheers,
Hrvoje

 Regards.


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KItemModels, Solid KJS licenses

2014-02-22 Thread šumski 
On Saturday 22 of February 2014 17:39:33 Alex Merry wrote:
 On 20/02/14 16:00, šumski wrote:
  KItemModels are even more GPL, than LGPLv2+, 'only'
  main.cpp, lessthanwidget.(cpp|h), mainwindow.(cpp|h),
  selectionpmwidget.(cpp|h), descendantpmwidget.(cpp|h),
  recursivefilterpmwidget.(cpp|h), reparentingpmwidget.(cpp|h)
  and proxymodeltestwidget.(cpp|h) (all from autotests/proxymodeltestapp/)
  are LGPLv2+, the rest is GPL.
 
 Huh?  As far as I can see, the only file in autotests/ with a GPL
 license is proxymodeltestsuite/modeltest.(cpp|h).  Everything else is
 either Library GPL or Lesser GPL.  Well, or doesn't have a license at
 all (eg: python files, but those contain fewer than 10 logical lines of
 code, so are probably not copyrightable).

Indeed, grep fooled me || read without cofee...
Sorry for the confusion.


Cheers,
Hrvoje
 
 Alex


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KItemModels, Solid KJS licenses

2014-02-20 Thread šumski 
On Thursday 20 of February 2014 11:41:48 Alex Merry wrote:
...
 KItemModels
 
 kcheckableproxymodel.(cpp|h) is Stephen Kelly (and, for safety, David
 Faure).
 
 modeltest.(cpp|h) were taken from Qt Concurrent, and subsequently
 modified by Stephen Kelly, and touched by David Faure and Aurélien
 Gâteau (but I don't think the latter two count as copyright holders,
 judging from the commit messages).
 
 David is on record as being happy with relicensing to LGPLv2+ (with or
 without the e.V. clause) - see relicensecheck.pl in kde:kde-dev-scripts.
 
  [1] https://build.opensuse.org/request/show/223093
 

KItemModels are even more GPL, than LGPLv2+, 'only'
main.cpp, lessthanwidget.(cpp|h), mainwindow.(cpp|h),
selectionpmwidget.(cpp|h), descendantpmwidget.(cpp|h),
recursivefilterpmwidget.(cpp|h), reparentingpmwidget.(cpp|h)
and proxymodeltestwidget.(cpp|h) (all from autotests/proxymodeltestapp/)
are LGPLv2+, the rest is GPL.

Cheers,
Hrvoje


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Build failed in Jenkins: kde4support_master_qt5 #32

2014-01-24 Thread šumski 
On Friday 24 of January 2014 09:53:00 Ben Cooksley wrote:
 There has been no changes in regards to the compiler, etc. on
 build.kde.org in the past few weeks.
 The only thing that could have changed would be the version of CMake -
 as we follow the 'next' branch, so this could be a CMake regression.

Hi Ben, Christoph,
actually, this seems like a regression within one of frameworks, or e-c-m. 
Last build of kde4support went fine on openSUSE's OBS[1] few hours ago, 
however, after updating and rebuilding all frameworks in their dependency 
chain - build fails. Used CMake version there is 2.8.12.1.

Cheers,
Hrvoje


[1] 
https://build.opensuse.org/package/show/KDE:Unstable:Frameworks/kde4support


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Compiling Plasma-Framework with a QT5 compiled with -egl -opengl es2

2013-11-23 Thread šumski 
On Monday 14 of October 2013 16:40:03 Martin Gräßlin wrote:
 it shouldn't require es2. It's obvious that it needs egl, but it shouldn't
 need es2. If it does that would be clearly an upstream bug. KWin 4.11 for
 Wayland requires egl, but doesn't work with es2.
...
 What if you add the -egl and not the -opengl es2? Egl is an own library and
 not part of opengles.
Building egl without es2 works with current stable branch/will work with Qt 
5.2.1.
Still the original problem remains: plasma-framework will not build with es2 
enabled Qt (and without the mentioned workaround applied). Maybe similar 
approach as with KWin can be used there also?

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel