Re: Launch Bug Report Wizard failing on Apple OS X (was "ksycoca4")
On 05 May 2014, at 21:25 , Thomas Lübking wrote: > -> can you lookup your local KDE code for the section in kfmclient.cpp? Since I am using current KDE 4.12.4 here this change is - of course - present. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Launch Bug Report Wizard failing on Apple OS X (was "ksycoca4")
On 05 May 2014, at 21:00 , Thomas Lübking wrote:
> Many thanks for the update - let's see whether Jose can confirm this
> observation.
You’re welcome. We’ll see.
>> The only odd thing is that some kio_client apps clutter up the dock, which
>> I’ve also seen for kglobalaccel in konversation [1].
> Actually this does match [2] where many [kioclient] processes hang
> around - do you get them as well? ("ps ax" should also work under OSX)
Yup.
signature.asc
Description: Message signed with OpenPGP using GPGMail
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Launch Bug Report Wizard failing on Apple OS X (was "ksycoca4")
Hi Thomas, On 23 Mar 2014, at 19:18 , Thomas Lübking wrote: > Another idea would be that OSX doesn't like the "!" prefix (no idea why > componentchooser writes it - here. Works fine w/o as well) Hmm, I think that’s indeed the problem! I did this test once again with konqueror, but this time I selected konqueror via the “KDE control module” itself using the “Select preferred Web browser application” dialog under "Internet/Konqueror" instead of specifying the path to the executable directly in the application package... AND -> THIS TIME THERE WAS NO ENDLESS RESPAWNING HAPPENING ANYMORE! The only odd thing is that some kio_client apps clutter up the dock, which I’ve also seen for kglobalaccel in konversation [1]. But they disappear after a while (i.e. a few mins). So, eventually, the exclamation mark is the dangerous thing here, as it seems! I guess one should cross-check that as well with [2]! Perhaps the user also used the exclamation mark there. Greets, Marko [1] https://bugs.kde.org/show_bug.cgi?id=334174 [2] https://sourceforge.net/p/be-shell/tickets/21/ signature.asc Description: Message signed with OpenPGP using GPGMail >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Baloo - [Basic Settings]
On 28 Apr 2014, at 09:13 , Kevin Krammer wrote: > http://techbase.kde.org/KDE_System_Administration/Configuration_Files#Shell_Expansion Thanks, Kevin, that link was indeed just what I needed! :-) Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Baloo - [Basic Settings]
Hi Vishesh, On 23 Apr 2014, at 23:54 , Michael Pyne wrote: > I'm not sure about [$]. There are other possibilities for a KConfig file > besides [$e] but I don't think [$] is one of them. could you please clarify what the [$] means on your wiki page for the folders key? Greets, Marko [1] http://community.kde.org/Baloo/Configuration >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Baloo - [Basic Settings]
Hi Vishesh, On 23 Apr 2014, at 11:44 , Vishesh Handa wrote: > [1] http://community.kde.org/Baloo/Configuration is there a reason why this page isn’t linked on http://community.kde.org/Baloo yet? BTW, what is the meaning of “[$e]” and “[$]” in the respective “exclude folders” and “folders” keys of baloo’s user configuration file? (Sorry if asking this seems perhaps greenhornish, but I am not an expert regarding KDE’s config-files, which is why I have to ask.) I guess all baloo settings are also present somewhere in a system-wide baloofilerc, correct? Where would that file reside? Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Running KDE apps on Apple OS X
Hi Ben, On 13 Apr 2014, at 13:45 , mk-li...@email.de wrote: >> To build certain projects, the compiler will need to support C# and a >> certain level of C++11 as well. The Mono bindings will not be >> buildable if C# support is unavailable. > Well, that should be built in on OSX, or not? well, only now I see that it is C# above and not "Objective C” which my brain tried to tell me… ;-) I guess applications requiring C# will only ever be supported on Windows. BTW, I have tried to take the essence of our CI discussion to a new wiki page on MacPorts’s trac wiki [1]. This should help us to collect all information in one place, without browsing mailing list posts endlessly. Greets, Marko [1] https://trac.macports.org/wiki/KDEProblems/KDEMacPortsCI >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Running KDE apps on Apple OS X
Hi John, when I was going once more through your post from mid-March I noticed that you are using kate extensively. On 12 Mar 2014, at 19:44 , John Layt wrote: > I use Kate extensively on Mac, and Dolphin when Finder is too > brain-dead. Don’t you see the trouble described in ticket [1] on your end? The issue has been reassigned as [2] which is already to be found on our KDE software problems wiki page [3]. Funnily enough I have another MacPorts installation. And in that one I don’t see the two tabs “Search and Replace” and “Current Project” at all. How can they be toggled between visible and hidden? So, I don’t know whether on that machine the form widgets get as squeezed and overlapped as in the attached screenshot. Greets, Marko [1] https://bugs.kde.org/show_bug.cgi?id=333049 [2] https://bugs.kde.org/show_bug.cgi?id=296810 [3] https://trac.macports.org/wiki/KDEProblems >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Running KDE apps on Apple OS X
Hi Ben, thanks very much for your so informative reply! On 13 Apr 2014, at 12:28 , Ben Cooksley wrote: > Not exactly, however the infrastructure we have for our Linux builds > should be nearly completely portable to OSX without too much trouble > (in theory at least - i've never done any compilation on OSX). That sounds good. I am willing to give it a try then. :-) Just for the record: Yesterday I've built KMyMoney via MacPorts from scratch (on a fresh OSX VM machine “2.5GHz Mac Mini"). If I subtract the time I needed to set up the environment and some intermediate steps, I end up with 3h11m install time for kmymoney4-devel and all its dependencies (kdepimlibs, kde4-runtime, kdelibs4, virtuoso, nepomuk, mysql5, soprano and last but not at all least qt4-mac). This still sounds a lot, but given the number of libraries and programs to install it is already VERY FAST compared to pre-buildbot times of 24hrs or so. Most of the time had to be spent on 14 ports which cannot be distributed as binaries, for that see [1]. Once we get rid of Nepomuk (with KDE 4.13) many of those dependencies will disappear according to Ian. That would speed things up tremendously! But 3h on a VM isn’t bad, considering! :-D > The actual requirements aren't written anywhere, but you might find > the documentation i've written for the CI system to be of some use. > See > http://quickgit.kde.org/?p=websites%2Fbuild-kde-org.git&a=tree&h=48c561bdfa467b0a09d6591491abc168b63197ce&hb=f2d024f155bed23a9e81b0175e5c7d752d6d8f14&f=documentation I’ll have a look at it. Thanks! > A basic run down of what the CI system needs however: > > 1) Python 2.x, with json and lxml support (for the scripts which conduct > builds) Ports python 2.[4-7] and python 3.1.5 - 3.4.0 are available. Regarding json and lxml we have for 2.7 these ports: — py27-anyjson @0.3.3 (python, www)Wrap the best available JSON implementation in a common API py27-cjson @1.0.5 (python)Fast JSON encoder/decoder for Python py27-demjson @1.6 (python)encoder, decoder, and validator for JSON compliant with RFC 4627 py27-geojson @1.0.6 (python, gis)Python bindings and utilities for GeoJSON py27-simplejson @3.4.0 (python, www)Simple, fast, extensible JSON encoder/decoder for Python py27-lxml @3.3.4 (python, devel)Powerful and Pythonic XML processing library — > 2) Java (for the Jenkins node agent itself) — $ java -version java version "1.6.0_65" Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609) Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode) — > 3) RSync and SSH (for the transferral of completed builds between nodes) — $ port list rsync ssh rsync @3.0.9 net/rsync $ which ssh /usr/bin/ssh $ ssh -v OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011 — > 4) Git, Subversion, Bazaar, wget and GNU Tar (to access source code) — $ port list git-core subversion bazaar wget gnutar git-core @1.9.2 devel/git-core subversion @1.8.8 devel/subversion bazaar @1.4.2 devel/bazaar wget @1.15 net/wget gnutar @1.27.1 archivers/gnutar — > 5) GNU Patch (for applying custom patches, used in certain builds) — $ patch -v patch 2.5.8 — > 6) A compiler, usable by CMake, QMake and autotools based build systems Well, in principle there is Apple’s standard compiler: CLANG on the newer versions of OSX, but you can configure MacPorts to use many compilers. — $ port list gcc* gcc42 @4.2.4 lang/gcc42 gcc43 @4.3.6 lang/gcc43 gcc44 @4.4.7 lang/gcc44 gcc45 @4.5.4 lang/gcc45 gcc46 @4.6.4 lang/gcc46 gcc47 @4.7.3 lang/gcc47 gcc48 @4.8.2 lang/gcc48 gcc49 @4.9-20140406 lang/gcc49 gcc_select @0.1sysutils/gcc_select gccmakedep @1.0.2 x11/gccmakedep gccxml-devel @20130919 lang/gccxml-devel $ port list clang* clang-2.9 @2.9lang/llvm-2.9 clang-3.0 @3.0lang/llvm-3.0 clang-3.1 @3.1lang/llvm-3.1 clang-3.2 @3.2lang/llvm-3.2 clang-3.3 @3.3lang/llvm-3.3 clang-3.4 @3.4lang/llvm-3.4 clang-3.5 @3.5-r206116lang/llvm-3.5 clang_select @0.1sysutils/clang_select — > 8) GNU Make, Automake, Autoconf (for carrying out the build, and > configuring it in certain rare cases) — $ which make /usr/bin/make $ make -v GNU Make 3.81 $ port installed automake autoconf automake
Re: Running KDE apps on Apple OS X
Hi Ben, On 15 Mar 2014, at 12:07 , Ben Cooksley wrote: > We'll await the results of the Macports collaboration thread before > continuing further. in the meantime we have proceeded somewhat regarding our efforts to collect some information about current problems of KDE software on MacPorts. For that purpose we have eventually created a dedicated wiki page during the last few days [1]. It also contains a section entitled "Continuous Integration of KDE software”. I guess it is not possible to simply install Jenkins and start building on OSX. :-) Well, a while ago I installed Jenkins on my old iMac and found that it actually worked out of the box for makeicns [2], but I have never tried to do anything else with it, since about at the same time the MacPorts buildbots appeared on the scene [3]. Which prerequisites do you need for your CI system on Linux? Where can I read about that? I guess without more information it doesn’t make sense to approach the MacPorts developer team regarding their buildbots’ setup... Have a nice weekend! Greets, Marko [1] https://trac.macports.org/wiki/KDEProblems [2] https://bitbucket.org/mkae/makeicns [3] https://build.macports.org/builders >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling baloo-integration possible?
On 10 Apr 2014, at 00:40 , Thomas Lübking wrote: > i assume, ideally the api would just abstract spotlight on osx? > would require someone developing an osx backend. Yes, Thomas, that would be ideal. Since I am not an OSX developer I have no clue as to how open Apple’s API’s regarding Spotlight are… But that could definitely be a good way to integrate more seamlessly on the OSX platform. Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling baloo-integration possible?
On 10 Apr 2014, at 00:18 , Albert Astals Cid wrote: > Again not Baloo guy here, but as far as I know you can't disable "Baloo", > what > Vishesh told you is how to disable it's file indexer (baloofile), but if you > use KMail it(akonadi_baloo_indexer) will still index your emails into the > Baloo database, and may be other baloo_stuff (not aware of others existing) > running. Oh… No, one would perhaps not use KMail on OSX, because its Mail.app is sufficient for most stuff, although it also has some shortcomings. So, I wonder what baloo would be doing on OSX to get its hands into the user’s emails… I hope Vishesh can clarify this! Sure one doesn’t want to see any collisions between OSX’ Spotlight indexer on one side and baloo on the other. As I pointed out: I would like to tell baloo - if I am after all forced to install it anyways - that it should sleep and do NOTHING. Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling baloo-integration possible?
Hi again, On 09 Apr 2014, at 23:53 , Frank Reininghaus wrote: > I think that there are many KDE apps which do not require Baloo at all. I could imagine that too. > I'm not sure if there is a full list somewhere, but you can > always build KDE modules and watch for any Baloo-related output from > CMake. If there is none, then everything will most likely work fine > without Baloo. OK, perhaps we could think about introducing baloo as an opt-in port variant which would only be installed if the user specifically asks for it. But that - of course - could cause a lot of stress during port maintenance. I guess it is better to install baloo and simply disable it. This case should be handled safely by all baloo-dependent KDE applications. Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling baloo-integration possible?
Hi Albert, On 09 Apr 2014, at 22:28 , Albert Astals Cid wrote: > No, it is not, if we had to do user support in this list it would get crowded I got it. > So you are a packager, ok, the it's not user support and I guess it is kind > on > topic. If you had given all the information on the beginning it would have > been better :) It’s okay. I got PM from Mario clarifying things. I am maintaining KMyMoney on MacPorts and because of it I of course also try to keep KDE afloat on OSX/MacPorts. I am NOT the main KDE maintainer there, but I know that many OSX users do not need another indexing service due to the existence of Spotlight (which is Apple’s baloo). I personally mostly don’t need any indexer, except that I am forced by my email program Mail.app to enable Spotlight for detailed searching features in emails. > You are asking if you can compile stuff without baloo. You don't need to be a > "KDE developer" to try that. Have you tried? No, because I am not yet able to build anything else than the 4.12.4 (which my machine could successfully finish only just now) I cannot test the 4.13. > 1) not install baloo at all > Of course, you're free to not install baloo OK, but with the problems Frank already described... > 2) configure KDE and all relevant apps in such a way that they don’t expect > any services from baloo > What is "KDE”? :) You are right, I meant kdelibs there. But thanks to Frank I already understood that kdelibs itself doesn’t need baloo after all. > Simply replace baloo with libjpeg and the answers will be the same. So, ok, as I wrote in my reply to Frank: I should preferably simply use Vishesh’s suggestion and modify baloo’s configuration file. Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling baloo-integration possible?
Hi Frank, thanks again for your constructive feedback! :) On 09 Apr 2014, at 22:24 , Frank Reininghaus wrote: > yes, but you might not be able to build and/or use all KDE > applications correctly. kdelibs itself does not depend on Baloo at > all. okay, good to know that kdelibs itself doesn’t need baloo. > I'm not quite sure, but everything related to KDE PIM might be in the > (b) or (c) category. Well, I had hoped that also some other apps would not require baloo during build or runtime. So, I think it will be rather impossible to skip installing baloo after all and I should rather follow Vishesh’s advice and configuring baloo using its configuration file. Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling baloo-integration possible?
Hi Albert, On 09 Apr 2014, at 22:01 , Albert Astals Cid wrote: > How is this a development question? Remember this is kde-devel, not a support > forum. it is not? > If you want to check if that is possible. Try it out yourself. I am not a KDE developer, just a port maintainer, and I thought I AM on the correct list to ask such questions. If this is not the case I apologise herewith and try to find a KDE user list which already covers baloo. (But honestly, because baloo is a new tool, I thought this IS the only place where I could ask such a basic question...) Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Disabling baloo-integration possible?
Hi Vishesh, On 08 Apr 2014, at 10:36 , Vishesh Handa wrote: >> will it be possible to run KDE without baloo enabled? > Yes. You can go to System Settings -> Desktop Search -> Exclude Folders, and > add your $HOME directory over there. > > Otherwise you can also edit the baloofilerc file and add the following - > > [Basic Settings] > Indexing-Enabled=false actually I was more thinking along the lines of: 1) not install baloo at all 2) configure KDE and all relevant apps in such a way that they don’t expect any services from baloo Is that doable? Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Disabling baloo-integration possible?
Hi devs, will it be possible to run KDE without baloo enabled? If so, which switches would have to be turned to do so during configuring kdelibs and/or other KDE apps? Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Missing application icons of many KDE apps on MacPorts/OSX
Hi Ian, On 02 Apr 2014, at 02:16 , Ian Wadham wrote: >> The same holds for Konqueror, which answers your question, Ian! :-) > > Yeah, but where/how (in the code or the build instructions) does it get that > icon? I don’t know where in the code it happens, I only saw that it accessed the fils using dtrace. > And what does the build have to do (on Apple OS X) to pick up the Oxygen app > icons > and put them in an ICNS file? The CMakeLists.txt just specifies where to find the application icons from which the build generates the ICNS file and copies the latter into the application package. The individual icons not needed for the application icon, i.e. all icons needed by the app during runtime have to be placed somewhere below /usr/local/share/icons/hicolor/ . Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Missing application icons of many KDE apps on MacPorts/OSX
On 31 Mar 2014, at 22:41 , mk-li...@email.de wrote: > So, obviously the test program fiddles with the ICNS file at startup and > restores it when shutting down… > What’s going on there and what can go wrong? So, I figure now that the problem is actually due to the fact that the icon at runtime gets loaded from the install location in e.g. /opt/local/share/icons/oxygen/ whereas the icon in the dock is extracted from the ICNS file in the app package. It is important not only to supply the ICNS file, but also to install all needed PNGs in the required dimensions in /opt/local/share/icons/hicolor/…/apps/tutorial2.png There is also clears up why there are different kdevelop icons shown! Since MacPorts installs the oxygen icon set, KDE actually assigns those icons instead of the hicolor ones installed by the application itself: $ pwd /opt/local/share/icons $ find . -name "kdevelop*" ./hicolor/128x128/apps/kdevelop.png ./hicolor/16x16/apps/kdevelop.png ./hicolor/32x32/apps/kdevelop.png ./hicolor/48x48/apps/kdevelop.png ./oxygen/128x128/apps/kdevelop.png ./oxygen/16x16/apps/kdevelop.png ./oxygen/22x22/apps/kdevelop.png ./oxygen/256x256/apps/kdevelop.png ./oxygen/32x32/apps/kdevelop.png ./oxygen/48x48/apps/kdevelop.png ./oxygen/64x64/apps/kdevelop.png On 24 Mar 2014, at 02:36 , Ian Wadham wrote: > So where is this NEW Konqueror icon coming from? The files in > pics/indicators seem > to be far too small to be a big icon like that. The same holds for Konqueror, which answers your question, Ian! :-) Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Missing application icons of many KDE apps on MacPorts/OSX
Icon-wise there is progress on my end. I peeked into kmines’ sources (since it does show its icon properly on MacOSX and has very short source code) ...… and it turned out that it is important in which order the CMake directives kde4_add_app_icon() and kde4_add_executable() are appearing in CMakeLists.txt. If kde4_add_app_icon() comes after kde4_add_executable() the ICNS file is NOT generated!OK, SUCCESS in so far that the application now has it’s proper icon as long as the app is NOT RUNNING.However, when I now start the application the ICON DISAPPEARS AGAIN and - seemingly - a KDE-generic icon with a question mark appears instead:I am surprised to see partial success only.WHY can I see the expected icon when the app isn’t running and why can’t I see the same icon while it is running??So, obviously the test program fiddles with the ICNS file at startup and restores it when shutting down…What’s going on there and what can go wrong?Greets,Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Missing application icons of many KDE apps on MacPorts/OSX
I would really fancy a minimal demo app which shows the mechanics of the app icon… I have played a little more with my own test case https://bitbucket.org/mkae/kde-tests/commits/bab1c1e8c5c3ba7ddbd1a9d1cf0c948358e40038?at=default but it is leading nowhere. :-( >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Missing application icons of many KDE apps on MacPorts/OSX
I have put the code including some PNGs for testing on https://bitbucket.org/mkae/kde-tests/src/7ca075e847a2c0ba1d5e7a97f1a5a60a298fe0f9/AboutBoxCrash/?at=default This app does neither create the ICNS nor sets up the required Resources folder in Contents: — ./tutorial2.app ./tutorial2.app/Contents ./tutorial2.app/Contents/Info.plist ./tutorial2.app/Contents/MacOS ./tutorial2.app/Contents/MacOS/tutorial2 ./tutorial2.app/Contents/MacOS/tutorial2.shell — Any idea what I am missing? >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Launch Bug Report Wizard failing on Apple OS X (was "ksycoca4")
Thanks Thomas, for your valuable hints! :-) On 23 Mar 2014, at 12:19 , Thomas Lübking wrote: > Do you get a dialog for >kcmshell4 componentchooser OK, I located the executable eventually: — $ /Applications/MacPorts/KDE4/kcmshell4.app/Contents/MacOS/kcmshell4 componentchooser kcmshell(3530)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from "/private/var/tmp/kdecache-marko/ksycoca4" kcmshell(3530)/kutils (KCMultiDialog) *KCMultiDialog::addModule: "Default Applications" kcmshell(3530)/kutils (KCModuleProxy) KCModuleProxyPrivate::loadModule: Module not already loaded, loading module "Default Applications" from library "kcm_componentchooser" using symbol "kcm_componentchooser" kcmshell(3530)/kutils (KCMultiDialog) *KCMultiDialog::addModule: adding KCM "Default Applications" at the top level kcmshell(3530)/kutils (KCMultiDialog) KCMultiDialogPrivate::_k_slotCurrentPageChanged: kcmshell(3530)/kutils (KCMultiDialog) KCMultiDialogPrivate::_k_clientChanged: kcmshell(3530)/kutils (KCMultiDialog) KCMultiDialogPrivate::_k_clientChanged: kcmshell(3530)/kutils (KCMultiDialog) KCMultiDialogPrivate::_k_dialogClosed: 2014-03-23 13:42:57.451 kcmshell4[3530:507] modalSession has been exited prematurely - check for a reentrant call to endModalSession: — I then selected konqueror deliberately in the component chooser and NOW it indeed gets fired up when I call "kioclient exec 'http://www.kde.org/'” Now also the bug report web page is displayed in konqueror when clicking on the corresponding menu item in said tutorial app. Great. OK, this proves that the KDE setup isn’t properly carried out correctly on MacPorts at the moment. > try: > kwriteconfig --group General --key BrowserApplication '!safari’ If I specify the full path to Safari and start kioclient it will SPAWN AN ENDLESS AMOUNT of Safaris (at a rate of ~2/s) which fill up the dock bit by bit. — $ kioclient exec 'http://www.kde.org/' … (in my system log:) 23/03/14 14:00:12,483 com.apple.launchd.peruser.502[272]: (0x7fb848506610.anonymous.Safari[3758]) Unmanaged jobs may not make XPC Events requests. 23/03/14 14:00:12,835 com.apple.launchd.peruser.502[272]: (0x7fb848705f60.anonymous.Safari[3768]) Unmanaged jobs may not make XPC Events requests. 23/03/14 14:00:13,298 com.apple.launchd.peruser.502[272]: (0x7fb848506f00.anonymous.Safari[3772]) Unmanaged jobs may not make XPC Events requests. . . . — This I could only stop by logging off... And now I see that — $ kwriteconfig --group General --key BrowserApplication '!/Applications/MacPorts/KDE4/konqueror.app/Contents/MacOS/konqueror’ $ kioclient exec 'http://www.kde.org/' … — will also FIRE UP COUNTLESS konquerors at the same rate like Safaris. So, it’s not related to Safari then! What’s going on there? > To do that for every user, one could make use of kiosk (basically provide > /usr/share/config/kdeglobals with appropriate entry in [General] - whether > that works on MacOS, i don't know. H… Didn’t look into that now, but one could simply use the kwriteconfig line of yours once after kdelibs installation. Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Launch Bug Report Wizard failing on Apple OS X (was "ksycoca4")
On 23 Mar 2014, at 12:19 , Thomas Lübking wrote:
> kioclient exec 'http://www.kde.org/'
$ kioclient exec 'http://www.kde.org/'
kioclient(2672)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open
ksycoca from "/private/var/tmp/kdecache-marko/ksycoca4"
kioclient(2672)/kio (Scheduler) KIO::SchedulerPrivate::doJob:
KIO::SimpleJob(0x7f91a0c84cd0)
kioclient(2672)/kio (Scheduler) *KIO::SchedulerPrivate::protoQ: creating
ProtoQueue instance for "http"
kioclient(2672)/kio (Scheduler) KIO::ProtoQueue::ProtoQueue:
m_maxConnectionsTotal: 20 m_maxConnectionsPerHost: 5
kioclient(2672)/kdeui (kdelibs) KWindowSystem::setIcons:
KWindowSystem::setIcons( WId win, const QPixmap& icon, const QPixmap& miniIcon
) isn't yet implemented!
kioclient(2672)/kio (KIOConnection) KIO::ConnectionServer::listenForRemote:
Listening on
"local:/private/var/folders/79/1f244yjd38v_g1qq6qfw8qx8gp/T/ksocket-marko/kioclientDH2672.slave-socket"
kioclient(2672)/kio (Scheduler) *KIO::SchedulerPrivate::heldSlaveForJob: HOLD:
Reusing klauncher held slave ( KIO::Slave(0x7f91a0ca3bf0) )
kioclient(2672)/kio (Scheduler) KIO::SchedulerPrivate::putSlaveOnHold:
KIO::TransferJob(0x7f91a0c84cd0) KUrl("http://www.kde.org/";)
KIO::Slave(0x7f91a0ca3bf0)
kioclient(2672)/kio (Scheduler) KIO::SchedulerPrivate::cancelJob:
KIO::TransferJob(0x7f91a0c84cd0) QObject(0x0)
kioclient(2672)/kio (Scheduler) KIO::SchedulerPrivate::jobFinished:
KIO::TransferJob(0x7f91a0c84cd0) QObject(0x0)
kioclient(2672)/kio (Scheduler) KIO::SchedulerPrivate::publishSlaveOnHold:
KIO::Slave(0x7f91a0ca3bf0)
> Does this open kde.org in any browser?
No, it didn’t open a browser.
> Do you get a dialog for
>kcmshell4 componentchooser
$ kcmshell4 componentchooser
-bash: kcmshell4: command not found
Well, I seem to have to install some other port to get kcmshell4 into my
system...
> and can you select a webbrowser (safari) there?
Need to search now which port contains that kcmshell4.
Is there perhaps another way to define the standard web browser at install time
in such a way that Safari would be used as the initial default?
Not every user might install all KDE ports - including konqueror - just to
install e.g. KMyMoney.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Missing application icons of many KDE apps on MacPorts/OSX
On 23 Mar 2014, at 12:09 , Thomas Lübking wrote:
> kdevelop/app/CMakeLists.txt *does* have
> kde4_add_app_icon(kdevelop_bin_SRCS
> "${CMAKE_CURRENT_SOURCE_DIR}/../pics/hi*-app-kdevelop.png”)
Yep, thanks for pointing that out. I forgot option ‘-i’ in my find command call.
:-(
> As you probably figured, the QT4_ADD_DBUS_ADAPTOR is not relevant and will
> esp. not configure (it'll cause a cmake error if put into the kdevelop
> context,
I saw that this isn’t relevant, yes.
> just as your KDE4_ADD_APP_ICON should likely in the pics subdir, as
> kdevelop_SRCS isn't definedanywhere)
It must have worked to some degree, since the ICNS file contained the image
with size 128 pixels.
Well, although the big icon now exists in there the app still doesn’t show the
wanted icon in the doc - as KMyMoney does.
Something’s still missing.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Missing application icons of many KDE apps on MacPorts/OSX
On 23 Mar 2014, at 12:09 , Thomas Lübking wrote:
> kdevelop/app/CMakeLists.txt *does* have
> kde4_add_app_icon(kdevelop_bin_SRCS
> "${CMAKE_CURRENT_SOURCE_DIR}/../pics/hi*-app-kdevelop.png”)
Yep, thanks for pointing that out. I forgot option ‘-i’ in my find command call.
:-(
> As you probably figured, the QT4_ADD_DBUS_ADAPTOR is not relevant and will
> esp. not configure (it'll cause a cmake error if put into the kdevelop
> context,
I saw that this isn’t relevant, yes.
> just as your KDE4_ADD_APP_ICON should likely in the pics subdir, as
> kdevelop_SRCS isn't definedanywhere)
It must have worked to some degree, since the ICNS file contained the image
with size 128 pixels.
Well, although the big icon now exists in there the app still doesn’t show the
wanted icon in the doc - as KMyMoney does.
Something’s still missing.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Missing application icons of many KDE apps on MacPorts/OSX
On 23 Mar 2014, at 09:42 , mk-li...@email.de wrote: > KDevelop is the only one missing the 128x128 icon, which seems to be the > reason for displaying the generic icon in dock if the app is not started. Simply giving KDevelop the missing icon is not yet enough to make it work in the dock and finder… :-( >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Missing application icons of many KDE apps on MacPorts/OSX
On 23 Mar 2014, at 08:56 , mk-li...@email.de wrote: > I haven’t crosschecked with other apps from my long list, but I guess that > explains it. I have found that the ports with an app icon on OSX actually do have an ICNS file installed: — $ find /Applications/MacPorts/KDE4 -name "*.icns" /Applications/MacPorts/KDE4/dolphin.app/Contents/Resources/dolphin_SRCS.icns /Applications/MacPorts/KDE4/kapptemplate.app/Contents/Resources/kapptemplate_SRCS.icns /Applications/MacPorts/KDE4/kdevelop.app/Contents/Resources/kdevelop_SRCS.icns /Applications/MacPorts/KDE4/kfind.app/Contents/Resources/kfind_SRCS.icns /Applications/MacPorts/KDE4/khelpcenter.app/Contents/Resources/khelpcenter_KDEINIT_SRCS.icns /Applications/MacPorts/KDE4/kmymoney.app/Contents/Resources/kmymoney_SRCS.icns /Applications/MacPorts/KDE4/kompare.app/Contents/Resources/kompare_SRCS.icns /Applications/MacPorts/KDE4/kuiviewer.app/Contents/Resources/kuiviewer_SRCS.icns /Applications/MacPorts/KDE4/kwrite.app/Contents/Resources/kwrite_KDEINIT_SRCS.icns /Applications/MacPorts/KDE4/lokalize.app/Contents/Resources/lokalize_SRCS.icns /Applications/MacPorts/KDE4/okteta.app/Contents/Resources/okteta_SRCS.icns /Applications/MacPorts/KDE4/umbrello.app/Contents/Resources/umbrello_SRCS.icns — KDevelop is the only one missing the 128x128 icon, which seems to be the reason for displaying the generic icon in dock if the app is not started. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Missing application icons of many KDE apps on MacPorts/OSX
This patch file does NOT yet achieve the expected up to now:
—
--- pics/CMakeLists.txt 2014-03-23 09:03:11.0 +0100
+++ pics/CMakeLists.txt.new 2014-03-23 09:12:01.0 +0100
@@ -7,3 +7,6 @@
### install files ###
kde4_install_icons(${ICON_INSTALL_DIR})
+
+#QT4_ADD_DBUS_ADAPTOR(kmymoney_SRCS org.kde.kmymoney.xml kmymoney.h
KMyMoneyApp)
+KDE4_ADD_APP_ICON( kdevelop_SRCS hi*-app-kdevelop.png )
—
Perhaps because there is no 128x128 pixel PNG yet?!
KMM has it, guess I’ll have to crosscheck the other apps or simply supply an
appropriate PNG resized to 128x128.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Missing application icons of many KDE apps on MacPorts/OSX
And now I see that there is also this line in KMM’s cmake file: QT4_ADD_DBUS_ADAPTOR(kmymoney_SRCS org.kde.kmymoney.xml kmymoney.h KMyMoneyApp) which is most certainly also important for something… ;-) How would that have to be adapted to e.g. KDevelop? >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Missing application icons of many KDE apps on MacPorts/OSX
Hi Thomas,
I indeed can’t find the needed statement in any CMakeLists.txt file in
KDevelop’s sources:
—
$ find . -name CMakeLists.txt -exec grep -l KDE4_ADD_APP_ICON {} \;
$
—
I haven’t crosschecked with other apps from my long list, but I guess that
explains it.
Thanks again,
Marko
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: ksycoca4
On 22 Mar 2014, at 23:41 , Ian Wadham wrote: > That is a normal message. It just tells you where KDE libs is looking for the > SyCoCa. OK. Good to know. > I see you are running your tutorial2 as if it was a UNIX or Linux app, i.e. by > direct execution of the executable file which the compile/build just created. > That Yes, simply because I wanted to see any console output, which is swallowed by the app if done via “open tutorial2.app”, as you described in your post. > See the thread "taskgated: no signature" on the MacPorts Users list for the > (slow) dawning of > my understanding of this. I am aware of this thread. > Try again? … :-) I did. :-) Well, the tutorial doesn’t fire up a web browser as it should be doing. :-( I assumed here that the KDE framework deals with the bug reporter menu item on its own and doesn’t require the tutorial code to implement anything to open up the browser. Please, correct me if I am wrong there. Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: ksycoca4
On 22 Mar 2014, at 22:28 , Thomas Lübking wrote: > Define "nothing" - and what would you have expected? > Do you return to the prompt or would you expect a window to show up? > A link to the tutorial code would be helpful (to know what it's supposed to > do) It’s just a very basic app and I forgot to mention that I chose the “Help/Report Bug…” from the programs menu and then clicked “Launch Bug Report Wizard”… But the app doesn’t fire up a browser at b.k.o as it was supposed to do. Sorry, I missed to describe that above, because I got distracted when I posted that before... >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Missing application icons of many KDE apps on MacPorts/OSX
On 22 Mar 2014, at 20:40 , Thomas Baumgart wrote: > I found the following in KMyMoneys kmymoney/CMakeLists.txt > KDE4_ADD_APP_ICON( kmymoney_SRCS hi*-app-kmymoney.png ) OK, Thomas, I’ll check whether I can find something like that for the other ports in question or not (and if not will file corresponding ticket(s) at bko). Thanks for the hint. Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Missing application icons of many KDE apps on MacPorts/OSX
[ I am cross-posting this also to KMyMoney’s and KDevelop’s mailing lists, because I hope for some synergy (see the example at the bottom of this post). ] Hi devs, I know, the following might not be a very pressing one, but it is a long-standing issue on MacPorts [1] Many KDE applications are not showing their application icon correctly. For visual people it can be a show-stopper, which is why I want to bring it up on KDE-DEVEL. Here in my MacPorts installation I have in KDE 4.12.2 in total 55 KDE applications listed in /Applications/MacPorts/KDE4/. ONLY 11 of these 55 actually show a proper application icon. (I could post a screenshot somewhere, in case of need.) Well, the apps which are able to supply an application icon are: dolphin.app kapptemplate.app kfind.app khelpcenter.app kmymoney.app kompare.app kuiviewer.app kwrite.app lokalize.app okteta.app umbrello.app Of the remaining 55 there are certainly some which belong to applications which are only launchers for something or helper apps, but some are certainly normal applications which should be supplying an icon. I consider the following as such: cervisia.app kate.app kdenlive.app kdevelop.app konqueror.app An example: - KMyMoney obviously does something differently compared to KDevelop, since the latter is on MacOSX/MacPorts NOT ABLE to deliver the application icon to OSX’ finder and dock. If one has added KDevelop to OSX’ dock, one can actually see only a generic Xcode-application-icon for KDevelop as long as it is not started. Once you start up KDevelop you’ll see that the icon immediately switches to the correct one. As soon as KDevelop is closed the icon reverts back to the generic one. However, KMyMoney does NOT do such a dance! Any ideas what could be the reason? Greets, Marko [1] https://trac.macports.org/ticket/27931 >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
ksycoca4
Hi, I just tried to start KDE's bug reporter from a little tutorial application on MacOSX, but I got this spat out at the console: — $ tutorial2.app/Contents/MacOS/tutorial2 tutorial2(1006)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from "/private/var/tmp/kdecache-marko/ksycoca4” — and nothing happened. I don’t know what goes wrong here. Perhaps nothing? Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: meinproc4 on Mac, KLocale (was Re: What to test for 4.13?)
On 19 Mar 2014, at 22:30 , Thomas Lübking wrote: > That the libxml2 bug is not related to the bug #261509 backtrace (doesn't > change anything since i anticipated that for social reasons ;-) Ah, ok, so that supports the notion that it was just an accidental coincidence. So, I am afraid we might really have what Ian suggested. A problem with concurrently running processes. meinproc uses some cache, does it perhaps cross-use data cached by other instances of meinproc and that collides with itself if there are parallel tasks running? >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: meinproc4 on Mac, KLocale (was Re: What to test for 4.13?)
On 19 Mar 2014, at 21:50 , Luigi Toscano wrote: > The crash described in that stack trace happens in a part of code which is > executed *before* initializing livxml. OK, and what do we learn from that? Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: meinproc4 on Mac, KLocale (was Re: What to test for 4.13?)
On 19 Mar 2014, at 06:29 , Thomas Lübking wrote: > There seems a known issue reg. multithreaded libxml2 [1], but since Marko was > the reporter, i simply ruled it out being the remaining one. I doubt it was a libxml2 issue, since the corresponding poster wrote — Hi on windows we had a similar crash. The problem was in libxml2, when builded with multithread support.Disabling multithread fixed it. — The crash I described back then happened with KMyMoney, but did occur for any other KDE software arbitrarily every now and then. I think in order to reproduce the error I’d also need to build stuff highly parallel with all 8 cores and in an an endless loop, but I’d need to get familiar with parallel and stuff alike, I am afraid… Well, let’s see what Ian can come up with once he’s done with partying his birthday. ;-) >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: meinproc4 on Mac, KLocale (was Re: What to test for 4.13?)
Hi Thomas, thanks for that clarification with code! :-) OK, now I see what you mean. I still wonder how and where you found this "str == NULL” issue… I must have seen some other stack trace then. Which one are you referring to, actually? Greets, Marko (who is now eventually truly off for tonight) >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: meinproc4 on Mac, KLocale (was Re: What to test for 4.13?)
So, I got all *.docbook files coming with kdelibs4 and copied them into a test directory and wrote a bash script which calls meinproc4 for every of those files. Of course there are now tons of warning because I obviously don’t have some needed files in certain directories which meinproc4 needs… A few html files get generated, but many won’t. So, just in case you can be bothered to give me a more hands-on hint which set of files I could let meinproc4 work on, that would be really cool. I guess it would be worthwhile to have inclusion of other references in there and all the stuff which would occur in a real package build/install. I hope I am not asking for too much, but it seems tedious for me to start to analyse some Makefile's or whatever now to try to mimic something close to a real documentation build. OK, now I am definitely off. Far too late already. :( >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: meinproc4 on Mac, KLocale (was Re: What to test for 4.13?)
On 18 Mar 2014, at 23:56 , Thomas Lübking wrote: > is NULL, thus try with an initial > > if (str == NULL) > return QString(); I didn’t grasp this quickly where I should insert that code, to tell you the truth. ;-) >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: meinproc4 on Mac, KLocale (was Re: What to test for 4.13?)
Luigi, before I am off for tonight I verified that I can start meinproc4 with lldb. Works. All I’d need now would be big and complex files to work on. Without doing any building of any port I’d want to just steal some XML/XSL source files perhaps from KDELIBS and let meinproc4 work on them in an endless loop. Perhaps I’d be able to see it crash in the debugger so that we get a few more stack traces. (Sorry, for now w/o debug symbols, but it’s a start.) Could you please point me to how I should organise which files in a test directory tree in such a way that meinproc would happily do its Sisyphus job?! OK, I am off for now, looking forward to suggestions now to get this going. :) Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: meinproc4 on Mac, KLocale (was Re: What to test for 4.13?)
On 18 Mar 2014, at 23:15 , Luigi Toscano wrote: > Ok: I've seen the other message, but then I would start from this and make > sure that the stacktrace is the correct one. Hmm… > Could you (or any other Mac user/developer) please try to > - recompile kdelibs with debug symbols Right now I am not able to do so (and I knew you’d ask for it…), because I haven’t set up a parallel install for debugging. That’s something I long planned to do since I migrated slowly to my new machine, but I haven’t achieved it YET. > - run meinproc4 on any document using the debugger, to get a complete > backtrace Ha, I tell you, that will be impossible, I am afraid, because those crashes come unpredictably... :-( > I guess that MacOSX uses lldb instead of gdb nowadays: I found this > http://lldb.llvm.org/tutorial.html > I shouldn't be too difficult, just run meinproc4 through the debugger with the > specified docbook (any docbook provided by KDE software) with lldb until it > crashes, and from its shell execute: > (lldb) thread backtrace all > > This is important to understand if the issue is really that one. Yep I know, but there is NO specific docbook, at least to my knowledge, which would always crash it. I wonder what Ian can add in here, since he is building docs all the time recently… I guess one would have to automate the procedure and let meinproc4 again and again build one or several files. Perhaps that’s a possibility. But I don’t know whether this could be automated with lldb… Needs some investigation, I guess. OK, I had hoped you had an idea to test this hypothesis with a minimal app, but I see we might have to do brute force on meinproc4 itself. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: meinproc4 on Mac, KLocale (was Re: What to test for 4.13?)
As shown in [1] I’ve got a working native KDE tutorial application started. So, now one could add whatever code you think is needed to test the issue observed with meinproc4. [1] http://mail.kde.org/pipermail/kdevelop/2014-March/018258.html >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: meinproc4 on Mac, KLocale (was Re: What to test for 4.13?)
Ages ago I was hunting a but in KDE’s about dialog and had set up a Mercurial repo for it on BitBucket [1]. One could use that location for the minor app which you’re suggesting. [1] https://bitbucket.org/mkae/kde-tests >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: meinproc4 on Mac, KLocale (was Re: What to test for 4.13?)
Hi Luigi, On 18 Mar 2014, at 14:33 , Luigi Toscano wrote: > I wonder why it happens only here and not in other applications; the crash is > in a innocent call to KGlobal. Do you know about similar crashes/stacktraces > in other applications? I don’t know whether this stack trace is representative, but the only one to start from. As pointed out this meinproc4 error always occurred only sporadically and unpredictably... :-( > I would really need some help from a real Mac programmer to find why that > snippet of code is crashing. Let's see if I can extract that code in simple > test program (any help or volunteer is appreciated), but I would need some > Mac > around to test it. Luigi, if you can put or suggest a minimal test program it would be helpful. One could use SVN access to your folder at KDE’s server, BitBucket via Mercurial or GitHub, whatever you like, to share the code. I am ready to support you if you need someone to build stuff on MacOSX. I am not a Mac developer though, but do have some experience building and testing apps on Linux and Mac. > For sure it needs to be fixed, the downstream solution of removing > documentation is non-solution. No, it is certainly not. When I installed KDevelop [1] I realised already that tons of documentation is missing in its man page browser, although it would be very helpful, like all the KDE stuff. ;-) Luckily the great KDevelop code reader show a lot of things already. Greets, Marko [1] http://mail.kde.org/pipermail/kdevelop/2014-March/018250.html >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: What to test for 4.13?
On 18 Mar 2014, at 00:17 , Luigi Toscano wrote: > I'm pretty sure meinproc4 does not depend on anything tex-related. Of course it does not. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: KDevelop on Apple OS X
Hi Ian, On 17 Mar 2014, at 01:20 , Ian Wadham wrote: > Alexander Dymo (adymo) is one of two former KDE developers now working on > Homebrew. > And he was one of the original developers of KDevelop. I remember him from > back then. > Do you fancy some "bridge building", Marko? I’ll will contact the KDevelop-Devel ML, as Aleix suggested. :) He’s surely listen in over there, I hope. > Please persevere with with your efforts on getting KDevelop going on > MacPorts, Marko. It I’ll definitely do so, since I was surprised to see that KDevelop already seems to be comparable to Qt-Creator these days. :-D > contains one of the finest code-readers around, AFAIK the best in the world. > I have used > it on Linux to gain an understanding of many a line of difficult C++ code. > Indispensable. If you say code-readers you mean that it gives you all those useful class definitions including documentation? Yes, I have to say that was impressive to see, since at least all the Qt classes where heavily referenced right from the start. Funnily enough only the KDE classes where NOT FOUND by KDevelop. I needed to specify their location manually, but that it worked seamlessly! :) So, I figure this is something which could be added already at install time, so that KDevelop does know about KDE right away. This must be possible, since it does work for Qt. OK, I am moving my discussion to kdevelop-devel herewith. Will come to it earliest tomorrow. Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: KDevelop on Apple OS X
Hi Aleix, On 17 Mar 2014, at 00:54 , Aleix Pol wrote: > First of all, KDevelop mailing lists are not dead, we did change our mailing > list to kde.org infrastructure, you might have looked at the wrong place [1]. Oh, I see now. I had realised that they had been moved a while ago. But when checking on the traffic I went to the user list and not to devel. On user the traffic is fairly low. I didn’t notice my mistake up to now. > We have some people already using KDevelop through homebrew on Mac OS X [2], > maybe using the same tools Alexander used will help, at least with the first > bug. OK, I Alexander knows how to avoid that little bug after template app creation. > Regarding the second one, it clearly seems like it's a bug in the cmake > integration. It hasn't been tested on Mac before so it can be just as well > that you're the first person trying that. Some further investigation will be > very much welcome. I would suggest following up in the kdevelop-devel mailing > list would be the best. Good. I’ll switch over to develop-devel for further discussion then. Thanks for your response. Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: KDevelop on Apple OS X
On 16 Mar 2014, at 22:02 , mk-li...@email.de wrote: > What I did was that I set up a project via “Project/New From > Template…/Project Type/Graphical”. Turns out I was creating a template for a QML application. I just tried a "Graphical C++ KDE” with the same sad result. But when I tried “Minimal C++ KDE” it worked! No crash, the application window comes up. So, I guess my speculation about the failing access to the application’s configuation files might not be that wrong... >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
KDevelop on Apple OS X
Hi devs, after having installed kdesdk4 successfully MacPorts needed only about 30s to install the residual handful of ports required by KDevelop. Now there is KDevelop 1.6.0 up and running. :) Well, before going further with questions I wonder whether I should address them to KDevelop’s mailing list (which seems to be quite dead) or rather stay here on KDE-DEVEL for the moment, since I am not sure whether it is a Mac specific issue or not. What I did was that I set up a project via “Project/New From Template…/Project Type/Graphical”. After running into a little issue with the temlate [1] I was able build the generated code with some warnings, but without a real error. :-) When I now start the application from the built app package I unfortunately get an error: — $ ./testgraphical file:///Users/marko/projects/TestGraphical/build/src/testgraphical.app/Contents/MacOS/: File not found Killed: 9 — I am surprised to see a message like this on the console. What does this mean? Which file does the app try to load and why does it fail to do so? KDevelop doesn’t allow me to step through the code in debug mode, so that I cannot say where exactly the issue occurred. I could imagine that the app tries to access its configuration which is stored on MacOSX in ~/Library/Preferences/KDE : — $ pwd /Users/marko/Library/Preferences/KDE/share/apps $ ls -1 RecentDocuments desktoptheme dolphin Kate kdenlive kdevappwizard kdevelop kfileplaces khelpcenter kssl plasma remoteview — As one can see, kdevelop itself already stores its stuff in there. I am clueless right now about how to further proceed. Hope you can push me into the right direction. Greets, Marko [1] https://bugs.kde.org/show_bug.cgi?id=329392 >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: What to test for 4.13?
On 16 Mar 2014, at 20:59 , Kevin Krammer wrote: > Yes, but those are build dependencies, right? Yep. > The binary packages are not affected by this, are they? No. It’s only a nuisance for those who need/want to build from scratch. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: What to test for 4.13?
On 16 Mar 2014, at 20:34 , Kevin Krammer wrote: > A dependency in two versions of GTK? > For a non-GUI program? I even had a case with a port (don’t remember which one though) where actually LaTeX was required just because there was some documentation stuff to be converted from tex to pdf… Imagine to have to build LaTeX just for generating a piece of documentation. LaTeX’s tools then also pull in X11 due to ImageMagick and poplar! (It never ends.) >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: What to test for 4.13?
On 16 Mar 2014, at 20:34 , Kevin Krammer wrote: > A dependency in two versions of GTK? > For a non-GUI program? > Oh dear. Yup. :-( > Wouldn't it make more sense to make the native variants the default? Well, I would think so, but it’s historically grown, so the maintainers tried their best to get all functionality by default into the lib. I wonder how one could get rid of these criss-cross dependencies... >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: What to test for 4.13?
Below another example of kdelibs4’s dependencies, which shows that soprano is the port requiring all the X11. Ian already mentioned libsdl, but also virtuoso and gtk[23]… (I’ve stripped all non-X11 port from that tree.) But, things get more complex when you start looking at other ports. There is the possibility to use non-X11 variants, but they are not selected by default. And, usually you run sooner or later into inconsistencies, because certain ports might require e.g. a cairo variant +x11 and other -x11… So, it’s not an easy undertaking to disentangle all this. :-( — The following ports are dependencies of kdelibs4 @4.12.2_0: soprano strigi ffmpeg libsdl xorg-libXext xorg-util-macros xorg-libX11 xorg-xtrans xorg-bigreqsproto xorg-xcmiscproto xorg-xextproto xorg-xf86bigfontproto xorg-inputproto xorg-libXdmcp xorg-xproto xorg-libXau xorg-libxcb xorg-xcb-proto xorg-libpthread-stubs xorg-kbproto xorg-libXrandr xrender xorg-renderproto xorg-randrproto gtk2 pango Xft2 xorg-libXi xorg-libXfixes xorg-fixesproto xorg-libXcursor xorg-libXinerama xorg-xineramaproto xorg-libXdamage xorg-damageproto xorg-libXcomposite xorg-compositeproto virtuoso ImageMagick djvulibre librsvg gtk3 at-spi2-atk at-spi2-core xorg-libice xorg-libsm xorg-libXtst xorg-recordproto xorg-libXevie xorg-evieproto ghostscript xorg-libXt >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: What to test for 4.13?
Hi Luigi, On 16 Mar 2014, at 14:14 , Luigi Toscano wrote: > It would be interesting to know what are those issues. All the dependencies > for those packages are regularly packaged in many Linux distributions where > the licenses have been properly checked. OK, with this — $ bash mp-distributable.sh cervisia "cervisia" is not distributable because its license "lglp" is not known to be distributable $ bash mp-distributable.sh antlr "antlr" is distributable — it turns out that: 1) cervisia’s portfile just doesn’t use a proper identifier for the license, which needs to be fixed. 2) probably there wasn’t any binary port yet on the buildbot server for some reason, since it is marked as distributable. So there wasn’t actually a license conflict. (Mind that I was just speculating about it in my previous post.) Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: What to test for 4.13?
Hi Kevin, >> Hmm, it does apply also to KDE software, since it may use a library which >> isn’t permitting binary-only distribution. > I find this hard to believe. That would mean this is a KDE application that > is > not available on Linux distributions. hmmm, well, I remember there was some discussions a while ago concerning those license issues… MacPort’s infrastructure checks whether the license settings defined permit the distribution. I’ll check these issue and post the information I can find here. (Just now also Luigi asked for it.) > I have no clue about that either but my naive approach would have been to > check the build input files for Windows branches and check if the deviation > is > something compiler specific (or similar like paths), or non-X11 platform > stuff. Well, I guess it’s worth exploring those dependencies to check where code is pulled in which is not really needed for KDE with a qt4-mac-based Qt installation. >> And thanks to the buildbots the MacPorts infrastructure can make sure that a >> a new version of any committed portfile will always be build immediately >> and thus explicitly verify for all four supported versions of MacOSX that >> the port binaries can be build just fine. THAT is very close to CI, isn’t >> it?! > Are the build results published somewhere? A website or mailinglist one can > subscribe to? Yes, the buildbots (see e.g. [1]) keep all the logs, so that each port maintainer can figure out what went wrong on which buildbot. Let’s take [2] as an example where I had committed a new version of the port for AqBanking version 5. The waterfall graph [3] (scroll down to 14:46:03) shows that only one of the four buildbots (Snow Leopard) was a able to successfully build the port. Its orange compile stage even gives you a list of warnings and errors during the build. The other three failing buildbots turn out to have trouble due to SVN: --- svn: OPTIONS of 'https://svn.macports.org/repository/macports/contrib/mpab': Server certificate verification failed: issuer is not trusted (https://svn.macports.org) — which was due to maintenance work being carried out at the time of the commit. OK, that’s all regarding CI on MacPorts for now. Will try to find the information concerning the licenses now. Greets, Marko [1] https://build.macports.org/buildslaves [2] https://build.macports.org/changes/34958 [3] https://build.macports.org/waterfall?last_time=1394457731 >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: What to test for 4.13?
Hi Kevin, On 16 Mar 2014, at 11:07 , Kevin Krammer wrote: > I didn't mean to imply or suggest that the design was flawed or anything like > that. ok. > Ian wrote something about build dependencies and building which kind of > didn't go > well with my mental model of Mac users. I see. > I hardly know any Mac user who would build software so they would not be > affected by build dependencies. Neither do I, personally I mean. But there are many on MacPorts! >> Also one has to point out that MacPorts DELIBERATELY does not distribute >> port binaries which use code with a licence which isn’t allowing binary >> distribution. This is good and considerate design in my eyes. > > Right. Doesn't apply to KDE software but certainly the right thing to do in > the wider scope. Hmm, it does apply also to KDE software, since it may use a library which isn’t permitting binary-only distribution. >> Yes, it’s hugely difficult to get KDE applications to build without any X11 >> deps. > > Any idea why? Most applications should not have any X11 dependency, those > available on Windows definitely don’t. Well, good question! Unfortunately I am not knowledgeable enough to answer this easily now. I am busy with all of this since about 3 years and I haven’t dived into the depths of X11 on MacOSX (XQuartz), Cocoa and the vast dependency tree of MacPorts’ ports. I just know that I did my best trying to remove all dependencies to X11 for KMyMoney back then, but had a really hard time, because some tools in these many dependencies might need some little GTK application or so… It’s a major undertaking to unwind all these dependencies and figure out where and why exactly a certain X11 lib is needed. But there is a dependency tree view possible for any application. By using that one can locate which lib needs what. An example of that can be seen in my post from March 12th @ 21:31. >> Well, their philosophy is: OFFER EVERYTHING for the usual OSX user, as >> up-to-date as possible, so that no-one misses anything later. Back then - >> when there were no port binaries distributed - this would mean hours and >> hours and hours of building X11 and Qt and KDE… A pain to get started with >> any Qt[34] application, I tell you! > > "usual OSX user" and "hours of building" just don't match in my experience. > "hours of building" and "usual user" doesn't match on any platform I know of. You are absolutely right. MacPorts doesn’t target those who can only manage to go to the AppStore and click on icons. It’s merely for geeks, I guess. But it does a pretty good job already, once you’ve understood the needed workflows. Their website explains everything sufficiently to get started - if you’re not afraid of the command line. > That assumption seemed to have been wrong with Macports actually having pre- > built software and having building as a separate option. As I said, the pre-built ports came up only a year ago or so, but MacPorts is far older. I think it just shows the evolution of the project. It was time to switch from solely port building from scratch to binary distribution wherever possible. And they made it happen. :) > My updated understanding is now that it is very much like a Linux package > repository, where users can just install and run the software without having > to care about building and dependencies. Correct, let me cite their website’s 1st sentence: The MacPorts Project is an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading either command-line, X11 or Aqua based open-source software on the OS X operating system. > Basically a FOSS app store. Yep, driven by a perhaps a dozen very active MacPorts infrastructure developers and a few hundred port maintainers. Have a look at their port repository which contains about 18000 ports! You’d find almost everything you wish for if you have a Linux background. When I switched to MacOSX I missed so many tools (Qt, KDE, MySQL, mercurial, git, cctools, boost, autojump, doxygen, xsltproc, mc, recode), but MacPorts gave them back to me almost pain-free! Your system gets updated whenever a port maintainer decides to commit an updated portfile. So, one does not need to worry about how to deinstall old software versions from the depths of your iMac’s file system, but instead can sit back and rely on MacPorts’ logic to keep everything up-to-date, which generally works fine and with very little interactive user action. The plus is that you usually have stable and up-to-date software installed. For KMyMoney 4.6 - for instance - there are two ports kmymoney4 and kmymoney4-devel. The first is always the latest release version, whereas the devel port distributes a version which I try to keep as close as possible to its git's HEAD version, i.e. is always bleeding edge. The user decides what she/he wants. And thanks to the buildbots the MacPorts infrastructure can make sure that a
Re: What to test for 4.13?
Hi folks, for testing I have just tried to install MacPorts’ port kdesdk4 (which includes dolphin) and it worked like a charm, except a minor issue which turned out to be not a dolphin-one [1]. All dependent ports got installed w/o problems on Mac OS X 10.9.2 within just a very few minutes (due to binary versions of most ports required): --- $ sudo port install kdesdk4 ---> Computing dependencies for kdesdk4 ---> Dependencies to be installed: cervisia dolphin-plugins kde4-baseapps nepomuk-widgets kapptemplate kcachegrind4 kde-dev-scripts kde-dev-utils kdesdk-kioslaves kdesdk-strigi-analyzers kdesdk-thumbnailers kompare libkomparediff2 lokalize okteta poxml antlr umbrello --- where only cervisia and antlr needed to be built from sources (certainly due to some license issues). :-) I haven’t done any further testing so far - except the tiny dolphin-issue, but I’d say this is an example for great interoperatibility of the KDE framework and its apps. Greets, Marko [1] https://bugs.kde.org/show_bug.cgi?id=332202 >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: MacPorts: Running KDE ports on Apple OS X
Hi folks, although it’s not KDE, but “only” pure Qt, still I thought it is worth mentioning: Thanks to support by its developer I was able to bring AT-Transfers [1] seamlessly via MacPorts to MacOSX [2] with only a few tweaks to make the Qt-Creator project build no problem. This shall support what has been said about the usability of Qt/KDE applications on Apple’s OS. Greets, Marko [1] http://schmufu.dyndns.org/dokuwiki/ab_transfer:start [2] http://www.macports.org/ports.php?by=name&substr=abtransfers >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: What to test for 4.13?
Hi Frank, On 15 Mar 2014, at 17:30 , Frank Reininghaus wrote: > I apologize for making this statement then. It was done in response to :) Accepted. > a message which described at least some parts of KDE on Mac as > severely broken, said that Mac users use 4-letter words when talking I wasn’t aware of any 4-letter words. Sad that people who invest their spare time into giant project like this have to be faced with stuff like that. I absolutely understand where you are coming from. > It's good to know that the situation is not as bad as it seemed. > Thanks for your message that clarified this. Yep, I simply had to shout it out loud and clear. :) Certainly there are broken things every now and then, but luckily there are people dealing with it, investing time and effort to fix things by patches and if they can’t be sorted out sending bug reports and alike. I don’t know if the KDE developers know about the patches being used for the various KDE ports at MacPorts… Perhaps these would also be a good starting point for improving KDE step by step by communicating these patches upstream if that hadn’t happened up to now, so that they can be introduced in your code after review. Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: What to test for 4.13?
Hi Kevin, On 14 Mar 2014, at 09:46 , Kevin Krammer wrote: > I hadn't imagined that a packaging effort for OSX would do that as well. My > assmption was that especially on OSX one wouldn't want end users to have to > deal with that. > > My obviously uneducated guess would have been that it would be more similar > to > Windows, i.e. having a single app store like installer that would download > and > install everything needed by the chosen applications. > > Maybe that is something the OSX packaging community should have a look into. I have been using Linux and especially KDE since its earliest days. (My first Linux was a S.u.S.E. 4.4 and I never gave up on Linux since then. Still I am running a few OpenSUSE servers at work, my private laptop is OpenSUSE and my daughter’s as well.) I.e. I am coming from a Linux background. 4 years ago I got my 1st iMac as a present. I myself would never have bought one, because of its ridiculous price! :) I was happy enough with my old Linux machine up to then. But then in 2010 I suddenly had this present on my desk and I loved the large screen from the first minute on. BUT, I missed my KDE apps, especially KMyMoney which actually had saved my life back then in 2007 or so... Luckily I heard about MacPorts and on the 2nd day with my iMac I had it up and running and had been amazed by the relative ease with which almost all the Open Source software I was used to use on Linux could be installed on the iMac! Back then they didn’t have the buildbot infrastructure up and running, so everyone was forced to build every single port from scratch - just like Gentoo does. MacPorts allows to install a variety of compilers, unix/linux tools, KDE or Gnome apps, … AND many of them are at the tip of development!!! So, e.g. KDE is at version 4.12.2!!! (My SuSE’s were never as current as MacPorts has been in years.) And, I want to underline that the building of almost all KDE4 ports seems to have been going flawless in the last while. Which is amazing, given there are almost no KDE core developers on MacOSX. ===>>> So, stating "we should seriously consider dropping MacOS support IMHO, to prevent further discredit being done to KDE” is doing neither side any good! :-) Quite the opposite - I think the fact that KDE is still alive on MacPorts is an amazing example of what Open Source can achieve and that should be cherished and praised - which is what I do herewith. :-) And I won’t consider MacPorts' installation from sources as a design flaw, it is partly just a development state on the way to become an open-source software distribution system (not only) for Apple’s MacOSX. If I am not mistaken you can run MacPorts also on Linux. :-) So, in fact the system allows every port maintainer to locally create new ports which will eventually checked in through SVN into MacPorts’ port tree, so that the buildbots automatically start building them for the currently supported 4 MacOSX versions. The buildbots keep the responsible maintainers informed about any problems during those builds. This information is then used to investigate further and file a bug report on bug.kde.org or at Digia. Also one has to point out that MacPorts DELIBERATELY does not distribute port binaries which use code with a licence which isn’t allowing binary distribution. This is good and considerate design in my eyes. >> Maybe there are some non-KDE packages which require the libsdl library >> and they require the +x11 variant, so then everybody gets it. Just as >> KGoldrunner gets Nepomuk, et al. … ;-) > > That is a serious packaging problem then. Yes, it’s hugely difficult to get KDE applications to build without any X11 deps. Up to a certain point I offered no_x11 and no_gtk variants for KMyMoney, but as Ian wrote probably almost no-one made use of them. And those who did did run into trouble sooner or later if they installed other KDE or GTK applications. > Or rather there seems to be a huge gap between the target audience of the mac > packaing effort and the people wanting to use it. > Has anyone pointed that out to them? Well, their philosophy is: OFFER EVERYTHING for the usual OSX user, as up-to-date as possible, so that no-one misses anything later. Back then - when there were no port binaries distributed - this would mean hours and hours and hours of building X11 and Qt and KDE… A pain to get started with any Qt[34] application, I tell you! > And is there no packaing community targetting the usual OSX users? It is! It’s called MacPorts. ;-) Seriously, they really do a great job keeping MacPorts itself and all its ports going! The community is very active, the developer and user mailing lists are responsive (200-300+ posts/month aren't too bad, I think) and the communication is always friendly. Herewith I want to conclude once again that KDE4 is alive on MacPorts. Let’s keep it so, together! :-) Thanks to everyone involved!!! Greets, Marko P.S.: Af
Re: MacPorts: Running KDE ports on Apple OS X
On 15 Mar 2014, at 13:35 , Thomas Lübking wrote: > On Samstag, 15. März 2014 12:07:46 CEST, René JV Bertin wrote: >> and who knows maybe even support KWin for those of us using X11 apps ... > What's your concern here? > X11 on OSX should be provided by XQuartz which should provide native OSX > titlebars (and integration into the OSX WM) Actually Qt4 gets installed in its native version as port qt4-mac these days. This means that XQuartz (X11.app) isn’t started at all to run KDE apps, if I am not mistaken. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Running KDE apps on Apple OS X
On 12 Mar 2014, at 19:44 , John Layt wrote: > But what we need most right now is a Mac experienced sysadmin to take > on setting up and maintaining the Mac infrastructure, then a > fundraiser to get the hardware. And for people to start talking to > each other on kde-mac. Well, one could also contact the MacPorts guys in order to learn how they set up their CI environment which is based on several buildbots for the currently supported four MacOSX versions 10.6.x-10.9.x. They for instance do make use of virtualised servers for this job. There is a “hardcore maintainer" who keeps qt4-mac going, but he hasn’t dealt with Qt5 up to now, mainly because he is alone with this job and needs support himself. So, I guess going towards KF5 is still impossible. One would have to go for Qt5 first. His work wrt Qt4 is a major task, so I guess it will be equally hard to install Qt5 through MacPorts. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: What to test for 4.13?
Hi Kevin, On 12 Mar 2014, at 14:46 , Kevin Krammer wrote: > Anyway, my point was that X11 should not be a dependency on a non-X11 > platform, just like it is not on Windows. Well, I always tried to keep all X11 stuff away from the KDE apps I installed. But unfortunately even KMyMoney and kdenlive cannot be build w/o xorg-libX11: --- $ port rdependents xorg-libX11 The following ports are dependent on xorg-libX11: ImageMagick dvdauthor kdenlive libdmtx prison kdepimlibs4 kde4-runtime kmymoney4-devel virtuoso soprano akonadi kdelibs4 kactivities libalkimia mobipocket nepomuk-core xorg-libXext cairo frei0r-plugins mlt gobject-introspection atk pango gnuplot policykit poppler poppler-qt4-mac py27-gobject dbus-python27 harfbuzz py27-cairo ghostscript libsdl ffmpeg minidlna strigi libmpeg2 libsdl_image libsdl_mixer smpeg — There are quite a few nasty dependencies here. kmymoney4-devel of course also depends on nepomuk-core and thus it is quite a hassle to remove all the dependencies to X11, ALTHOUGH qt4 got installed as qt4-mac, i.e. is a native and non-X11 install!!! You are right, it’s not an easy situation on MacPorts… Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: What to test for 4.13?
On 11 Mar 2014, at 04:05 , Ian Wadham wrote: > I am seriously interested in this problem of running KDE apps > on Apple Mac OS X and would like to do something to solve it, > but I am going to need help and advice on the internals of > KDE --- or an up-to-date set of design and architecture > documentation … :-) +1 > To Ben Cooksley: I have the deepest respect for Sysadmin and > what you do, but I do not think Continuous Integration is an issue > in this case. Bugs that occur in KDE apps in an Apple environment > also tend to occur in a Linux environment and vice versa, otherwise > I could not fix bugs on Apple OS X that are reported in other O/S’s. +1 > Bugs that occur in KDE apps and KDE libraries and are specific to an > Apple environment are rather rare and can be handled in the usual > ways via bugzilla. +1 >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Running KDE apps on Apple OS X
Hi Ian, thanks for your initiative!!! I am not a software engineer - but just a Linux/MacOSX hobby-coder - and since 4 years I am trying to keep KMyMoney (KMM) alive on MacOSX via MacPorts during my spare time [0]. That’s how the two of us initially got to know each other! :-) — INSET — Well, here I simple MUST mention that I always had A LOT OF GREAT SUPPORT from the KMM developers whenever I ran into trouble getting KMM to build on MacPorts. For the last four years I was running MacOSX 10.6.x and since a quarter of a year I am using MacOSX 10.9.x - successfully building KMM 4.6.x and almost always at master’s HEAD! :-) When I started using MacOSX four years ago there was KMM 1.0.3 available (still using KDE3) since someone else had created a functional port for it on MacPorts. :) That and the KMM devs helped me a lot setting up a new port for KMM 4.5 in Nov 2010! :-D After a while I switched over to keep my finances under control only by KMM 4.x! — INSET — Well, but just you, mention there are again and again little problems with the underlying KDE framework. Luckily there were and up to now are very active MacPorts maintainers who tried/try to keep kdelibs3 and kdelibs4 afloat on MacOSX via the MacPorts port system. Thank god!!! To my horror I’ve seen already two maintainers give up on kdelibs4 in the past four years, which is a shame and very sad. I - personally - would find it very sad if KMM would disappear because of KDE dropping support for MacOSX!!! So, I hope that this initiative might be a spark which motivates more people to get involved here. I have - just like you, Ian - tried TO FIND help here on KDE-DEVEL (as well as on KDE-MAC) all these years and I was grateful for every hint I got - given the low number of MacOSX users to be found in there. Whenever I find a bug in KMM or KDE I DO TRY TO PIN IT DOWN as much as possible and address it to the relevant bug reporters on https://bugs.kde.org (e.g. open [2,3]) or https://bugreports.qt-project.org (e.g. open [4,5]). A most annoying bug is related to meinproc4 [6] (as you, Ian, already mentioned) which is bugging me on MacPorts with KMM and other KDE-apps since years. But unfortunately it shows a very indeterministic behaviour and I couldn’t come forward there. Only in Dec 2013 / Jan 2014 there was finally movement, but I haven’t yet followed that up… I could grab my own nose and try to investigate what had been changed there to find out whether other apps would build without this annoyance from now on, like e.g. KMM! :-/ ——>>> Would be a good thing to start with, I guess. 8-) — NOTE — I am deliberately listing all those references to show that there are people trying their best, and I am not the only one on MacPorts, Homebrew, Fink, etc. That shall be enough in response to what has been uttered in this list’s thread “What to test for 4.13" and I don’t want to put more oil into the fire but rather like to calm the waves and come to a constructive level. I - for my part - will always try to contribute as best as I can and as I have done in the past to KDE, KMM and also wxWidgets as another example [7]. — NOTE — On 11 Mar 2014, at 04:15 , Ian Wadham wrote: > I need some ongoing help, advice and mentoring from time to > time as I investigate why some KDE apps run OK on Apple > OS X and others do not. The problem is simply stated. So would I. > Most KDE apps build and run well in Apple OS X. The difficult > ones are the more complex ones --- and the ones that are in > demand from Apple users --- such as Digikam, Kdenlive, > KDevelop and Amarok. I have recently only tested kdenlive myself - and it works!!! :-) > The case of kbuildsysoca4 is a good example. Yes, indeed, luckily the kdelibs4 port since then installs a user launch agent which takes care of running kbuildsyscoca4 periodically to avoid most of the trouble. > But I need help, guidance and mentoring as I dive into > KDE internals. Any offers will be gratefully accepted. Dito. For completeness I want to add, that I try with scrooge to maintain also another alternative financial KDE-application on MacPorts [8]. Best regards to all devs on this list, Marko ——— References [0] http://www.macports.org/ports.php?by=name&substr=kmymoney [1] Thread "[Kmymoney2-developer] SUCCESS: v4.5 runs on Mac OS X” @ 2 Nov 2010 [2] https://bugs.kde.org/show_bug.cgi?id=279194 [3] https://bugs.kde.org/show_bug.cgi?id=316404 [4] https://bugreports.qt-project.org/browse/QTBUG-19873 [5] https://bugreports.qt-project.org/browse/QTBUG-32943 [6] https://bugs.kde.org/show_bug.cgi?id=261509 [7] http://trac.wxwidgets.org/ticket/15345 [8] http://www.macports.org/ports.php?by=name&substr=skrooge >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
How to tell CMake to NOT GENERATE any kind of files for documentation purposes?
Hi devs, I keep having trouble trying to build the KDE application KMyMoney4 without documentation. With ccmake I can see that all settings with relevance to documentation issues are set to off: --- KDE4_ENABLE_HTMLHANDBOOK OFF USE_DEVELOPER_DOCOFF USE_HTML_HANDBOOKOFF --- However, when building meinproc4 is being called frequently, which is exactly what I would like to prevent from happening due to a nasty-hard-to-locate-since-spurious-segfault... It looks like there is no explicit switch which disallows building the API doc. Is this assumption correct? If yes, how can I avoid calling meinproc4 in the build process anyway? Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Question concerning editing of OVERDUE schedules
On Jan 26, 2013, at 2:38 PM, Thomas Baumgart wrote: > p.s. I am pretty sure you wanted to send this to kmymoney-devel instead of > kde-devel, right? Hence I am switching lists here Sorry, wrong list, yes! :-/ >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Question concerning editing of OVERDUE schedules
BTW, is it a bug or a feature that the editor doesn't allow to edit overdue payments of schedules? >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: [KDE/Mac] KDE 4.9.5, kde4-runtime build error
> On Jan 6, 2013, at 11:45 PM, mk-li...@email.de wrote: >> :info:build Undefined symbols: >> :info:build "GlobalShortcutsRegistry::keyPressed(int)", referenced from: >> :info:build KGlobalAccelImpl::keyPressed(int)in kglobalaccel_mac.o >> :info:build ld: symbol(s) not found > > Thanks to Nicos I've learnt by now that it is essential to build kdelibs4 > with -DKDE4_AUTH_BACKEND_NAME="OSX" to get his working fine, > or was it mainly due to the removal of -DKDE4_ENABLE_FINAL=ON from configure > options?? Sorry, I have to draw back what I just wrote. Performing another update with original files from MacPorts kde4-runtime still breaks because of the above error! :-( >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: [KDE/Mac] KDE 4.9.5, kde4-runtime build error
On Jan 6, 2013, at 11:45 PM, mk-li...@email.de wrote: > :info:build Undefined symbols: > :info:build "GlobalShortcutsRegistry::keyPressed(int)", referenced from: > :info:build KGlobalAccelImpl::keyPressed(int)in kglobalaccel_mac.o > :info:build ld: symbol(s) not found Thanks to Nicos I've learnt by now that it is essential to build kdelibs4 with -DKDE4_AUTH_BACKEND_NAME="OSX" to get his working fine, or was it mainly due to the removal of -DKDE4_ENABLE_FINAL=ON from configure options?? >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
KDE 4.9.5, kde4-runtime build error
While trying to upgrade my KDE from 4.9.3 to 4.9.5 installed through MacPorts all went smoothly for kdelibs4 kactivities nepomuk-core kdepimlibs4 oxygen-icons redland but for kde4-runtime I finally ran into an undefined symbol: :info:build cd /opt/macports-test/var/macports/build/_Users_marko_WC_MacPorts_ports_kde_kde4-runtime/kde4-runtime/work/build/knotify && /opt/macports-test/bin/qdbusxml2cpp -m -p kspeechinterface /opt/macports-test/share/dbus-1/interfaces/org.kde.KSpeech.xml :info:build /usr/bin/g++-4.2 -pipe -O2 -arch x86_64 -fno-common -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual -fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden -O2 -DNDEBUG -DQT_NO_DEBUG -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -arch x86_64 CMakeFiles/kglobalaccel.dir/kglobalaccel_automoc.o CMakeFiles/kglobalaccel.dir/kglobalaccel_dummy.o CMakeFiles/kglobalaccel.dir/kglobalaccel_mac.o -o kglobalaccel ../lib/libkdeinit4_kglobalaccel.dylib ../lib/libkdeinit4_kglobalaccel.dylib /opt/macports-test/lib/libkio.5.9.5.dylib /opt/macports-test/lib/libQtNetwork.dylib /opt/macports-test/lib/libQtXml.dylib /opt/macports-test/lib/libkdeui.5.9.5.dylib /opt/macports-test/lib/libQtGui.dylib /opt/macports-test/lib/libQtSvg.dylib /opt/macports-test/lib/libkdecore.5.9.5.dylib /opt/macports-test/lib/libQtDBus.dylib /opt/macports-test/lib/libQtCore.dylib -framework Carbon :info:build Undefined symbols: :info:build "GlobalShortcutsRegistry::keyPressed(int)", referenced from: :info:build KGlobalAccelImpl::keyPressed(int)in kglobalaccel_mac.o :info:build ld: symbol(s) not found :info:build collect2: ld returned 1 exit status :info:build make[2]: *** [kglobalaccel/kglobalaccel] Error 1 :info:build make[2]: Leaving directory `/opt/macports-test/var/macports/build/_Users_marko_WC_MacPorts_ports_kde_kde4-runtime/kde4-runtime/work/build' :info:build make[1]: *** [kglobalaccel/CMakeFiles/kglobalaccel.dir/all] Error 2 :info:build make[1]: *** Waiting for unfinished jobs…. What can be done about this? A happy New Year to everyone, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: is kdepimlibs4 a necessary dependency of kde4-runtime
On Nov 1, 2012, at 7:55 PM, Ben Cooksley wrote: > It is stored in the KDE Git repository kde-build-metadata, which you > can get from git://anongit.kde.org/kde-build-metadata > The file "dependency-data" is located in that repository. Thanks very much! That's helpful. Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: is kdepimlibs4 a necessary dependency of kde4-runtime
On Nov 1, 2012, at 7:50 PM, Ben Cooksley wrote: > Per kde-build-metadata:dependency-data: Where exactly do I find this data? > kde/kde-runtime: kdesupport/strigi/libstreams[master] > kde/kde-runtime: kde/kdelibs/kactivities > kde/kde-runtime: kdesupport/attica[master] > kde/kde-runtime: kde/kdepimlibs Ah, ok, good to know! Thanks, Ben! Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
is kdepimlibs4 a necessary dependency of kde4-runtime
I was wondering whether kdepimlibs4 is a necessary dependency of kde4-runtime... >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Fwd: Trying latest KDE 4.9.2
I got a compilation error in kactivities-4.9.2/service/main.cpp:79:
---
static void initSignalCatching() {
#ifndef Q_OS_WIN32 // krazy:skip
struct sigaction action;
::sigemptyset(&action.sa_mask); // << this
is line 79 where compiling fails
action.sa_flags = 0;
/* Use the sa_sigaction field because the handles has two additional
parameters */
action.sa_handler = signalHandler;
::sigaction(SIGINT, &action, NULL);
::sigaction(SIGHUP, &action, NULL);
::sigaction(SIGTERM, &action, NULL);
::sigaction(SIGSEGV, &action, NULL);
#endif
}
---
leads to an error:
---
:info:build
/opt/macports-test/var/macports/build/_Users_marko_WC_MacPorts_ports_kde_kactivities/kactivities/work/kactivities-4.9.2/service/main.cpp:
In function ‘void initSignalCatching()’::info:build
/opt/macports-test/var/macports/build/_Users_marko_WC_MacPorts_ports_kde_kactivities/kactivities/work/kactivities-4.9.2/service/main.cpp:79:
error: expected id-expression before ‘(’ token:info:build make[2]: ***
[service/CMakeFiles/activity-manager.dir/main.o] Error 1
:info:build make[2]: Leaving directory
`/opt/macports-test/var/macports/build/_Users_marko_WC_MacPorts_ports_kde_kactivities/kactivities/work/build'
:info:build make[1]: *** [service/CMakeFiles/activity-manager.dir/all] Error 2
:info:build make[1]: *** Waiting for unfinished jobs
:info:build /opt/macports-test/bin/cmake -E cmake_progress_report
/opt/macports-test/var/macports/build/_Users_marko_WC
---
Obviously gcc doesn't like "::sigemptyset()" in that static function!
Removing the "::" in front of sigemptyset() fixes it!
Could it be that sigemptyset() is actually a macro?
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Trying to build kdepimlibs 4.9.2 on MacOSX fails during linking nepomuk
I still can't believe that my last silly try succeeded just now with these
changes to the configuration:
configure.args-append \
-DNEPOMUK_LIBRARIES:FILEPATH=/opt/macports-test/lib/libnepomuk.dylib \
-DNEPOMUK_QUERY_LIBRARIES:FILEPATH=/opt/macports-test/lib/libnepomukquery.dylib
\
-DNEPOMUK_UTILS_LIBRARIES:FILEPATH=/opt/macports-test/lib/libnepomukutils.dylib
# -DNEPOMUK_LIBRARIES=${prefix}/lib
It seems to me that cmake's logic is missing that specifying
"-DNEPOMUK_LIBRARIES=${prefix}/lib"
should be sufficient to fill
"-DNEPOMUK_LIBRARIES:FILEPATH"
with the correct file path
"/opt/macports-test/lib/libnepomuk.dylib"
in order to let the build succeed.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Trying to build kdepimlibs 4.9.2 on MacOSX fails during linking nepomuk
Hi devs, I was trying to build kdepimlibs 4.9.2 on MacOSX 10.6.8... While it was possible to install kdelibs4 almost without trouble (with some fixes concerning missing Nepomuk header files) I FAILED with kdepimlibs. All was built fine, but linking gives trouble. Nepomuk libs are installed and e.g. AllTags() can be found in here: --- $ dyldinfo -export /opt/macports-test/lib/libnepomuk.dylib | grep allTag 0x000286B0 __ZN7Nepomuk3Tag7allTagsEv --- Do you have any idea why the links step does NOT include the nepomuk libs: --- :info:build cd /opt/macports-test/var/macports/build/_Users_marko_WC_MacPorts_ports_kde_kdepimlibs4/kdepimlibs4/work/build/akonadi/contact && /opt/macports-test/bin/cmake -E cmake_link_script CMakeFiles/akonadi-contact.dir/link.txt --verbose=1 :info:build /usr/bin/g++-4.2 -pipe -O2 -arch x86_64 -fno-common -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual -fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden -fexceptions -UQT_NO_EXCEPTIONS -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -fexceptions -UQT_NO_EXCEPTIONS -O2 -DNDEBUG -DQT_NO_DEBUG -arch x86_64 -isysroot / -mmacosx-version-min=10.6 -dynamiclib -Wl,-headerpad_max_install_names -single_module -multiply_defined suppress -arch x86_64 -compatibility_version 4.0.0 -current_version 4.9.2 -o ../../lib/libakonadi-contact.4.9.2.dylib -install_name /opt/macports-test/lib/libakonadi-contact.4.dylib CMakeFiles/akonadi-contact.dir/akonadi-contact_automoc.o CMakeFiles/akonadi-contact.dir/abstractcontactformatter.o CMakeFiles/akonadi-contact.dir/abstractcontactgroupformatter.o CMakeFiles/akonadi-contact.dir /attributeregistrar.o CMakeFiles/akonadi-contact.dir/collectionfiltermodel.o CMakeFiles/akonadi-contact.dir/contactcompletionmodel.o CMakeFiles/akonadi-contact.dir/contactdefaultactions.o CMakeFiles/akonadi-contact.dir/contacteditor.o CMakeFiles/akonadi-contact.dir/contacteditordialog.o CMakeFiles/akonadi-contact.dir/contactgroupeditor.o CMakeFiles/akonadi-contact.dir/contactgroupeditordelegate.o CMakeFiles/akonadi-contact.dir/contactgroupeditordialog.o CMakeFiles/akonadi-contact.dir/contactgrouplineedit.o CMakeFiles/akonadi-contact.dir/contactgroupexpandjob.o CMakeFiles/akonadi-contact.dir/contactgroupmodel.o CMakeFiles/akonadi-contact.dir/contactgroupsearchjob.o CMakeFiles/akonadi-contact.dir/contactgroupviewer.o CMakeFiles/akonadi-contact.dir/contactgroupviewerdialog.o CMakeFiles/akonadi-contact.dir/contactmetadata.o CMakeFiles/akonadi-contact.dir/contactmetadataattribute.o CMakeFiles/akonadi-contact.dir/contactsearchjob.o CMakeFiles/akonadi-contact.dir/contactsfilterprox ymodel.o CMakeFiles/akonadi-contact.dir/contactstreemodel.o CMakeFiles/akonadi-contact.dir/contactviewer.o CMakeFiles/akonadi-contact.dir/contactviewerdialog.o CMakeFiles/akonadi-contact.dir/customfields.o CMakeFiles/akonadi-contact.dir/customfieldmanager.o CMakeFiles/akonadi-contact.dir/emailaddressselection.o CMakeFiles/akonadi-contact.dir/emailaddressselectiondialog.o CMakeFiles/akonadi-contact.dir/emailaddressselectionproxymodel.o CMakeFiles/akonadi-contact.dir/emailaddressselectionwidget.o CMakeFiles/akonadi-contact.dir/textbrowser.o CMakeFiles/akonadi-contact.dir/leafextensionproxymodel.o CMakeFiles/akonadi-contact.dir/recentcontactscollections.o CMakeFiles/akonadi-contact.dir/recentcontactscollectionrequestjob.o CMakeFiles/akonadi-contact.dir/standardcontactactionmanager.o CMakeFiles/akonadi-contact.dir/standardcontactformatter.o CMakeFiles/akonadi-contact.dir/standardcontactgroupformatter.o CMakeFiles/akonadi-contact.dir/waitingoverlay.o CMakeFiles/akonadi-contact.di r/actions/dialphonenumberaction.o CMakeFiles/akonadi-contact.dir/actions/showaddressaction.o CMakeFiles/akonadi-contact.dir/actions/qdialer.o CMakeFiles/akonadi-contact.dir/actions/qskypedialer.o CMakeFiles/akonadi-contact.dir/actions/sendsmsaction.o CMakeFiles/akonadi-contact.dir/actions/smsdialog.o CMakeFiles/akonadi-contact.dir/contactactionssettings.o CMakeFiles/akonadi-contact.dir/editor/addresseditwidget.o CMakeFiles/akonadi-contact.dir/editor/categorieseditwidget.o CMakeFiles/akonadi-contact.dir/editor/contacteditorwidget.o CMakeFiles/akonadi-contact.dir/editor/customfieldeditordialog.o CMakeFiles/akonadi-contact.dir/editor/customfieldsdelegate.o CMakeFiles/akonadi-contact.dir/editor/customfieldseditwidget.o CMakeFiles/akonadi-contact.dir/editor/customfieldsmodel.o CMakeFiles/akonadi-contact.dir/editor/dateeditwidget.o CMakeFiles/akonadi-contact.dir/editor/displaynameeditwidget.o CMakeFiles/akonadi-contact.dir/editor/emaileditwidget.o CMakeFiles/akonadi-contact.dir/ed itor/freebusyeditwidget.o CMakeFiles/akonadi-contact.dir/editor/geoeditwidget.o CMakeFiles/akonadi-contact.dir/editor/im/imdelegate.o CMakeFiles/akonadi-contact.dir/editor/im/imeditordi
Re: Problems starting akonadi on MacOSX
On Oct 21, 2012, at 12:43 AM, mk-li...@email.de wrote: > Looks like Qt needs to be installed including its MySQL drivers. I guess > that's something to be checked first… Sorry for the nose. Problem solved. After installing the MySQL-plugins for Qt all worked fine. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Problems starting akonadi on MacOSX
On Oct 21, 2012, at 12:37 AM, mk-li...@email.de wrote: > QSqlDatabase: QMYSQL driver not loaded > QSqlDatabase: available drivers: QSQLITE Looks like Qt needs to be installed including its MySQL drivers. I guess that's something to be checked first... >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Problems starting akonadi on MacOSX
Hi devs,
when trying to start akonadi on a KDE4-installation via MacPorts on MacOSX one
gets these errors:
---
$ /opt/macports-test/bin/akonadictl start
Starting Akonadi Server...
done.
Connecting to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
search paths: ("/Users/marko/bin", "/opt/macports-test/bin",
"/opt/macports-test/sbin", "/opt/macports-test/libexec/gnubin", "/usr/bin",
"/bin", "/usr/sbin", "/sbin", "/usr/local/bin", "/usr/local/MacGPG2/bin",
"/usr/texbin", "/usr/X11/bin", "/usr/sbin", "/usr/local/sbin",
"/usr/local/libexec", "/usr/libexec", "/opt/mysql/libexec",
"/opt/local/lib/mysql5/bin", "/opt/mysql/sbin", "/Applications/KDE4")
Found mysql_install_db: ""
Found mysqlcheck: ""
QSqlDatabase: QMYSQL driver not loaded
QSqlDatabase: available drivers: QSQLITE
Invalid database object during database server startup
"[
0: 0 akonadiserver 0x0001b43b _Z11akBacktracev
+ 59
1: 1 akonadiserver 0x0001b78c
_ZL19defaultCrashHandleri + 268
2: 2 libSystem.B.dylib 0x7fff8a4841ba _sigtramp + 26
3: 3 ??? 0x0008d9a0 0x0 + 58
4: 4 libQtCore.4.dylib 0x000100220b85
_Z17qt_message_output9QtMsgTypePKc + 117
5: 5 akonadiserver 0x0001d75a
_ZN15FileDebugStream9writeDataEPKcx + 170
6: 6 libQtCore.4.dylib 0x0001002c84d0
_ZN9QIODevice5writeEPKcx + 128
7: 7 libQtCore.4.dylib 0x0001002d55f6
_ZN18QTextStreamPrivate16flushWriteBufferEv + 230
8: 8 libQtCore.4.dylib 0x0001002d5958
_ZN11QTextStreamD2Ev + 104
9: 9 akonadiserver 0x0001000b36b3
_ZN13DbConfigMysql19startInternalServerEv + 10675
10: 10 akonadiserver 0x0001fb8a
_ZN7Akonadi13AkonadiServer20startDatabaseProcessEv + 202
11: 11 akonadiserver 0x000100011fd0
_ZN7Akonadi13AkonadiServerC2EP7QObject + 192
12: 12 akonadiserver 0x0001000139a7
_ZN7Akonadi13AkonadiServer8instanceEv + 71
13: 13 akonadiserver 0x000144ef main + 975
14: 14 akonadiserver 0x000140e8 start + 52
15: 15 ??? 0x0001 0x0 + 1
]
"
---
What's going on here?
For some reason the driver QMYSQL is not loaded!
What could be done to diagnose the cause of this?
Greets,
Marko
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: When does kbuildsycoca4 run?
> Technically it needs to be run if new .desktop files are installed. Is the assumption correct that the run would have to be carried out by the user and not by root? >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
