Review Request: Move checks for locking primitives in KSharedDataCache to CMake
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106174/ --- Review request for kdelibs and Michael Pyne. Description --- This patch does move some run-time checks (mainly for different locking mechanisms) in KSharedDataCache to build time (CMake). This addresses bug 305023. http://bugs.kde.org/show_bug.cgi?id=305023 Diffs - kdecore/util/config-util.h.cmake 83ccdf7 kdecore/util/kshareddatacache.cpp 393902e kdecore/util/kshareddatacache_p.h ec5a7a0 kdecore/util/ConfigureChecks.cmake fe9f47e Diff: http://git.reviewboard.kde.org/r/106174/diff/ Testing --- On OpenBSD-CURRENT. Thanks, Vadim Zhukov
Review Request: Mutex cleanup in KSharedDataCache
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106221/ --- Review request for kdelibs and Michael Pyne. Description --- - Remove support for thread-shared-only locks: they do not help at all but makes app crash instead of slowly work; lack of decent locks to be resolved later. - Add error checking with console printouts. - Consistently use :: before global functions. Probably failed mutexes should be destroyed in case of some errors, any thoughts? This addresses bug 305023. http://bugs.kde.org/show_bug.cgi?id=305023 Diffs - kdecore/util/kshareddatacache_p.h ec5a7a0 kdecore/util/kshareddatacache.cpp 393902e Diff: http://git.reviewboard.kde.org/r/106221/diff/ Testing --- On OpenBSD-CURRENT. Thanks, Vadim Zhukov
Re: Review Request: Mutex cleanup in KSharedDataCache
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106221/ --- (Updated Aug. 26, 2012, 7:02 p.m.) Review request for kdelibs and Michael Pyne. Changes --- Fixed lie in comment. Description --- - Remove support for thread-shared-only locks: they do not help at all but makes app crash instead of slowly work; lack of decent locks to be resolved later. - Add error checking with console printouts. - Consistently use :: before global functions. Probably failed mutexes should be destroyed in case of some errors, any thoughts? This addresses bug 305023. http://bugs.kde.org/show_bug.cgi?id=305023 Diffs (updated) - kdecore/util/kshareddatacache.cpp 393902e kdecore/util/kshareddatacache_p.h ec5a7a0 Diff: http://git.reviewboard.kde.org/r/106221/diff/ Testing --- On OpenBSD-CURRENT. Thanks, Vadim Zhukov
Review Request: Add spinlocks lock type, based on GCC intrisincs
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106224/ --- Review request for kdelibs and Michael Pyne. Description --- Add simple spin locking mechanism. Written by Michael Pyne as from https://bugs.kde.org/attachment.cgi?id=73282 , with some tweaking by me. This addresses bug 305023. http://bugs.kde.org/show_bug.cgi?id=305023 Diffs - kdecore/util/ConfigureChecks.cmake fe9f47e kdecore/util/config-util.h.cmake 83ccdf7 kdecore/util/kshareddatacache_p.h ec5a7a0 Diff: http://git.reviewboard.kde.org/r/106224/diff/ Testing --- On OpenBSD-CURRENT, i386 Thanks, Vadim Zhukov
Re: Review Request: Mutex cleanup in KSharedDataCache
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106221/ --- (Updated Aug. 27, 2012, 8:50 a.m.) Review request for kdelibs and Michael Pyne. Changes --- Added error text printing, as requested by mpyne@. Please note: strerror() is not thread-safe, so we have to use strerror_r(), which doesn't exists everywhere. So I've added another CMake check, and if it fails, still print error code directly. Description --- - Remove support for thread-shared-only locks: they do not help at all but makes app crash instead of slowly work; lack of decent locks to be resolved later. - Add error checking with console printouts. - Consistently use :: before global functions. Probably failed mutexes should be destroyed in case of some errors, any thoughts? This addresses bug 305023. http://bugs.kde.org/show_bug.cgi?id=305023 Diffs (updated) - kdecore/util/ConfigureChecks.cmake fe9f47e kdecore/util/config-util.h.cmake 83ccdf7 kdecore/util/kshareddatacache.cpp 393902e kdecore/util/kshareddatacache_p.h ec5a7a0 Diff: http://git.reviewboard.kde.org/r/106221/diff/ Testing --- On OpenBSD-CURRENT. Thanks, Vadim Zhukov
Re: Review Request: Move checks for locking primitives in KSharedDataCache to CMake
On Aug. 26, 2012, 9:35 p.m., Michael Pyne wrote:
I've looked over everything and didn't see anything I didn't like. I'd like
to apply and and compile and run what little test cases do exist, but
git-apply won't run as kdecore/util/{ConfigureChecks,config-util.h}.cmake
don't exist yet. Are those from stray commits on your end or is there an
earlier review request that includes them?
I'm trying to apply to KDE/4.10 as this is not strictly a bugfix, though I
didn't see either of those in KDE/4.9 or frameworks branches either.
Hm-m-m, I've checked out trunk of kdelibs... See the log of my repo:
commit 2975583acb23334efc2f13860d0f9c36462c4524
Author: Vadim Zhukov persg...@gmail.com
Date: Mon Aug 27 12:01:31 2012 +0400
Improve error printing, and mention another (related) reason to avoid
semaphores.
commit 487edb5e59b16edb63c70d3100dc1c9cc608eea8
Author: Vadim Zhukov persg...@gmail.com
Date: Sun Aug 26 22:30:12 2012 +0400
- Remove support for thread-shared-only locks: they do not help at all
but makes app crash instead of slowly work; lack of decent locks to be resolved
later.
- Add error checking with console printouts.
- Consistently use :: before global functions.
commit 04adbc24f5bc14828fcd8da84a322993df4a8f35
Author: Vadim Zhukov persg...@gmail.com
Date: Sun Aug 26 21:17:12 2012 +0400
Move checks for functionality (especially locking mechanisms) to CMake.
commit 8af088493827cb1eaf6bb4aa4df89f2147986a1a
Merge: 58fd025 fed5ee7
Author: David Faure fa...@kde.org
Date: Thu Aug 16 11:04:58 2012 +0200
Merge branch 'KDE/4.10'
commit 0e8325376aefb912ab318c2795f276fc23a9837c
Author: Sergio Martins iamser...@gmail.com
Date: Tue Aug 14 23:16:51 2012 +0100
s/newer then/newer than
(cherry picked from commit fef8d2c8ce38c735cbf2fa196006ead991a17171)
commit 75328c0cc379d80f179ce77fc66d19706290a674
Merge: 557c126 c67bfaf
Author: David Faure fa...@kde.org
Date: Fri Jul 20 13:23:52 2012 +0200
Merge branch 'KDE/4.9'
commit d178c64d53fcc6ab50d35c4f178b21322b7fa357
Author: Michael Pyne mp...@kde.org
Date: Sat Jun 16 23:32:09 2012 -0400
kshareddatacache: Correct the findEmptyPages loop boundary.
I did review the last patch to remove 'pagesNeeded' from the loop test,
but I missed that it has '+ 1' instead of '- 1' (which is still too
conservative). The correct thing is to not have any addition at all
since we use operator() for the test.
Graciously pointed out by kde_pepo, thanks!
- Vadim
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106174/#review18055
---
On Aug. 26, 2012, 5:15 p.m., Vadim Zhukov wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106174/
---
(Updated Aug. 26, 2012, 5:15 p.m.)
Review request for kdelibs and Michael Pyne.
Description
---
This patch does move some run-time checks (mainly for different locking
mechanisms) in KSharedDataCache to build time (CMake).
This addresses bug 305023.
http://bugs.kde.org/show_bug.cgi?id=305023
Diffs
-
kdecore/util/config-util.h.cmake 83ccdf7
kdecore/util/kshareddatacache.cpp 393902e
kdecore/util/kshareddatacache_p.h ec5a7a0
kdecore/util/ConfigureChecks.cmake fe9f47e
Diff: http://git.reviewboard.kde.org/r/106174/diff/
Testing
---
On OpenBSD-CURRENT.
Thanks,
Vadim Zhukov
Re: Review Request: Move checks for locking primitives in KSharedDataCache to CMake
On Aug. 27, 2012, 3:57 p.m., Alexander Neundorf wrote: Why do you want to do this ? Beside that, you are using CMakePushCheckState.cmake, which is part of cmake only since version 2.8.6. trunk still requires cmake 2.6.4, so this is not allowed, use MacroPushrequiredVars.cmake, which we have in kdelibs, instead. Why do you want to do this ? Because it makes things simplier and more stable: switching to CMake tests makes KDE looking for actual functionality instead of trusting OS; see comments about OS X in code removed by this patch from kshareddatacache_p.h for example of OS lie. I've left compiling all locks supported by OS, so, after live update, old lock types will be still available and will be used because KShareDataCache runs detection code only when creating cache from scratch. Beside that, you are using CMakePushCheckState.cmake, which is part of cmake only since version 2.8.6. trunk still requires cmake 2.6.4, so this is not allowed, use MacroPushrequiredVars.cmake, which we have in kdelibs, instead. Acknowledged. I'm from OpenBSD land, we have CMake 2.8 there for a while (I was working on update too) and forgot that you still support older ones. Fixed diff to follow in a few minutes. - Vadim --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106174/#review18113 --- On Aug. 26, 2012, 5:15 p.m., Vadim Zhukov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106174/ --- (Updated Aug. 26, 2012, 5:15 p.m.) Review request for kdelibs and Michael Pyne. Description --- This patch does move some run-time checks (mainly for different locking mechanisms) in KSharedDataCache to build time (CMake). This addresses bug 305023. http://bugs.kde.org/show_bug.cgi?id=305023 Diffs - kdecore/util/config-util.h.cmake 83ccdf7 kdecore/util/kshareddatacache.cpp 393902e kdecore/util/kshareddatacache_p.h ec5a7a0 kdecore/util/ConfigureChecks.cmake fe9f47e Diff: http://git.reviewboard.kde.org/r/106174/diff/ Testing --- On OpenBSD-CURRENT. Thanks, Vadim Zhukov
Re: Review Request: Move checks for locking primitives in KSharedDataCache to CMake
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106174/ --- (Updated Aug. 27, 2012, 6:54 p.m.) Review request for kdelibs and Michael Pyne. Changes --- Fixed a bug in test for pthread_mutex_timedlock() that forced test always fail. Also made whitespace style more consistent with other code. Description --- This patch does move some run-time checks (mainly for different locking mechanisms) in KSharedDataCache to build time (CMake). This addresses bug 305023. http://bugs.kde.org/show_bug.cgi?id=305023 Diffs (updated) - kdecore/util/ConfigureChecks.cmake fe9f47e kdecore/util/config-util.h.cmake 83ccdf7 kdecore/util/kshareddatacache.cpp 393902e kdecore/util/kshareddatacache_p.h ec5a7a0 Diff: http://git.reviewboard.kde.org/r/106174/diff/ Testing --- On OpenBSD-CURRENT. Thanks, Vadim Zhukov
Re: Review Request: Move checks for locking primitives in KSharedDataCache to CMake
04.09.2012 1:08 пользователь Michael Pyne mp...@kde.org написал: This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106174/ I think I've figured out the issue with the missing files. The review request is indeed based against master, which isn't a big problem. If rebasing to KDE/4.10 will be an issue just let me know and I'll integrate the latest diff myself to KDE/4.10. I'm on a vacation now, but I think 4.10 stuff can wait two more weeks. :) I'll send a diff against 4.10 too then. On August 27th, 2012, 6:54 p.m., Vadim Zhukov wrote: Review request for kdelibs and Michael Pyne. By Vadim Zhukov. Updated Aug. 27, 2012, 6:54 p.m. Description This patch does move some run-time checks (mainly for different locking mechanisms) in KSharedDataCache to build time (CMake). Testing On OpenBSD-CURRENT. Bugs: 305023 Diffs kdecore/util/ConfigureChecks.cmake (fe9f47e) kdecore/util/config-util.h.cmake (83ccdf7) kdecore/util/kshareddatacache.cpp (393902e) kdecore/util/kshareddatacache_p.h (ec5a7a0) View Diff
Re: Use of bin versus libexec
Hello all. Sorry for messing around here (I'm not a KDE developer) but in case anyone interested in OpenBSD look, I'll try to present it here via some thoughts and facts. 1. OpenBSD doesn't care about FHS, and all *nix except Linux distros do not care either. Because FHS is Linux-only itself. 2. Due to (1) some folders should be placed in other, errrm, places. Particularly, libexec folder for non-base packages should be /usr/local/libexec/, not something in */lib/. Unfortunately, while there exists KDE_LIBEXEC_DIR (if I recall correctly) CMake configuration option, it's ignored in many places. 3. I've patches for stuff in KDE 4.9 that got hardcoded in $KDELIBDIR/kde4/libexec. Runs more or less fine here, but not polished yet. If anyone is interested, I could publish them on review board. 20.09.2012 15:47 пользователь Jonathan Marten j...@keelhaul.demon.co.uk написал: There are a lot of executables in $KDEDIR/bin which are used for internal purposes within KDE and are not intended to be directly executed by the end user. Having these in the user's $PATH is not necessary and has overheads for the shell (and for the user, when doing tab-completion of a command). Maybe the forthcoming next major release of KDE (i.e. that based on Qt5 and Frameworks, whether it ends up being called KDE 5 or something else) would be a good time to review what is installed here, and move anything that is not intended to be run by the user into $KDEDIR/lib/kde4/libexec? KStandardDirs::findExe() already searches there (before $PATH or $KDEDIR/bin), so there should be no serious compatibility problems. I could submit bugs for all of the individual components that install such things, but this message is just to gauge the reaction first. Here is a quick survey of my current $KDEDIR/bin, I'm not sure about the purpose of all of these executables but have certainly never had the occasion to run any of them as a user. Some of them are even dangerous to run... *.kss -- all screen savers akonadi_* akonadiserver amarok_afttagger amarokcollectionscanner curconvd dtvdaemon kactivitymanagerd kalarmautostart kapplymousetheme kbuildsycoca4 -- but useful for the user to run sometimes kcheckrunning kcminit kcminit_startup kcookiejar4 kded4 kdeinit4 kdeinit4_shutdown kdeinit4_wrapper kdekillall kdostartupconfig4 kfilemetadatareader khotnewstuff-upload kio_svn_helper kjotsmigrator kmail-migrator kmailcvt knotify4 kpartloader krandrstartup kres-migrator ksmserver kstartupconfig4 ksysguardd ktesnippets_editor ktmagnetdownloader kuiserver kwalletd kwrapper4 kwrited lucene2indexer nepomukindexer nepomukserver nepomukservicestub nspluginscan plasma-remote-helper rdfindexer servicemenudeinstallation servicemenuinstallation sopranod strigidaemon xmlindexer -- Jonathan Marten http://www.keelhaul.demon.co.uk Twickenham, UK j...@keelhaul.demon.co.uk
Re: Review Request 106224: Add spinlocks lock type, based on GCC intrisincs
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106224/ --- (Updated April 10, 2013, 7:12 p.m.) Status -- This change has been marked as submitted. Review request for kdelibs and Michael Pyne. Description --- Add simple spin locking mechanism. Written by Michael Pyne as from https://bugs.kde.org/attachment.cgi?id=73282 , with some tweaking by me. This addresses bug 305023. http://bugs.kde.org/show_bug.cgi?id=305023 Diffs - kdecore/util/ConfigureChecks.cmake fe9f47e kdecore/util/config-util.h.cmake 83ccdf7 kdecore/util/kshareddatacache_p.h ec5a7a0 Diff: http://git.reviewboard.kde.org/r/106224/diff/ Testing --- On OpenBSD-CURRENT, i386 Thanks, Vadim Zhukov
Re: Review Request 106221: Mutex cleanup in KSharedDataCache
On April 7, 2013, 5:56 p.m., Albert Astals Cid wrote: Michael/Vadim what's the status of this? This needs rebasing... I'm very busy those days, hope to have time for new patch at the weekend. - Vadim --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106221/#review30621 --- On Aug. 27, 2012, 12:50 p.m., Vadim Zhukov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106221/ --- (Updated Aug. 27, 2012, 12:50 p.m.) Review request for kdelibs and Michael Pyne. Description --- - Remove support for thread-shared-only locks: they do not help at all but makes app crash instead of slowly work; lack of decent locks to be resolved later. - Add error checking with console printouts. - Consistently use :: before global functions. Probably failed mutexes should be destroyed in case of some errors, any thoughts? This addresses bug 305023. http://bugs.kde.org/show_bug.cgi?id=305023 Diffs - kdecore/util/ConfigureChecks.cmake fe9f47e kdecore/util/config-util.h.cmake 83ccdf7 kdecore/util/kshareddatacache.cpp 393902e kdecore/util/kshareddatacache_p.h ec5a7a0 Diff: http://git.reviewboard.kde.org/r/106221/diff/ Testing --- On OpenBSD-CURRENT. Thanks, Vadim Zhukov
Review Request 111371: Fix duplicate targets in PythonMacros.cmake, unbreaking Ninja builds for Python-based KDE apps
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111371/ --- Review request for kdelibs. Description --- Currently, PYTHON_INSTALL macro in PythonMacros.cmake creates same target compile_python_files for all Python modules. This somehow works for Make-based builds, but breaks when using Ninja backend for CMake. CMake itself says that it does not guarantee that targets with same name will ever work. The patch creates unique target for each python module being pre-compiled and installed. The patch can be applied without modifications to 4.10 and 4.11, too. Diffs - cmake/modules/PythonMacros.cmake 95c9315 Diff: http://git.reviewboard.kde.org/r/111371/diff/ Testing --- OpenBSD-CURRENT, PyKDE 4.10.4 and 4.10.5. Thanks, Vadim Zhukov
Re: Review Request 111371: Fix duplicate targets in PythonMacros.cmake, unbreaking Ninja builds for Python-based KDE apps
On July 4, 2013, 9:35 a.m., Luca Beltrame wrote: Ship It! Luca Beltrame wrote: Please put this modification also in kdelibs master branch (in fact, put it in master so it'll get merged in next time dfaure merges master into frameworks). Could you (or somebody else) commit it then, please? I don't have commit access. - Vadim --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111371/#review35551 --- On July 2, 2013, 10:58 p.m., Vadim Zhukov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111371/ --- (Updated July 2, 2013, 10:58 p.m.) Review request for kdelibs. Description --- Currently, PYTHON_INSTALL macro in PythonMacros.cmake creates same target compile_python_files for all Python modules. This somehow works for Make-based builds, but breaks when using Ninja backend for CMake. CMake itself says that it does not guarantee that targets with same name will ever work. The patch creates unique target for each python module being pre-compiled and installed. The patch can be applied without modifications to 4.10 and 4.11, too. Diffs - cmake/modules/PythonMacros.cmake 95c9315 Diff: http://git.reviewboard.kde.org/r/111371/diff/ Testing --- OpenBSD-CURRENT, PyKDE 4.10.4 and 4.10.5. Thanks, Vadim Zhukov
Re: release schedule BoF
2013/7/23 David Faure fa...@kde.org: tsdgeos: can someone please kick kdelibs people to fix the tests Hmm? http://build.kde.org/job/kdelibs_stable/ is very green. Altough this gets a bit offtopic... Here is the exempt from my TODO list (I had not enough time to investigate all tests yet). Running on OpenBSD-CURRENT. The following tests FAILED: 6 - kdecore-karchivetest (Failed) # buggy test (at minimum group ID inheritance specifics) 7 - kdecore-kdirwatch_unittest (Failed) # looks like buggy test (uses QFSWatch?!) 11 - kdecore-kstandarddirstest (Failed)# probably a buggy test (symlink already resolved after resourceDirs() call) 22 - kdecore-ktimezonestest (Failed) # buggy test 38 - kdecore-kservicetest (Failed) # XXX needs konsole and baseapps 45 - kdecore-ktcpsockettest (Failed) # buggy test 46 - kdecore-ksycocathreadtest (Failed)# XXX needs Kate 51 - kdecore-kmimetype_nomimetypes (Failed)# buggy test 55 - kdecore-klocalsocketservertest (Failed) # OpenBSD does not support abstract UNIX sockets 105 - kptyprocesstest (Failed) # buggy test (execute should not be used for KPtyProcess) That's not all the failed tests - there are 60+ more, that's just tests I as able investigate till now. I want to finish that work, make patches where applicable and put 'em on reviewboard. But I think you should know. You see, from the 10 failing tests investigated: 1 test (correctly) fail because underlying OS does not support the feature. 2 tests require some stuff that itself depends on kdelibs - not a big deal, but it's definitely not The Good Thing. 7 other tests are just buggy. Just my two tes^H^H^Hcents. -- WBR, Vadim Zhukov
Re: Fwd: looking for phonon gstreamer maintainer
25.09.2013 15:25 пользователь Aaron J. Seigo ase...@kde.org написал: On Wednesday, September 25, 2013 12:35:25 Harald Sitter wrote: since everyone who ever was/is/wanted to be Phonon GStreamer maintainer is either busy or has no interest in it, the backend has as of right now no actual maintenance. you may not get much a reply without some more information: * is there some underlying reason why there is no interest in maintaining Phonon GStreamer? e.g. is there a GStreamer annoyance that needs to be known about / taken into consideration? * what are the real-world ramifications of not having GStreamer support? which platforms might suffer due to a lack of integration / codec support / etc as a result? * what effort is currently required to support Phonon GStreamer? Is it stable and needing continued testing and bug fixing maintenance; is it need of more major surgery; is the big work ahead a port to Qt5 or a change in Phonon? * One more serious question: how well does this backend copes with (recent versions of) GStreamer 1.x?
Re: ksysguard failing tests
25.11.2013 3:18 пользователь Albert Astals Cid aa...@kde.org написал: Hi, there are two ksysguard failing tests in jenkins http://build.kde.org/view/KDE%20SC%20stable/job/kde-workspace_stable/lastCompletedBuild/testReport/ There is one because of an API misuse expecting that a float will give you the plural version in k18np. Not sure we can fix this in KDE/4.11 since it's part of an installed header (even if we don't guarantee API stability for kde- workspace libs). My suggestion for this is removing the test from KDE/4.11 and adding a TODO in master branch in case someone wants to pick it up. The other one seems to be because of wrong implementation of SoftRaid reporting in ksysguardd. Anyone taking care of it? I'll take a look and post patches on reviewboard.
Re: Moving Baloo forward
2014/1/21 Thomas Lübking thomas.luebk...@gmail.com: On Dienstag, 21. Januar 2014 13:37:29 CEST, viv...@gmail.com wrote: And windows? HPFS/NTFS has xattr support (through alternative data streams) and WINNT supports handling xattr on FAT as well. The problem about xattr is rather that 99% of all ext3/4 users will atm get setfattr: filename: Operation not supported ie. xattr nowhere being activated. This would have to change dramatically in order to make a xattr implementation useful. Next thing is global xattr awareness, ie. one has to consider that even if kio/dolphin would have great xattr support and cp aliasing -a by default etc., the user might move/copy the data using nautilus or some other lousy filemanager :-P I *do* consider xattr the BY FAR more sane approach to the problem, but currently do frankly not see this on end user desktops :-( Linux/Desktop has to become a xattr OS before relying on it - thus imo xattr support could only be explicitly optional to get there. Otherwise ubuntusers™ will complain loosing their metadata all the time. Unfortunately this isn't MacOS where SJ. just said: do or you're fired, you censored! Keeping metadata in id3v2/xmp/iptc unfortunately only covers few filetypes (w/o invoking sidecars, ie. what __MACOSX does when entering the outer world) - directories could be stored in .directory xattrs are not available in neither NetBSD, DragonFlyBSD nor in OpenBSD (which will ship 4.11.5 in the next release). And what's for read-only mounted file systems? And what will happen if the file with xattr is saved on a flash drive, and then transferred to another computer? In case with separate DB it'll be just lost, maybe not immediately. In case of xattrs, other user will receive this info, which is not good itself at least. And this may cause Baloo misbehaving, no? I'm all for improving current situation with Nepomuk, and appreciate any steps in this direction a lot. But, please, do not use xattrs here: in the best case you'll have two totally different codepaths that you'll have to manage. -- WBR, Vadim Zhukov
Re: Moving Baloo forward
2014/1/24 Sebastian Kügler se...@kde.org: On Friday, January 24, 2014 01:24:54 Vadim Zhukov wrote: in the best case you'll have two totally different codepaths that you'll have to manage. This should be worst case, I think. In the best case, there's xattr support, meaning another code path isn't needed. It's doubtful at least whether xattr support is a good thing, because it's too easily gets misused: for example, there were viruses on Windows which effectively hidden themselves in NTFS streams. And there are personal data leaking issues I've pointed out earlier. But the question xarttrs: to be or not to be everywhere is totally offtopic, because it's what OS developers should decide. The worst case is Nepomuk becoming a crashy resource hog again, which will turn in cutting it off or disabling by default in most OSes. -- WBR, Vadim Zhukov
Re: Review Request 106221: Mutex cleanup in KSharedDataCache
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/106221/ --- (Updated July 1, 2014, 3:02 a.m.) Status -- This change has been discarded. Review request for kdelibs and Michael Pyne. Bugs: 305023 http://bugs.kde.org/show_bug.cgi?id=305023 Repository: kdelibs Description --- - Remove support for thread-shared-only locks: they do not help at all but makes app crash instead of slowly work; lack of decent locks to be resolved later. - Add error checking with console printouts. - Consistently use :: before global functions. Probably failed mutexes should be destroyed in case of some errors, any thoughts? Diffs - kdecore/util/ConfigureChecks.cmake fe9f47e kdecore/util/config-util.h.cmake 83ccdf7 kdecore/util/kshareddatacache.cpp 393902e kdecore/util/kshareddatacache_p.h ec5a7a0 Diff: https://git.reviewboard.kde.org/r/106221/diff/ Testing --- On OpenBSD-CURRENT. Thanks, Vadim Zhukov
Re: Review Request 106174: Move checks for locking primitives in KSharedDataCache to CMake
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/106174/ --- (Updated July 1, 2014, 3:02 a.m.) Status -- This change has been discarded. Review request for kdelibs and Michael Pyne. Bugs: 305023 http://bugs.kde.org/show_bug.cgi?id=305023 Repository: kdelibs Description --- This patch does move some run-time checks (mainly for different locking mechanisms) in KSharedDataCache to build time (CMake). Diffs - kdecore/util/ConfigureChecks.cmake fe9f47e kdecore/util/config-util.h.cmake 83ccdf7 kdecore/util/kshareddatacache.cpp 393902e kdecore/util/kshareddatacache_p.h ec5a7a0 Diff: https://git.reviewboard.kde.org/r/106174/diff/ Testing --- On OpenBSD-CURRENT. Thanks, Vadim Zhukov
Re: Review Request 106237: Add flock()/lockf()-based locking mechanizm to KSharedDataCache
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/106237/ --- (Updated July 1, 2014, 3:03 a.m.) Status -- This change has been discarded. Review request for kdelibs and Michael Pyne. Bugs: 305023 http://bugs.kde.org/show_bug.cgi?id=305023 Repository: kdelibs Description --- This patch adds another lock type, to be used as a last resort when no non-blocking lock mechanisms are available on the current platform. LOCKTYPE_FILE = 4 for compatibility with atomic-based locking mechanism patch in another review. Diffs - kdecore/util/ConfigureChecks.cmake fe9f47e kdecore/util/config-util.h.cmake 83ccdf7 kdecore/util/kshareddatacache.cpp 393902e kdecore/util/kshareddatacache_p.h ec5a7a0 Diff: https://git.reviewboard.kde.org/r/106237/diff/ Testing --- On OpenBSD-CURRENT. Thanks, Vadim Zhukov
Re: Review Request 119025: Actually pass IBUS_DEFINITIONS when compiling ibus-panel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119025/ --- (Updated Июль 9, 2014, 7:52 п.п.) Review request for kde-workspace and Plasma. Repository: kimtoy Description (updated) --- The ibus-panel can't build on OpenBSD because some required definitions obtained from pkgconfig file are not used. This happens due to the following reasons: 1. IBUS_DEFINITIONS is not used in ibus-panel/CMakeLists.txt 2. IBUS_DEFINITIONS is not saved in cache, and thus isn't available at compile time This patch resolves both issues and makes ibus-panel compile on OpenBSD. (I found no suitable review group and therefore used plasma instead, as it was in plasma-addons previously; please, feel free to correct me if I'm wrong and sorry for any possible inconvenience) ((as there was no feedback for more than a week, I've added kde-workspace group to list of reviewers, too)) Diffs - cmake/FindIBus.cmake 8250c49 ibus-panel/CMakeLists.txt 3a1ee49 Diff: https://git.reviewboard.kde.org/r/119025/diff/ Testing --- OpenBSD/i386-CURRENT, KDE 4.13 (it doesn't have kimtoy package, of course, but the code is same) Thanks, Vadim Zhukov
Re: Review Request 119025: Actually pass IBUS_DEFINITIONS when compiling ibus-panel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119025/ --- (Updated Июль 12, 2014, 5:12 п.п.) Review request for kde-workspace, Plasma and Hui Ni. Changes --- As a last resort for the patch to be reviewed, adding nihui@ to reviewers, who committed to the ibus-panel last times. Repository: kimtoy Description --- The ibus-panel can't build on OpenBSD because some required definitions obtained from pkgconfig file are not used. This happens due to the following reasons: 1. IBUS_DEFINITIONS is not used in ibus-panel/CMakeLists.txt 2. IBUS_DEFINITIONS is not saved in cache, and thus isn't available at compile time This patch resolves both issues and makes ibus-panel compile on OpenBSD. (I found no suitable review group and therefore used plasma instead, as it was in plasma-addons previously; please, feel free to correct me if I'm wrong and sorry for any possible inconvenience) ((as there was no feedback for more than a week, I've added kde-workspace group to list of reviewers, too)) Diffs - cmake/FindIBus.cmake 8250c49 ibus-panel/CMakeLists.txt 3a1ee49 Diff: https://git.reviewboard.kde.org/r/119025/diff/ Testing --- OpenBSD/i386-CURRENT, KDE 4.13 (it doesn't have kimtoy package, of course, but the code is same) Thanks, Vadim Zhukov
Re: Review Request 119025: Actually pass IBUS_DEFINITIONS when compiling ibus-panel
On Июль 19, 2014, 1:17 д.п., Vadim Zhukov wrote: (As a general note, for build system related stuff like this you can also try including the buildsystem group, which can be more responsive at times) The ibus-panel can't build on OpenBSD because some required definitions obtained from pkgconfig file are not used. 1. IBUS_DEFINITIONS is not used in ibus-panel/CMakeLists.txt Can you post the error you get here? I've tried building kimtoy here on FreeBSD expecting to hit the same issue(s), but it all went along just fine. 2. IBUS_DEFINITIONS is not saved in cache, and thus isn't available at compile time This doesn't make much sense; all values found at configuration time in CMake are then used to generate your make/ninja/whatever files, regardless of whether they are cached or not. Raphael, thank you for your input! The issue was caused by the fact that X includes are placed in the /usr/X11R6/include directory on OpenBSD. This catalog is mentioned in PC_IBUS_DEFINITIONS variable but isn't propagated to the caller of find_package(IBus). Yes, I was wrong: the CACHE part may and should be omitted. This patch was added by me a long time ago (7 Feb 2012 according to git log; guess the KDE version used then), when I was much less expirienced in CMake... I've started a massive push of OpenBSD local patches upstream recently during OpenBSD hackathon, when I got time for such cleanup. At the present time, the /usr/X11R6/include gets to the include_directories() from another place, so the patch isn't required at all. But, still, the PC_IBUS_DEFINITIONS should be respected, IMHO. What do you think? Please note that FreeBSD and OpenBSD and quiet different. So you can't test on one OS instead of another. - Vadim --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119025/#review62669 --- On Июль 12, 2014, 5:12 п.п., Vadim Zhukov wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119025/ --- (Updated Июль 12, 2014, 5:12 п.п.) Review request for kde-workspace, Plasma and Hui Ni. Repository: kimtoy Description --- The ibus-panel can't build on OpenBSD because some required definitions obtained from pkgconfig file are not used. This happens due to the following reasons: 1. IBUS_DEFINITIONS is not used in ibus-panel/CMakeLists.txt 2. IBUS_DEFINITIONS is not saved in cache, and thus isn't available at compile time This patch resolves both issues and makes ibus-panel compile on OpenBSD. (I found no suitable review group and therefore used plasma instead, as it was in plasma-addons previously; please, feel free to correct me if I'm wrong and sorry for any possible inconvenience) ((as there was no feedback for more than a week, I've added kde-workspace group to list of reviewers, too)) Diffs - cmake/FindIBus.cmake 8250c49 ibus-panel/CMakeLists.txt 3a1ee49 Diff: https://git.reviewboard.kde.org/r/119025/diff/ Testing --- OpenBSD/i386-CURRENT, KDE 4.13 (it doesn't have kimtoy package, of course, but the code is same) Thanks, Vadim Zhukov
Re: Review Request 119025: Actually pass IBUS_DEFINITIONS when compiling ibus-panel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119025/ --- (Updated Июль 19, 2014, 10:43 п.п.) Review request for kde-workspace, Plasma and Hui Ni. Changes --- Simplified patch, no CACHE needed. Repository: kimtoy Description --- The ibus-panel can't build on OpenBSD because some required definitions obtained from pkgconfig file are not used. This happens due to the following reasons: 1. IBUS_DEFINITIONS is not used in ibus-panel/CMakeLists.txt 2. IBUS_DEFINITIONS is not saved in cache, and thus isn't available at compile time This patch resolves both issues and makes ibus-panel compile on OpenBSD. (I found no suitable review group and therefore used plasma instead, as it was in plasma-addons previously; please, feel free to correct me if I'm wrong and sorry for any possible inconvenience) ((as there was no feedback for more than a week, I've added kde-workspace group to list of reviewers, too)) Diffs (updated) - ibus-panel/CMakeLists.txt 3a1ee49 Diff: https://git.reviewboard.kde.org/r/119025/diff/ Testing --- OpenBSD/i386-CURRENT, KDE 4.13 (it doesn't have kimtoy package, of course, but the code is same) Thanks, Vadim Zhukov
Re: Distros and QtWebEngine
2015-04-20 19:28 GMT+03:00 Lisandro Damián Nicanor Pérez perezme...@gmail.com: Hi everyone! I'm one of Debian's Qt maintainers and I'm writing here due to the problem that QtWebEngine poses for us distros (in this case, at least Debian and Fedora). I know that kdepim seems to depend on it now. Sadly QtWebEngine it's quite a hard (very hard) piece of software to package. It embeds quite a lot of 3rd party stuff which we distros don't accept (in different grades depending on the distro) as we require to build using the system versions. Fedora's Rex Dieter tells me that's actually why chromium is not available for them. Moreover we can't build debugging symbols on most archs due to the enormous amount of RAM+swap it involves in the linking process (more than 8GB last time I checked). This is at least the same as QtWebKit, but seems to be getting worse. Yes, we do understand that QtWebEngine is technically superior to any other thing out there but making that code an acceptable package is another thing. So basically what I'm trying to say is: don't expect us down streamers to easily package QtWebEngine soon, if we ever get to it. I'm really sorry if this comes as bad news, but the reality is currently this :( And if such large-community distros like Debian and Fedora have issues, what to say about smaller ones? Also, QtWebEngine isn't ported outside of Linux, Windows and MacOS X at all. I'm an OpenBSD developer, maintaining almost all Qt and KDE ports for now. And I can clearly say that I won't ever start working on QtWebEngine: chromium port in OpenBSD (maintained by a different person) already has 285 (sic!) local patches, so QtWebEngine will need at least as much. That's, obviously, too much. So until something changes, there will be no KF5-based PIM on OpenBSD. I'm not in favor of using outdated QtWebkit module either: it's likely full of security holes, so it's not the thing you want to throw incoming email at. Could some sa[fn]e, compact, non-JS engine be used for viewing mail and other PIM activities? What options do KDE PIM people see? -- WBR, Vadim Zhukov
Re: Policy regarding QtWebKit and QtScript
e will, right? But it happens. There is a little chance QtWebEngine will be ported on OpenBSD: if someone will come in and fix Chromium and QtWebEngine to bundle less, at least. I won't volunteer: handling a few hundreds of KDE ports + ports of Qt itself is already big enough task for me. So, again, it was my seeing, both for today and tomorrow. Now I'm back to porting other KDE5 stuff. Thank you for reading! -- WBR, Vadim Zhukov
Re: Review of special packager access
2016-07-20 10:29 GMT+03:00 Ben Cooksley <bcooks...@kde.org>: > Hi all, > > Just as a final reminder, i've yet to see responses from: > > - Asplinux BTW, ASPLinux is no more. http://distrowatch.com/table.php?distribution=asp -- WBR, Vadim Zhukov
Re: Review Request 119025: Actually pass IBUS_DEFINITIONS when compiling ibus-panel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119025/ --- (Updated Sept. 22, 2016, 8:40 p.m.) Status -- This change has been discarded. Review request for kde-workspace, Plasma and Hui Ni. Repository: kimtoy Description --- The ibus-panel can't build on OpenBSD because some required definitions obtained from pkgconfig file are not used. This happens due to the following reasons: 1. IBUS_DEFINITIONS is not used in ibus-panel/CMakeLists.txt 2. IBUS_DEFINITIONS is not saved in cache, and thus isn't available at compile time This patch resolves both issues and makes ibus-panel compile on OpenBSD. (I found no suitable review group and therefore used "plasma" instead, as it was in "plasma-addons" previously; please, feel free to correct me if I'm wrong and sorry for any possible inconvenience) ((as there was no feedback for more than a week, I've added "kde-workspace" group to list of reviewers, too)) Diffs - ibus-panel/CMakeLists.txt 3a1ee49 Diff: https://git.reviewboard.kde.org/r/119025/diff/ Testing --- OpenBSD/i386-CURRENT, KDE 4.13 (it doesn't have kimtoy package, of course, but the code is same) Thanks, Vadim Zhukov
