Re: Hidden KDED desktop file crashing systemsettings - where to fix?

[Sebastian Trüg]

On 11/02/2010 09:26 AM, Jonathan Marten wrote:
> Dear all,
> 
> Since it got committed to trunk a few days ago, the new activity
> manager (kdebase/runtime/activitymanager) crashes the "kcmkded"
> systemsettings module:
> 
> ASSERT: "file.desktopGroup().readEntry("X-KDE-ServiceTypes") == "KDEDModule""
> in file /ws/trunk/kdebase/runtime/kcontrol/kded/kcmkded.cpp, line 190
> 
> This seems to be because it installs a desktop file
> (share/kde4/services/kded/activitymanager.desktop) which contains
> only:
> 
> [Desktop Entry]
> Hidden=true
> 
> KDEDConfig::load() simply lists all the desktop files in the "kded"
> subdirectory - it does not check whether the desktop file is hidden,
> therefore hitting the assert later.
> 
> So my question: where is the best place to fix this?  Should it be:
> 
> a) add the required (plus some dummy) entries to
> activitymanager.desktop, until its final version is in place.  Just
> adding X-KDE-ServiceTypes=KDEDModule, though, fixes the assert but
> shows a blank service entry in the list.
> 
> b) check for file.desktopGroup().readEntry("Hidden", false) just
> before the assert, and continue the loop if so.
> 
> c) use a KServiceTypeTrader query (which hopefully ignores hidden
> desktop files) instead of listing them.
> 
> Even if we say that (a) is the solution for this particular instance,
> it still leaves an unexpected catch in this systemsettings module
> (desktop files here cannot be hidden in the same way as others).  So
> should one of (b) or (c) be implemented also?

c seems the correct solution here. Isn't that what the service type
trader is for anyway?

Cheers,
Sebastian

Re: [PATCH] Re: KDE 4.6.0: go or no go?

[Sebastian Trüg]

This patch does in no way solve the issue.

On 01/20/2011 02:00 PM, Dirk Mueller wrote:
> On Wednesday 19 January 2011, Dirk Mueller wrote:
> 
>> so the general consensus seems to be against slipping the schedule and
>> inserting a RC3.
>>
>> This means that we need to solve bug 246678. Given that there seems to be
>> no fix in sight (no comment in the last 14 days), can we mitigate it. is
>> there a way to disable whatever causes the problem by default? what would
>> be the patch for that?
> 
> Hi,
> 
> I think the attached patch should make the services be disabled by default, 
> thereby avoiding kde bug 246678. I'm asking for a review and a comment 
> whether 
> we can go ahead with this workaround for KDE 4.6.0. 
> 
> As the general consensus was (previously) already against slipping the 
> schedule, I need a solution NOW to be able to release 4.6.0 in time. 
> 
> Please review/comment. 
> 
> Thanks,
> Dirk
> 

Re: [PATCH] Re: KDE 4.6.0: go or no go?

[Sebastian Trüg]

On 01/20/2011 03:18 PM, Sebastian Trüg wrote:
> This patch does in no way solve the issue.

Let me give some detail here: I only did see the disabling of Strigi
which makes no sense.
I am fine with disabling the KRunner plugin for now. But AFAIK this only
is a problem in combination with Akonadi.
I did improve the KRunner situation though. Normally it should not
create ugly queries anymore. At least I did not see it again.

The patches Will posted do provide a real solution. However, they still
have the problem that existing data needs to be converted to a certain
degree. This took roughly half an hour for me.

I could strip the patch down, remove parts of it. But honestly I am not
comfortable with doing that now. I would rather do that for 4.6.1.

Cheers,
Sebastian

> 
> On 01/20/2011 02:00 PM, Dirk Mueller wrote:
>> On Wednesday 19 January 2011, Dirk Mueller wrote:
>>
>>> so the general consensus seems to be against slipping the schedule and
>>> inserting a RC3.
>>>
>>> This means that we need to solve bug 246678. Given that there seems to be
>>> no fix in sight (no comment in the last 14 days), can we mitigate it. is
>>> there a way to disable whatever causes the problem by default? what would
>>> be the patch for that?
>>
>> Hi,
>>
>> I think the attached patch should make the services be disabled by default, 
>> thereby avoiding kde bug 246678. I'm asking for a review and a comment 
>> whether 
>> we can go ahead with this workaround for KDE 4.6.0. 
>>
>> As the general consensus was (previously) already against slipping the 
>> schedule, I need a solution NOW to be able to release 4.6.0 in time. 
>>
>> Please review/comment. 
>>
>> Thanks,
>> Dirk
>>
> 

Policy on git feature branches

[Sebastian Trüg]

Hi list,

I have been working on an improvement for Nepomuk via git-svn for a
while now and would now like to push it to kde-runtime.
However, I would prefer to keep the commit history and backport to 4.6.
Thus, I thought of pushing my feature branch into the kde-runtime
repository and then merge it into master and 4.6. Is this an acceptable
way to handle such a situation? Or should I merge locally only and then
push both master and 4.6?

Cheers,
Sebastian

Re: Policy on git feature branches

[Sebastian Trüg]

On 02/01/2011 11:11 AM, Andreas Pakulat wrote:
> On 01.02.11 10:21:01, Sebastian Trüg wrote:
>> Hi list,
>>
>> I have been working on an improvement for Nepomuk via git-svn for a
>> while now and would now like to push it to kde-runtime.
> 
> If the branch has been created via git-svn you cannot merge it properly.
> You need to cherry-pick all commits.
> 
>> However, I would prefer to keep the commit history and backport to 4.6.
>> Thus, I thought of pushing my feature branch into the kde-runtime
> 
> That won't work, as git-svn created different commits for all the history
> your branch is based on. So git cannot merge your branch into kde-runtimes
> history. The only options are to either cherry-pick all commits or rebase
> your feature branch onto kde-runtime as it is now. Then you can merge it.

I did cherry-pick them all into a new branch in my local kde-runtime clone.

> Merging itself should be local, the history of the branch will be preserved
> anyway (specify --no-ff in case git merge decides to try a fast-forward)
> even if you don't push the feature branch into the remote repository.

So I merge into master and 4.6 locally and then simply push the two, right?

Cheers,
Sebastian

Re: Policy on git feature branches

[Sebastian Trüg]

On 02/01/2011 01:21 PM, Andreas Pakulat wrote:
> On 01.02.11 13:05:49, Sebastian Trüg wrote:
>> On 02/01/2011 11:11 AM, Andreas Pakulat wrote:
>>> On 01.02.11 10:21:01, Sebastian Trüg wrote:
>>>> Hi list,
>>>>
>>>> I have been working on an improvement for Nepomuk via git-svn for a
>>>> while now and would now like to push it to kde-runtime.
>>>
>>> If the branch has been created via git-svn you cannot merge it properly.
>>> You need to cherry-pick all commits.
>>>
>>>> However, I would prefer to keep the commit history and backport to 4.6.
>>>> Thus, I thought of pushing my feature branch into the kde-runtime
>>>
>>> That won't work, as git-svn created different commits for all the history
>>> your branch is based on. So git cannot merge your branch into kde-runtimes
>>> history. The only options are to either cherry-pick all commits or rebase
>>> your feature branch onto kde-runtime as it is now. Then you can merge it.
>>
>> I did cherry-pick them all into a new branch in my local kde-runtime clone.
>>
>>> Merging itself should be local, the history of the branch will be preserved
>>> anyway (specify --no-ff in case git merge decides to try a fast-forward)
>>> even if you don't push the feature branch into the remote repository.
>>
>> So I merge into master and 4.6 locally and then simply push the two, right?
> 
> Yes. Except that I thought 4.6 was staying feature-frozen not only in
> kdelibs but also kde-runtime and other modules. But then I don't follow
> that stuff closely, so maybe I'm wrong.

It is not really a feature. "Just" a fix/improvement/whatever which is
rather heavy.

Cheers,
Sebastian

Re: Usage of pull rebasing and merges

[Sebastian Trüg]

Hi Ben,

could you please elaborate on this. I do not understand the problem at
all. What is so bad about rebasing and what is wrong with the commit you
mention?

Cheers,
Sebastian

On 02/08/2011 09:20 AM, Ben Cooksley wrote:
> Hi all,
> 
> Just a word of warning, if you are going to merge two branches
> together, make sure to run "git pull --rebase" before you conduct the
> merge. Once you have conducted the merge, use "git pull" if you
> encounter a non-fast forward error. Do not run "git pull --rebase"
> after performing the merge, under any circumstances.
> 
> If you do a "git pull --rebase" after performing a merge, then the
> merge, as well as all the commits it pulled in will be rebased, along
> with the attached consequences of that. This is what caused commits
> such as http://article.gmane.org/gmane.comp.kde.cvs/1008397 to be
> pushed.
> 
> Regards,
> Ben
> 

Re: Usage of pull rebasing and merges

[Sebastian Trüg]

Hi Ben,

thanks for clarifying. :)
Another point to add to my growing list of git tips.

Cheers,
Sebastian

On 02/08/2011 10:08 AM, Ben Cooksley wrote:
> On Tue, Feb 8, 2011 at 9:49 PM, Sebastian Trüg  wrote:
>> Hi Ben,
>>
>> could you please elaborate on this. I do not understand the problem at
>> all. What is so bad about rebasing and what is wrong with the commit you
>> mention?
>>
>> Cheers,
>> Sebastian
> 
> Hi Sebastian,
> 
> The problem in this case isn't rebasing itself, but doing a pull
> rebase after doing a merge.
> If you do a pull rebase after a merge, then *all* the commits you just
> merged in will be rebased as part of that process.
> 
> This will cause new commits to be created which has the effect of:
> - Increasing the repository size
> - Causing the commit hooks to run for those commits, repeating any
> keyword actions in the process
> 
> The commit I pointed to was wrong because it was a commit which had
> been rebased from elsewhere, yet was unchanged other than it's
> metadata.
> 
>>
>> On 02/08/2011 09:20 AM, Ben Cooksley wrote:
>>> Hi all,
>>>
>>> Just a word of warning, if you are going to merge two branches
>>> together, make sure to run "git pull --rebase" before you conduct the
>>> merge. Once you have conducted the merge, use "git pull" if you
>>> encounter a non-fast forward error. Do not run "git pull --rebase"
>>> after performing the merge, under any circumstances.
>>>
>>> If you do a "git pull --rebase" after performing a merge, then the
>>> merge, as well as all the commits it pulled in will be rebased, along
>>> with the attached consequences of that. This is what caused commits
>>> such as http://article.gmane.org/gmane.comp.kde.cvs/1008397 to be
>>> pushed.
>>>
>>> Regards,
>>> Ben
>>>
>>
> 
> Regards,
> Ben
> 

Re: QZeitgeist and Phonon

[Sebastian Trüg]

On 03/08/2011 09:53 AM, Ivan Cukic wrote:
> Hi all,
> 
> First of all, one thing to mention - KDE apps are not advised to use 
> QtZeitgeist directly because that way the 'tracking' has no idea about the 
> activities.
> 
> File/resource tracking (and thus rating) should be per activity - as an 
> example, there is no point in showing java docs that you used in 
> 'Developing J2EE application' activity in a 'KDE development activity'.
> 
> The classes that should be used are KActivity* which will soon enter 
> kdelibs/experimental.
> 
> The activity manager (the dbus service behind KActivity classes) will have 
> both Zeitgeist and Nepomuk as backends. (both as optional deps)
> 
> ---
> 
> Zeitgeist vs Nepomuk
> 
> Sebastian concluded that storing all the events in Nepomuk wouldn't be 
> wise, so it was agreed to store them in Zeitgeist which was designed with 
> that sole purpose.

to be precise: I wanted to test storing all in Nepomuk first which I
have not done yet.

> My current intention is the following (for the activity manager)
>   - Store all events in Zeitgeist making it possible to have more advanced
> queries like 'files opened last week between tue and sat in the
> ewening'
>   - Store only per-activity scores in nepomuk making it possible to have
> 'which are the most common files opened in kate during some activity'

how do you do that?

Cheers,
Sebastian

> 
> After this, we can do all kinds of magic even if not both Z and N are 
> running.
> 
> Cheerio,
> Ivan
> 
> 
> 

Re: QZeitgeist and Phonon

[Sebastian Trüg]

On 03/08/2011 12:13 PM, Ivan Čukić wrote:
>>> Sebastian concluded that storing all the events in Nepomuk wouldn't be
>>> wise, so it was agreed to store them in Zeitgeist which was designed with
>>> that sole purpose.
>>
>> to be precise: I wanted to test storing all in Nepomuk first which I
>> have not done yet.
> 
> I didn't know that. If it turns out it behaves well, both backends
> will be feature-complete.
> 
>>>   - Store only per-activity scores in nepomuk making it possible to have
>>> 'which are the most common files opened in kate during some activity'
>>
>> how do you do that?
> 
> I haven't written an ontology for that yet, but it works like this
> (i've been testing it with dummy code - still have to port it to KAMD)
> UsageScore:  (I need a better name for this)
> score (calculated via the magic of the exp function as previously 
> discussed)
> activity
> application
> resource

You mean you have one resource which relates a resource to an activity
and has a score and an application?

Could you elaborate, please?

Cheers,
Sebastian

Re: QZeitgeist and Phonon

[Sebastian Trüg]

On 03/08/2011 08:58 PM, todd rme wrote:
> On Tue, Mar 8, 2011 at 5:57 AM, Sebastian Trüg  wrote:
>>
>>
>> On 03/08/2011 09:53 AM, Ivan Cukic wrote:
>>> Hi all,
>>>
>>> First of all, one thing to mention - KDE apps are not advised to use
>>> QtZeitgeist directly because that way the 'tracking' has no idea about the
>>> activities.
>>>
>>> File/resource tracking (and thus rating) should be per activity - as an
>>> example, there is no point in showing java docs that you used in
>>> 'Developing J2EE application' activity in a 'KDE development activity'.
>>>
>>> The classes that should be used are KActivity* which will soon enter
>>> kdelibs/experimental.
>>>
>>> The activity manager (the dbus service behind KActivity classes) will have
>>> both Zeitgeist and Nepomuk as backends. (both as optional deps)
>>>
>>> ---
>>>
>>> Zeitgeist vs Nepomuk
>>>
>>> Sebastian concluded that storing all the events in Nepomuk wouldn't be
>>> wise, so it was agreed to store them in Zeitgeist which was designed with
>>> that sole purpose.
>>
>> to be precise: I wanted to test storing all in Nepomuk first which I
>> have not done yet.
> 
> Does this mean you would want to give nepomuk this capability if the
> tests are successful?

it is only about storing the data. There is no point in recreating all
the zeitgeist plugins. But storing the data in Nepomuk makes a lot of
sense since then it can be queried in combination with any other data as
compared to only being able to list usage times.

Cheers,
Sebastian

Re: QZeitgeist and Phonon

[Sebastian Trüg]

Hi Ivan,

sorry for the late reply.

On 03/08/2011 07:18 PM, Ivan Cukic wrote:
>> You mean you have one resource which relates a resource to an activity
>> and has a score and an application?
>>
>> Could you elaborate, please?
> 
> In essence, the relation is (resource, application, activity)* and has a 
> score.
> 
> (*in terms of relational dbs this would be a primary key)
> 
> This allows making summarized (resource, app) and (resource, activity) and 
> (resource) queries.

This is not really more detailed than what you said before. Could you
please tell me what exactly you store in Nepomuk.

Cheers,
Sebastian

Re: QZeitgeist and Phonon

[Sebastian Trüg]

OK, now I get it. So you in fact create one new resource for each
activity/app/resource combination.

So how does this work if I want to get a score over all apps, ie. the
most important files in the current activity?

BTW: We are encoding apps as NAO::Agent() instances in the data
mangement service. Did you already do something here? What are you using?

Cheers,
Sebastian

On 03/16/2011 10:47 AM, Ivan Cukic wrote:
> 
>>> This allows making summarized (resource, app) and (resource,
>>> activity) and (resource) queries.
>>
>> This is not really more detailed than what you said before. Could you
>> please tell me what exactly you store in Nepomuk.
> 
> Ok, I'll try to explain in more details. If it is not sufficient, you'll 
> have to say what exactly you don't get from it. (it was the thing I 
> planned from the start, so in my head it is rather self-explanatory :) )
> 
> -
> First of all, a reminder
> 
> UsageScore, as already stated, consists of:
> activity
> application
> resource
> score
> (and it has the last modification timestamp)
> 
> -
> Algorithm
> 
> An application notifies the daemon that the resource was accessed and 
> passes the following triple* to it (eventActivity, eventApplication, 
> eventResource)
> 
> * triple as in math structure, not as in semantic triple
> 
> We check whether we already have a UsageScore instance that matches the 
> input data
> (activity = eventActivity, application = eventApplication, resource = 
> eventResource, score = *)
> 
> If we don't {
>Create a new UsageScore instance and set the passed data, along with a
>predefined constant for the score = 0
> }
> 
> Change the score of the existing UsageScore (the one we found if it 
> existed, or the one we just created in the 'if' section above). The score 
> is calculated according to the formula defined a few months ago.
> 
> I've yet to add the difference between events for open/modify/close as 
> discussed before. But those will not change the data stored in N.
> 
> Ch
> 
> 
> 

Re: Backwards compatibility for shared desktop ontologies?

[Sebastian Trüg]

My comments as I am the one who introduced the break:

First off: I think the system does work. IMHO I am not the only one only
thinking about these dates shortly before they arrive. Thus, the hard
freeze is there to have time to fix issues like these. But that is just
my personal opinion.

As for SDO: the cardinality change was long due. I agree that it should
have been done sooner. But well, the harm is done. Reverting it is not
possible, the cardinalities are required. Introducing some hack in SDO
is not a good idea IMOH since it would only be there for the one tool,
namely nepomuk-rcgen. Thus, if anything was to be hacked, it would be that.

As far as dependencies go: KDE-PIM 4.7 does NOT depend on kdelibs 4.7
now since kdelibs <4.7 builds fine with SDO 0.7. Thus, it is perfectly
possible to have SDO 0.7, kdelibs 4.6.x, and kdepim 4.7 on one system.

KDE-PIM < 4.7 is another problem as it does not build against kdelibs
4.7. But then again: who does that? I know that is not a great argument,
but really, why would you update kdelibs and kde-runtime and friends but
not kde-pim, now that we finally have a kde-pim release with the rest of
kde again?
If someone wanted to do that there are two ways to make that happen:
1. Create another release of kde-pim <4.7 which introduces the mentioned
#ifdefs.
2. Patch nepomuk-rcgen to always generate both set and add methods.

With the above solution (both are very little code, 1. is of course more
trouble as it involves another release) the following is possible:

1. package SDO < 0.7, kdelibs < 4.7, and kdepim < 4.7
2. package SDO >= 0.7, kdelibs < 4.7, and kdepim >= 4.7
3. package SDO >= 0.7, kdelibs >= 4.7, and kdepim < 4.7
4. package SDO >= 0.7, kdelibs >= 4.7, and kdepim >= 4.7

Are any important combinations missing here?

Cheers,
Sebastian

On 05/17/2011 11:14 AM, Stephen Kelly wrote:
> 
> Hi,
> 
> = Executive Summary =
> 
> The new Shared Desktop Ontologies version 0.7 changes in a backwards 
> incompatible way compared to version 0.6. kdelibs master already depends on 
> SDO 0.7. kdepim-runtime master also now depends on SDO 0.7. 
> 
> kdepim4.4 still builds, because it happens to not use the backward-
> incompatible generated code.
> 
> kdepim-runtime4.6 no longer builds against kdelibs4.7 and SDO 
> 0.7. 
> 
> I think this should block beta 1 tagging until resolved.
> 
> = Details =
> 
> SDO is used to generate C++ code for nepomuk in some way using the rcgen 
> tool (which comes from kdelibs). See 
> 
> https://projects.kde.org/projects/kde/kdepim-
> runtime/repository/revisions/master/entry/agents/ontologies/CMakeLists.txt
> 
> and the code generated in your build directory for kdepim-
> runtime.git/agents/ontologies
> 
> There are two issues to raise from this.
> 
> == First issue: backwards incompatibility ==
> 
> SDO 0.7 changes cardinalities of certain properties, causing the generated 
> code to be different to what it was before.
> 
> The code generated is source incompatible with what was generated in 
> previous versions, so the code in kdepim-runtime master was updated:
> 
> https://projects.kde.org/projects/kde/kdepim-
> runtime/repository/revisions/c6b255476c3c62ccdfb30a96e551af0e58d9c990/diff
> 
> This means that 
> 
> a) kdepim-runtime master depends on kdelibs master, although the intention 
> with kdepim is to depend on the most recent kdelibs release or later.
> b) as kdelibs4.7 depends on SDO 0.7, and SDO 0.7 can't be installed 
> alongside SDO 0.6 (afaik), packagers can no longer build kdepim4.4 and 
> kdepim-runtime4.6 against kdelibs4.7 because the code generated by rcgen 
> (which comes from kdelibs and processes SDO) is different. Methods like 
> setStreetAddresses have been removed and methods like setStreetAddress have 
> been added. From what I can tell, this change relates to optimization in 
> virtuoso queries.
> 
> Here's the relevant threads I can find about this:
> 
> http://thread.gmane.org/gmane.comp.kde.devel.pim/30489
> 
> http://thread.gmane.org/gmane.comp.kde.devel.pim/30478
> 
> http://thread.gmane.org/gmane.comp.kde.devel.pim/30474
> 
> I see a few possible solutions.
> 
> 0) Ignore it. Make it impossible to build/package kdepim4.6 against kdelibs 
> 4.7 and SDO 0.7. This is the current situation afaik.
> 
> 1) Revert the dependency bump. Make kdelibs depend on a version of SDO that 
> does not introduce backwards incompatibility breakage. This means reverting 
> c6b255476c3c62ccdfb30a96e551af0e58d9c990 and 
> f84602273ac22eb540a36a1681ed051e5d12c3f5 in kdepim-runtime and 
> 2e1704ddfda6ae53ec2793129f2700601ac6f31b in kdelibs.
> 
> 2) Add a new property to SDO like backwardCompatibleCardinalities = true
> and make rcgen process that and generate *both* setStreetAddresses and 
> setStreetAddress if it is found.
> 
> 3) Make rcgen generate *both* setStreetAddresses and setStreetAddress all 
> the time, and generate a KDE_DEPRECATED macro for the setStreetAddresses in 
> the case of cardinality=1.
> 
> 4) Make rcgen gene

Re: Backwards compatibility for shared desktop ontologies?

[Sebastian Trüg]

On 05/17/2011 03:22 PM, Thiago Macieira wrote:
> On Tuesday, 17 de May de 2011 12:08:50 Sebastian Trüg wrote:
>> KDE-PIM < 4.7 is another problem as it does not build against kdelibs
>> 4.7. But then again: who does that?
> 
> That means breaking source compatibility. If you do that, please update the 
> version number of kdelibs to 5.0.

So then I will patch the rcgen to always generate both if cardinality is
1. That is no problem.

Cheers,
Sebastian

Re: Backwards compatibility for shared desktop ontologies?

[Sebastian Trüg]

pre-nepomuk versions do not count as they will compile anyway. :)

On 05/17/2011 12:24 PM, Christoph Feck wrote:
> On Tuesday 17 May 2011 12:08:50 Sebastian Trüg wrote:
>> KDE-PIM < 4.7 is another problem as it does not build against kdelibs
>> 4.7. But then again: who does that?
> 
> *raise hand*
> 
> I guess I am not alone when I say that I would like to keep KDEPIM 4.4 until 
> the teething troubles and memory/speed issues in Akonadi/Nepomuk are 
> resolved (watching bug reports for both). Unfortunately, I cannot help here, 
> as my databases voodoo is less than zero.
> 
> Christoph Feck (kdepepo)
> KDE Quality Team
> 

Re: Backwards compatibility for shared desktop ontologies?

[Sebastian Trüg]

On 05/17/2011 12:48 PM, Stephen Kelly wrote:
> Sebastian Trüg wrote:
> 
>> First off: I think the system does work. IMHO I am not the only one only
>> thinking about these dates shortly before they arrive. Thus, the hard
>> freeze is there to have time to fix issues like these. But that is just
>> my personal opinion.
> 
> Yes, the freeze is there to resolve these issues, as I wrote too, but if 
> such a big break appears on the day of freeze (a week before beta tagging) 
> after hibernating in a branch for 5 months, then *something* is broken. 
> That's just my opinion. 
> 
> I don't think having a 'Major feature freeze' and a 'Minor feature freeze' 
> is a sensible thing to do, but KDE developers should keep in mind that they 
> should introduce breakage or potential breakage months before freeze. So 
> there's probably no structural or scheduling solution, but only a community 
> one.
> 
>> As for SDO: the cardinality change was long due. I agree that it should
>> have been done sooner. But well, the harm is done. Reverting it is not
>> possible
> 
> How could reverting it not be possible? It seems perfectly possible to me. 
> It's just a revert in kdelibs and kdepim-runtime.
> 
>> , the cardinalities are required. Introducing some hack in SDO
>> is not a good idea IMOH since it would only be there for the one tool,
>> namely nepomuk-rcgen. Thus, if anything was to be hacked, it would be
>> that.
> 
> Right. 3 of the solutions I proposed (the ones I prefer) are to hack rcgen.
> 
> Are none of the solutions I proposed acceptable?
> 
>> As far as dependencies go: KDE-PIM 4.7 does NOT depend on kdelibs 4.7
>> now since kdelibs <4.7 builds fine with SDO 0.7. Thus, it is perfectly
>> possible to have SDO 0.7, kdelibs 4.6.x, and kdepim 4.7 on one system.
> 
> Ok.
> 
>>
>> KDE-PIM < 4.7 is another problem as it does not build against kdelibs
>> 4.7. But then again: who does that? 
> 
> Packagers apparently. They've raised the issue on the mailing list and on 
> IRC. Either KDE makes guarantees or KDE does not make guarantees.
> 
>> I know that is not a great argument,
>> but really, why would you update kdelibs and kde-runtime and friends but
>> not kde-pim, now that we finally have a kde-pim release with the rest of
>> kde again?
> 
> A release alone doesn't make it usable for everyone. While most are happy 
> with it, some are not. See this comment on my blog: 
> http://steveire.wordpress.com/2011/05/15/kde-pim-4-6-rc1/#comment-2206.
> 
> The comment is too vague to take any action, but it shows that people do 
> still have issues on the new stack. 
> 
> The fact is that the new platform does not work for everyone and does have 
> bugs and regressions, and people will want to use old versions of kdepim 
> with new kdelibs. 
> 
> The release is a development milestone less than a bugfix milestone.
> 
> Apparently I was not correct about kdepim4.4 working with kdelibs4.7, so 
> that is relevant.
> 
>> If someone wanted to do that there are two ways to make that happen:
>> 1. Create another release of kde-pim <4.7 which introduces the mentioned
>> #ifdefs.
>> 2. Patch nepomuk-rcgen to always generate both set and add methods.
>>
> 
> Ok, this looks like the list I created, but with different numbers, which 
> can only add to confusion. Your (1) is my (5). Your (2) is my (3) or (4), 
> depending on what you have in mind. 
> 
> As I said, I'd be fine with my (2), (3) or (4). You say my (2) is not a good 
> idea because it is only relevant to rcgen. That leaves my (3) and (4). What 
> solution do you propose? When can we expect a fix to be written, reviewed 
> and tested? Keep in mind that beta 1 tagging is supposed to happen on 
> Thursday.

Like I already said: patching rcgen seems like the best solution to me
and that is so trivial I can have finished it today.

Cheers,
Sebastian

Re: Moving nepomuk-system-tray to kdereview

[Sebastian Trüg]

On 05/26/2011 07:33 PM, Albert Astals Cid wrote:
> A Thursday, May 26, 2011, Christoph Feck va escriure:
>> On Monday 17 January 2011 22:29:18 Artem Serebriyskiy wrote:
>>> Hi everyone,
>>> I would like to move Nepomuk-system-tray from playground to kdereview
>>> Currently project is:
>>> project
>>> page>> y ?jump=welcome> git: g...@git.kde.org:nepomuk-system-tray
>>
>> What is the status of this project? Has it been integrated into
>> kde-runtime?
> 
> AFAIR trueg said that what is in kdereview is deprecated and should not be 
> there.

Deprecated is the wrong word here. IMHO it is not mature enough.
Otherwise I would have chosen it for inclusion into kde-runtime instead
of the "classical" nepomukcontroller.

I will ping the author and ask him to move it back.

Cheers,
Sebastian

Re: Moving nepomuk-system-tray to kdereview

[Sebastian Trüg]

On 05/26/2011 10:11 PM, Ben Cooksley wrote:
> On Fri, May 27, 2011 at 6:01 AM, Sebastian Trüg  wrote:
>> On 05/26/2011 07:33 PM, Albert Astals Cid wrote:
>>> A Thursday, May 26, 2011, Christoph Feck va escriure:
>>>> On Monday 17 January 2011 22:29:18 Artem Serebriyskiy wrote:
>>>>> Hi everyone,
>>>>> I would like to move Nepomuk-system-tray from playground to kdereview
>>>>> Currently project is:
>>>>> project
>>>>> page<https://projects.kde.org/projects/playground/base/nepomuk-system-tra
>>>>> y ?jump=welcome> git: g...@git.kde.org:nepomuk-system-tray
>>>>
>>>> What is the status of this project? Has it been integrated into
>>>> kde-runtime?
>>>
>>> AFAIR trueg said that what is in kdereview is deprecated and should not be
>>> there.
>>
>> Deprecated is the wrong word here. IMHO it is not mature enough.
>> Otherwise I would have chosen it for inclusion into kde-runtime instead
>> of the "classical" nepomukcontroller.
>>
>> I will ping the author and ask him to move it back.
> 
> Nepomuk System Tray has now been moved from KDE Review to Playground/Base.

Thanks a lot. :)

Cheers,
Sebastian

Re: Requested Moratorium on hard to build dependency bumps for KDE 5

[Sebastian Trüg]

Just as a side-note on SDO: For me SDO is very close to the KDE
development process. If I had my way everyone running KDE master would
also use SDO master. But for some reason that would only be acceptable
if SDO were in KDE's git...

On 06/06/2011 06:53 PM, Thiago Macieira wrote:
> On Monday, 6 de June de 2011 17:48:41 Martin Gräßlin wrote:
>> Personal opinion: I think it is impossible to want to run the latest
>> software around an old stack.  The overall FOSS world is rolling release
>> with everything depending on everything. I cannot see why you want to
>> change that with a moratorium.
> 
> I agree on that, but I disagree on the age of the "old stack". For example, 
> I'm running the Mandriva rolling-release right now and I can't compile kdepim 
> and kdepimlibs because they haven't packaged yet shared-desktop-ontologies 
> 0.7. That was released less than one month ago. 
> 
> I'd say that hard dependencies need to be at least a couple of months old, 
> unless there's a very good reason for doing otherwise. And in that case, it 
> should be announced in advance so that distributions and users can prepare 
> themselves.
> 
>* Shared desktop ontologies (0.6.51 or higher)  
> 
>  Desktop ontologies
>  Ontologies necessary for the Nepomuk semantic desktop.
> 
> Download & date: 
> http://sourceforge.net/projects/oscaf/files/shared-desktop-ontologies/0.7/
> 

Re: Requested Moratorium on hard to build dependency bumps for KDE 5

[Sebastian Trüg]

On 06/06/2011 10:51 PM, Ben Cooksley wrote:
> On Tue, Jun 7, 2011 at 8:42 AM, Martin Gräßlin  wrote:
>> On Tuesday 07 June 2011 08:29:51 Ben Cooksley wrote:
>>> Next KWin. It currently depends upon Mesa 7.10. I have a local revert
>>> in a private local branch which reverts the dependency check code
>>> within KWin to continue to allow me to use compositing. Even though I
>>> have Mesa 7.8, I rarely experience KWin crashes - it has only crashed
>>> once in the past 2 months. I use an Intel Ironlake based graphics.
>>> This patch of mine works perfectly and does not cause any issues.
>> KWin does *not* depend on Mesa 7.10! KWin does not have any build 
>> dependencies on Mesa.
>> There is an optional build dependency on OpenGL and XComposite/XDamage. This 
>> all is optional!
>> If you use Mesa drivers there is a runtime requirement for at least Mesa 
>> 7.10, whose reasons
>> have been explained to you on plasma-devel.
>>
>> Given what you demand this is out of scope as it is not a build dependency. 
>> It is just that you
>> don't get the latest features when not having the correct runtime 
>> dependency. I might add that
>> using different drivers (NVIDIA or ATI blob as well as GLES/EGL Mesa 
>> drivers) do not have this
>> runtime requirement. It is also still possible to use KWin with XRender or 
>> without compositing at
>> all. Btw. patches to have an environment variable to overwrite all checks 
>> are welcome.
>>
>> Please also note that I will add a runtime requirement to Mesa 7.11 as I 
>> have here on my system
>> the start of the Wayland port which will be in 4.8 and requires Mesa 7.11.
> 
> Now that is absolutely overboard. OpenSUSE 11.4 isn't even 3 months
> old. And has Mesa 7.10. You are effectively classifying a distribution
> as unsuitable for trunk development. You are now depending on
> components which aren't even in released distributions!
> 
> (Note that having to live with a desktop without compositing isn't
> exactly what I would call usable for the long run)

IMHO it is out of the question to ask a developer to not implement a
great new feature just because the dependancies are too young.
In that case you should just stick with an older version of KDE itself.

Whom who wants the bleeding edge of KDE might also need the bleeding
edge of all the rest (in the worst case). Restricting ourselves will
lead to branching and a lot of wasted time on ifdefs and cmake checks.
This wasted time could otherwise be used to create great new features
and fix bugs.

Isn't this the way open-source software is supposed to work?
Collaborate, depend on the work of others?

Restricting ourselves to old versions (and as a developer anything
released is old for me) means to restrict the power we have and
undermines our very development model.

Cheers,
Sebastian

>>
>> Cheers
>> Martin
> 
> Regards,
> Ben
> 

Re: Requested Moratorium on hard to build dependency bumps for KDE 5

[Sebastian Trüg]

On 06/07/2011 01:41 PM, Thiago Macieira wrote:
> On Tuesday, 7 de June de 2011 10:14:43 Alexander Neundorf wrote:
>> On Tuesday, June 07, 2011 08:21:02 AM Sebastian Trüg wrote:
>>> Just as a side-note on SDO: For me SDO is very close to the KDE
>>> development process. If I had my way everyone running KDE master would
>>> also use SDO master. But for some reason that would only be acceptable
>>> if SDO were in KDE's git...
>>
>> It could be integrated into a "virtual" kdesupport, independent from where
>> it is hosted.
>> doesn't kdesrc-build actually do this ?
> 
> The part "shared-desktop" of the name seems to imply that it's not that close 
> to the KDE development process. If they are so close to the KDE development 
> process, why aren't they called "kde ontologies" instead?

SDO is intended to be shared between desktop frameworks and was actually
started as a shared project between KDE and Ghome. Sadly Tracker uses
their own fork of it and does not contribute the changes back (although
they have claimed to be planning to do it for a long time).
Renaming it would be a IMHO bad move now.
It being close to the KDE development process simply stems from the fact
that I maintain it and add features when I need them for KDE.
So the reasons are simply of a practical nature.

Cheers,
Sebastian

> Otherwise, it looks like people from the other camp who name their 
> technologies under generic names like Notifications or libwebkit and pretend 
> that they are the official solution for everyone.
> 

Nepomuk code moved to nepomuk-core

[Sebastian Trüg]

With the currently ongoing split of kdelibs and kde-runtime according to
KDE 5.0 frameworks Nepomuk has already partly been reorganized:

kdelibs/nepomuk and most parts of kde-runtime/nepomuk have been moved
into the new repository "nepomuk-core". kdelibs master has already been
frozen for some time. kde-runtime/nepomuk master is now effectively
frozen as development has moved to the new nepomuk-core repository.

Shortly new repositories as outlined in [1] will be created to contain
the rest of kde-runtime/nepomuk.

Cheers,
Sebastian

[1] http://community.kde.org/Projects/Nepomuk/Irc_meeting_nepomuk_frameworks

Re: [Nepomuk] Nepomuk code moved to nepomuk-core

[Sebastian Trüg]

On 09/15/2011 05:54 PM, Vishesh Handa wrote:
> Hey Sebastian
> 
> On Thu, Sep 15, 2011 at 8:47 PM, Sebastian Trüg  <mailto:tr...@kde.org>> wrote:
> 
> With the currently ongoing split of kdelibs and kde-runtime according to
> KDE 5.0 frameworks Nepomuk has already partly been reorganized:
> 
> kdelibs/nepomuk and most parts of kde-runtime/nepomuk have been moved
> into the new repository "nepomuk-core". kdelibs master has already been
> frozen for some time. kde-runtime/nepomuk master is now effectively
> frozen as development has moved to the new nepomuk-core repository.
> 
> 
> Do you think we could get the system admin to actually freeze
> kde-runtime/nepomuk so that all commits to it fail?

no idea. have to ask...

> And what is the policy for bug fixes? The commit goes to both
> kde-runtime/KDE/4.7 and nepomuk-core? If so, how do I do that? Cherry
> picking won't really work over here.

true. This will have to be done manually I guess.

Cheers,
Sebastian

Re: [Nepomuk] Nepomuk code moved to nepomuk-core

[Sebastian Trüg]

On 09/16/2011 11:46 AM, Albert Astals Cid wrote:
> A Dijous, 15 de setembre de 2011, Sebastian Trüg vàreu escriure:
>> With the currently ongoing split of kdelibs and kde-runtime according to
>> KDE 5.0 frameworks Nepomuk has already partly been reorganized:
>>
>> kdelibs/nepomuk and most parts of kde-runtime/nepomuk have been moved
>> into the new repository "nepomuk-core". kdelibs master has already been
>> frozen for some time. kde-runtime/nepomuk master is now effectively
>> frozen as development has moved to the new nepomuk-core repository.
>>
>> Shortly new repositories as outlined in [1] will be created to contain
>> the rest of kde-runtime/nepomuk.
> 
> This is suboptimal regarding translations since now we have 2 different 
> repositories that want to create a translation template with the same name. 
> Please comment out or remove the Messages.sh file from kde-runtime/nepomuk

damn, I always forget the translations. Very sorry about that.

Now what is the solution. To be honest I am very confused about the 4.8
release. kdelibs master is frozen. kde-runtime master apparently should
be frozen but is not. There will be no changed in kdelibs for 4.8 but
Nepomuk needs them (well, we could do them as bugfixes in 4.7 also).
Then what about kde-runtime master? Should we continue to work in there
until 4.8? If so, I would disable translations on nepomuk-core and only
enable them for 5.0.

Someone please advise as I am confused...

Cheers,
Sebastian

Re: [Nepomuk] Nepomuk code moved to nepomuk-core

[Sebastian Trüg]

On 09/17/2011 04:30 PM, Albert Astals Cid wrote:
> A Dissabte, 17 de setembre de 2011, Sebastian Trüg vàreu escriure:
>> On 09/16/2011 11:46 AM, Albert Astals Cid wrote:
>>> A Dijous, 15 de setembre de 2011, Sebastian Trüg vàreu escriure:
>>>> With the currently ongoing split of kdelibs and kde-runtime according
>>>> to
>>>> KDE 5.0 frameworks Nepomuk has already partly been reorganized:
>>>>
>>>> kdelibs/nepomuk and most parts of kde-runtime/nepomuk have been moved
>>>> into the new repository "nepomuk-core". kdelibs master has already
>>>> been
>>>> frozen for some time. kde-runtime/nepomuk master is now effectively
>>>> frozen as development has moved to the new nepomuk-core repository.
>>>>
>>>> Shortly new repositories as outlined in [1] will be created to contain
>>>> the rest of kde-runtime/nepomuk.
>>>
>>> This is suboptimal regarding translations since now we have 2 different
>>> repositories that want to create a translation template with the same
>>> name. Please comment out or remove the Messages.sh file from
>>> kde-runtime/nepomuk
>> damn, I always forget the translations. Very sorry about that.
>>
>> Now what is the solution. To be honest I am very confused about the 4.8
>> release. kdelibs master is frozen. kde-runtime master apparently should
>> be frozen but is not. 
> 
> There is no reason kde-runtime master should be frozen. kde-runtime master 
> will be part of the 4.8 release and has to compile against kdelibs 4.7
> 
>> There will be no changed in kdelibs for 4.8 but
>> Nepomuk needs them (well, we could do them as bugfixes in 4.7 also).
> 
> Not sure I understand the sentence so won't answer.
> 
>> Then what about kde-runtime master? Should we continue to work in there
>> until 4.8? If so, I would disable translations on nepomuk-core and only
>> enable them for 5.0.
> 
> If all those nepomuk-* repositories depend on frameworks, they can only be 
> released with 5.0, so yes, we should disable translations there.
> If all those nepomuk-* repositories do not depend on frameworks and will be 
> released with 4.8 (you shall inform the release team about it since there is 
> yet another tarball to release) then you need to clean kde-runtime because 
> otherwise we will be shipping duplicate code.

since I really do not want to maintain two branches I propose removing
nepomuk from kde-runtime master completely.
However, since nepomuk-core also contains all the nepomuk libs which are
now in kdelibs 4.7 we need to act here, too.
I propose that we move to include path nepomuk2. The main library is
already called nepomukcore. I am not sure about that yet. So maybe it
could be renamed to libnepomuk2 also.
That way we would have the libnepomuk from 4.7 and the new stuff from
libnepomuk2 and the only thing we need to ensure is that the 4.7 libs
still work with the services from nepomuk-core. Applications are then
advised to already depend on nepomuk-core instead of kdelibs.

Opinions?

Cheers,
Sebastian

Re: [Nepomuk] Nepomuk code moved to nepomuk-core

[Sebastian Trüg]

On 09/19/2011 11:07 AM, Albert Astals Cid wrote:
> A Dissabte, 17 de setembre de 2011, Sebastian Trüg vàreu escriure:
>> On 09/17/2011 04:30 PM, Albert Astals Cid wrote:
>>> A Dissabte, 17 de setembre de 2011, Sebastian Trüg vàreu escriure:
>>>> On 09/16/2011 11:46 AM, Albert Astals Cid wrote:
>>>>> A Dijous, 15 de setembre de 2011, Sebastian Trüg vàreu escriure:
>>>>>> With the currently ongoing split of kdelibs and kde-runtime
>>>>>> according
>>>>>> to
>>>>>> KDE 5.0 frameworks Nepomuk has already partly been reorganized:
>>>>>>
>>>>>> kdelibs/nepomuk and most parts of kde-runtime/nepomuk have been
>>>>>> moved
>>>>>> into the new repository "nepomuk-core". kdelibs master has already
>>>>>> been
>>>>>> frozen for some time. kde-runtime/nepomuk master is now
>>>>>> effectively
>>>>>> frozen as development has moved to the new nepomuk-core
>>>>>> repository.
>>>>>>
>>>>>> Shortly new repositories as outlined in [1] will be created to
>>>>>> contain
>>>>>> the rest of kde-runtime/nepomuk.
>>>>>
>>>>> This is suboptimal regarding translations since now we have 2
>>>>> different
>>>>> repositories that want to create a translation template with the
>>>>> same
>>>>> name. Please comment out or remove the Messages.sh file from
>>>>> kde-runtime/nepomuk
>>>>
>>>> damn, I always forget the translations. Very sorry about that.
>>>>
>>>> Now what is the solution. To be honest I am very confused about the
>>>> 4.8
>>>> release. kdelibs master is frozen. kde-runtime master apparently
>>>> should
>>>> be frozen but is not.
>>>
>>> There is no reason kde-runtime master should be frozen. kde-runtime
>>> master will be part of the 4.8 release and has to compile against
>>> kdelibs 4.7> 
>>>> There will be no changed in kdelibs for 4.8 but
>>>> Nepomuk needs them (well, we could do them as bugfixes in 4.7 also).
>>>
>>> Not sure I understand the sentence so won't answer.
>>>
>>>> Then what about kde-runtime master? Should we continue to work in
>>>> there
>>>> until 4.8? If so, I would disable translations on nepomuk-core and
>>>> only
>>>> enable them for 5.0.
>>>
>>> If all those nepomuk-* repositories depend on frameworks, they can only
>>> be released with 5.0, so yes, we should disable translations there. If
>>> all those nepomuk-* repositories do not depend on frameworks and will
>>> be released with 4.8 (you shall inform the release team about it since
>>> there is yet another tarball to release) then you need to clean
>>> kde-runtime because otherwise we will be shipping duplicate code.
>>
>> since I really do not want to maintain two branches I propose removing
>> nepomuk from kde-runtime master completely.
>> However, since nepomuk-core also contains all the nepomuk libs which are
>> now in kdelibs 4.7 we need to act here, too.
>> I propose that we move to include path nepomuk2. The main library is
>> already called nepomukcore. I am not sure about that yet. So maybe it
>> could be renamed to libnepomuk2 also.
>> That way we would have the libnepomuk from 4.7 and the new stuff from
>> libnepomuk2 and the only thing we need to ensure is that the 4.7 libs
>> still work with the services from nepomuk-core. Applications are then
>> advised to already depend on nepomuk-core instead of kdelibs.
>>
>> Opinions?
> 
> Not sure I understand the mail, but to me it seems you are proposing breaking 
> binary compatibility between 4.7 and 4.8 releases and killing of code and 
> renaming of libraries.
> 
> If that is what you propose, it is a big no go for me. 

no, I am proposing to remove runtime components from kde-runtime and
using those from nepomuk-core instead. kdelibs will not be touched (frozen).
As discussed on IRC we could also make the libs in nepomuk-core private
for now (until frameworks) and only treat it as a split from kde-runtime.

Cheers,
Sebastian

Re: [Nepomuk] Nepomuk code moved to nepomuk-core

[Sebastian Trüg]

On 09/19/2011 12:59 PM, Vishesh Handa wrote:
> Just so that I'm clear -
> 
> * kde-runtime/nepomuk will be deleted

yes

> * kdelibs/nepomuk will not be touched and has the following libraries -
> libnepomuk, libnepomukquery, and libnepomukutils

yes

> * All new changes will happen in nepomuk-core

yes

> * nepomuk-core will now contain libnepomuk2, libnepomukquery2, and
> libnepomukutils2?

no, only libnepomuk2 - this is currently named libnepomukcore.

> * The services and other runtime components in nepomuk-core (
> ontologies, server .. ), will continue using libnepomuk? If so what is
> the point of creating libnepomuk2?

no, services all depend on the new lib.

> * When kde-runtime 4.8 is shipped - How will the nepomuk runtime
> components be shipped?

as an additional package.

> On Sat, Sep 17, 2011 at 9:51 PM, Sebastian Trüg  <mailto:tr...@kde.org>> wrote:
> 
> On 09/17/2011 04:30 PM, Albert Astals Cid wrote:
> > A Dissabte, 17 de setembre de 2011, Sebastian Trüg vàreu escriure:
> >> On 09/16/2011 11:46 AM, Albert Astals Cid wrote:
> >>> A Dijous, 15 de setembre de 2011, Sebastian Trüg vàreu escriure:
> >>>> With the currently ongoing split of kdelibs and kde-runtime
> according
> >>>> to
> >>>> KDE 5.0 frameworks Nepomuk has already partly been reorganized:
> >>>>
> >>>> kdelibs/nepomuk and most parts of kde-runtime/nepomuk have been
> moved
> >>>> into the new repository "nepomuk-core". kdelibs master has already
> >>>> been
> >>>> frozen for some time. kde-runtime/nepomuk master is now effectively
> >>>> frozen as development has moved to the new nepomuk-core repository.
> >>>>
> >>>> Shortly new repositories as outlined in [1] will be created to
> contain
> >>>> the rest of kde-runtime/nepomuk.
> >>>
> >>> This is suboptimal regarding translations since now we have 2
> different
> >>> repositories that want to create a translation template with the
> same
> >>> name. Please comment out or remove the Messages.sh file from
> >>> kde-runtime/nepomuk
> >> damn, I always forget the translations. Very sorry about that.
> >>
> >> Now what is the solution. To be honest I am very confused about
> the 4.8
> >> release. kdelibs master is frozen. kde-runtime master apparently
> should
> >> be frozen but is not.
> >
> > There is no reason kde-runtime master should be frozen.
> kde-runtime master
> > will be part of the 4.8 release and has to compile against kdelibs 4.7
> >
> >> There will be no changed in kdelibs for 4.8 but
> >> Nepomuk needs them (well, we could do them as bugfixes in 4.7 also).
> >
> > Not sure I understand the sentence so won't answer.
> >
> >> Then what about kde-runtime master? Should we continue to work in
> there
> >> until 4.8? If so, I would disable translations on nepomuk-core
> and only
> >> enable them for 5.0.
> >
> > If all those nepomuk-* repositories depend on frameworks, they can
> only be
> > released with 5.0, so yes, we should disable translations there.
> > If all those nepomuk-* repositories do not depend on frameworks
> and will be
> > released with 4.8 (you shall inform the release team about it
> since there is
> > yet another tarball to release) then you need to clean kde-runtime
> because
> > otherwise we will be shipping duplicate code.
> 
> since I really do not want to maintain two branches I propose removing
> nepomuk from kde-runtime master completely.
> However, since nepomuk-core also contains all the nepomuk libs which are
> now in kdelibs 4.7 we need to act here, too.
> I propose that we move to include path nepomuk2. The main library is
> already called nepomukcore. I am not sure about that yet. So maybe it
> could be renamed to libnepomuk2 also.
> That way we would have the libnepomuk from 4.7 and the new stuff from
> libnepomuk2 and the only thing we need to ensure is that the 4.7 libs
> still work with the services from nepomuk-core. Applications are then
> advised to already depend on nepomuk-core instead of kdelibs.
> 
> Opinions?
> 
> Cheers,
> Sebastian
> 
> 
> 
> 
> -- 
> Vishesh Handa

Do NOT use Soprano 2.7.1 or 2.6.1

[Sebastian Trüg]

The "fix" I introduced in 2.6.1 and 2.7.1 actually made things worse for
the DBus comunication as in: "Does not work at all anymore".
I am trying to find a better solution. Until that time please stick to
2.7.0 and 2.6.0.

Sorry for the inconvenience.

Cheers,
Sebastian

Who relies on Soprano::Model::statement[s]Added|Removed signals?

[Sebastian Trüg]

Hi lists,

with frameworks in the building and Nepomuk probably going that
direction already for 4.8 I would like to clean up a bit. One of these
cleanup tasks targets the Soprano::Model statement signals. So far these
were the only way to get informed about changes in Nepomuk - with a very
bad impact on performance and bad usability.
With 4.7 we already introduced a preliminary version of the
Nepomuk::ResourceWatcher[1] which is now in charge of informing clients
about changes.
I would like to anyone using the "old" API to change to the new
ResourceWatcher as soon as possible because I would like to disable the
old signals soon. They simply entail to many problems and clutter the API.

Cheers,
Sebastian

[1] Funnily enough only the docs for the copy in Akonadi is online at
the moment:
http://api.kde.org/4.x-api/kdepim-runtime-apidocs/agents/html/classNepomuk_1_1ResourceWatcher.html

Re: Who relies on Soprano::Model::statement[s]Added|Removed signals?

[Sebastian Trüg]

On 09/30/2011 01:56 PM, Alex Merry wrote:
> On 30/09/11 12:36, Sebastian Trüg wrote:
>> I would like to anyone using the "old" API to change to the new
>> ResourceWatcher as soon as possible because I would like to disable the
>> old signals soon. They simply entail to many problems and clutter the
>> API.
> 
> You might want to contact developers using the signals directly.
> lxr.kde.org suggests: Digikam, Amarok, kdepim, telepathy, ginkgo and the
> nepomuktags Plasma dataengine.

Good idea. I did not see Digikam and Amarok in lxr... maybe I did not
look properly. :)

> Everything else looks like your domain (although the nepomuk backupsync
> service might not be).
> 
> Alex
> 

Re: Who relies on Soprano::Model::statement[s]Added|Removed signals?

[Sebastian Trüg]

of course this is for the frameworks thingi.

On 09/30/2011 07:09 PM, Sune Vuorela wrote:
> On 2011-09-30, Albert Astals Cid  wrote:
>> A Divendres, 30 de setembre de 2011, Sebastian Trüg vàreu escriure:
>>> Hi lists,
>>>
>>> with frameworks in the building and Nepomuk probably going that
>>> direction already for 4.8 I would like to clean up a bit. One of these
>>> cleanup tasks targets the Soprano::Model statement signals. So far these
>>> were the only way to get informed about changes in Nepomuk - with a very
>>> bad impact on performance and bad usability.
>>> With 4.7 we already introduced a preliminary version of the
>>> Nepomuk::ResourceWatcher[1] which is now in charge of informing clients
>>> about changes.
>>> I would like to anyone using the "old" API to change to the new
>>> ResourceWatcher as soon as possible because I would like to disable the
>>> old signals soon. They simply entail to many problems and clutter the API.
>>
>> Removing signals of what seems to be an existing public class/daemon is a 
>> very 
>> bad idea and you should wait until 5.0.  
> 
> Full ack.
> 
> /Sune
> 
> 

Re: Qt 4.8 QUrl.toLocalFile behavior change, impacts to KUrl (and friends)

[Sebastian Trüg]

On 10/27/2011 11:35 PM, Thiago Macieira wrote:
> On Thursday, 27 de October de 2011 23:17:49 Milian Wolff wrote:
>> On Thursday 27 October 2011 21:11:11 Thiago Macieira wrote:
>>> On Thursday, 27 de October de 2011 13:32:51 Rex Dieter wrote:
 See also,
 http://bugs.kde.org/285028
 ( and https://bugreports.qt.nokia.com/browse/QTBUG-22382 )

 In Qt 4.8, QUrl.toLocalFile now seems, by design, to return NULL for
 urls
 lacking any scheme.  Discovered this the hard way figuring out why all
 my
 audio knotifications were quiet.  Since audio event sources are simple
 filenames, e.g. KDE-K3B-Finish-Success.ogg, and
 QString soundFile = soundFileURL.toLocalFile();
 no longer works.

 Any suggestions or advice on how best to deal with this?
>>>
>>> As we discussed on IRC, any string source must be properly labelled
>>> whether
>>> they are a URL or they are a local file. They cannot be both.
>>
>> is there at least a qWarning emitted in such a case, so we can find these
>> problems with QT_FATAL_WARNINGS=1 ?
> 
> No, but there's something better:
> 
> #define QURL_NO_CAST_FROM_QSTRING
> 
> Your code will not compile when you're auto-casting. You'll need to select 
> what to do:
> 
>   QUrl::fromEncoded() - if it's a URL, with the "file" scheme
>   QUrl::fromLocalFile() - if it's a file name
> 
> This option remains in Qt 5, but there there's going to be a new method to 
> convert from QString to QUrl without passing through QByteArray.
> 
> This is extremely important to get right because a filename and a URL are NOT 
> the same. Certain characters in the string are interpreted differently 
> depending on what the string is: %, # and ? in particular.
> 
> So, to be honest, the bug *already* *existed* in your code if you're finding 
> these problems now. I just made it blatantly clear, and it's been there for a 
> year for people to see.
> 
> I'm also calling right now KUrl's fromPathOrUrl a fatally flawed design.

Be that as it may but the fact remains that KDE potentially does not
work with Qt 4.8. Is that really a risk worth taking? I am all for fixed
semantics in the methods but this seems like a problematic case.

Cheers
Sebastian

Re: [Nepomuk] The Nepomuk Situation

[Sebastian Trüg]

nepomuk-core depends on kdelibs. So kdelibs cannot depend on
nepomuk-core. We would have to get rid of those dependencies in kdelibs.
But that should not be too hard.

On 05/03/2012 11:21 AM, Vishesh Handa wrote:
> I just noticed that this discussion is no longer cced to kcd.
> 
> On Thu, May 3, 2012 at 2:47 PM, Christian Mollekopf
> mailto:chrig...@fastmail.fm>> wrote:
> 
>  
>  
> On Thu, May 3, 2012, at 02:22 PM, Vishesh Handa wrote:
>>
>>
>> On Thu, May 3, 2012 at 3:09 AM, Christian Mollekopf
>> mailto:chrig...@fastmail.fm>> wrote:
>>
>> > On Thursday 03 May 2012 00.32:37 Vishesh Handa wrote:
>> >
>> > Hey everyone!
>> >
>> Hey Vishesh,
>>
>>
>> Hey Christian
>>
>>
>> Glad your tackling this, it's indeed a rather painful situation.
>>
>> >
>> > So, we need a solution.
>> >
>> > The first solution -
>> > * Remove nepomuk from kdelibs and kde-runtime
>> > * Make nepomuk-core a compile time dependency for kdelibs
>> > * Including the missing gui code into nepomuk-core
>> >
>> > The second solution is -
>> > * nepomuk-core installs the headers in nepomuk2
>> > * the library already has a different name, so there are no
>> clashes over
>> there
>> > * kde-runtime/nepomuk is removed
>> > * nepomuk-core is added as a dependency of kde-runtime
>> >
>> > The problem with the second solution is that all
>> applications using Nepomuk
>> will also need to depend on nepomuk-core. So far the list
>> includes - Dolphin,
>> KDE-pim and Telepathy (kinda)
>> >
>>  
>> I would suggest to create two repostories. One "nepomuk-core"
>> containing the
>> dependencies of kdelibs (respectively nepomuks core
>> libraries), and another
>> one "nepomuk2" containing the dms and possibly other stuff
>> which depends on
>> kdelibs (and in the future the required parts of kf5). That
>> would give you
>> clean dependencies without copies of code, which I think would
>> be rather ugly
>> (assuming that the "missing gui code" would be a copy of
>> kdelibs code).
>>
>>
>> I do not think this would be possible. Cause kdelibs requires
>> parts of the new APIS (Datamanagent APIs), for now we have just
>> copied some of the headers, and cpp files and are duplicating stuff.
>>
>> I would really want to avoid fragmenting nepomuk even more. Having
>> 2 repositories with related code is something that we want to avoid.
>>  
>>  
>> Indeed, if the code is related you don't want to split it. I
>> suppose I don't really understand your two suggestions then.
>> I would just depend on nepomuk-core from kdelibs/kde-runtime (if
>> necessary) and every application that uses nepomuk (if you're
>> using it, depend on it).
>> I don't think you should try to keep applications from depending
>> on stuff they need, because that also gives the option not to
>> depend on it.
>>  
>> PS: I can't seem to reasonably answer to your html mails, neither
>> in kmail nor in the webinterface.
>>  
>> Cheers,
>> Christian
>>  
>>  
>>
>>
>> I don't see any problem with applications having to depend on
>> nepomuk
>> libraries when they're using it. In contrary I would welcome
>> repositories
>> which keep dependencies low, as that opens new possibilities,
>> such as using
>> the same libraries in a server environment where you don't
>> want to pull in
>> everything including X11.
>>
>> Cheers,
>> Christian
>>
>> > What do you guys think?
>> >
>> > [1] https://projects.kde.org/projects/kde/kdelibs/nepomuk-core
>> > [2]
>> http://trueg.wordpress.com/2011/06/08/nepomuk-2-0-and-the-data-
>> management-service/
>> 
>> 
>> >
>> > --
>> > Vishesh Handa
>> >
>> >
>> >
>> >
>> >
>> ___
>> Nepomuk mailing list
>> nepo...@kde.org 
>> https://mail.kde.org/mailman/listinfo/nepomuk
>>
>>
>>
>>
>> --
>> Vishesh Handa
>>  
>  
> 
> 
> 
> 
> -- 
> Vishesh Handa
> 
> 
> 
> ___
> Nepomuk mailing list
> nepo...@kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk

Re: The Nepomuk Situation

[Sebastian Trüg]

On 05/07/2012 12:09 PM, Vishesh Handa wrote:
> 
> 
> On Mon, May 7, 2012 at 3:12 PM, David Faure  > wrote:
> 
> On Monday 07 May 2012 13:06:15 Vishesh Handa wrote:
> > On Mon, May 7, 2012 at 12:44 PM, Sune Vuorela  > wrote:
> > > On 2012-05-07, Vishesh Handa  > wrote:
> > > > Right.
> > > >
> > > > We could maintain BC and SC by not touching the kdelibs
> nepomuk, and
> > > > just
> > > > making nepomuk-core a dependency of kdelibs. But that would
> result in
> > >
> > > both
> > >
> > > > nepomuk-core and kdelibs installing the same headers.
> > >
> > > what happens if both libraries are loaded into the same process?
> >
> > I'm not sure. I'm assuming that it would result in some sort of linker
> > errors.
> 
> Not if libnepomukcore is brought in by the application, and
> libnepomuk is
> brought in by a dlopened plugin. In such a case, you get no clear
> error, you
> get random crashes.
> 
> The solution is usually to namespace the symbols (classes, standalone
> functions etc.) so that they don't conflict.
> Of course that makes the porting effort a bit higher, but it's the
> only way to
> have both things side by side during the transition period.
> 
> 
> Oh.
> 
> So, we're down to 3 options -
> 
> *1.* nepomuk-core become a dependency of kdelibs. Kdelibs is not touched.
> *Problem:* Overlapping headers and possible mysterious crashes if both
> libraries are loaded.
> 
> *2.* nepomuk-core installs headers under nepomuk2. It's released
> independently.
> *Problem:* Mysterious crashes if both libraries are loaded.
> 
> *3.* nepomuk-core installs headers under nepomuk2 and the namespace is
> changed to nepomuk2.
> *Problem:* A lot more work :(

Well, I suppose we could make this work with some sed magic. :P
I would vote for option 3 which could then be reverted (or not) for kde5.

> In all cases, kde-runtime/nepomuk will be removed. Binary and Source
> compatibility are not affected.
>  
> 
> 
> See knewstuff2 (namespace KNS) vs knewstuff3 (namespace KNS3) for
> instance ;)
> 
> --
> David Faure, fa...@kde.org ,
> http://www.davidfaure.fr
> Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
> 
> 
> 
> 
> -- 
> Vishesh Handa
> 

Re: The Nepomuk Situation

[Sebastian Trüg]

On 05/07/2012 02:35 PM, Vishesh Handa wrote:
> 
> 
> On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg  <mailto:tr...@kde.org>> wrote:
> 
>  
> On 05/07/2012 12:09 PM, Vishesh Handa wrote:
> 
> > So, we're down to 3 options -
> >
> > *1.* nepomuk-core become a dependency of kdelibs. Kdelibs is not
> touched.
> > *Problem:* Overlapping headers and possible mysterious crashes if both
> > libraries are loaded.
> >
> > *2.* nepomuk-core installs headers under nepomuk2. It's released
> > independently.
> > *Problem:* Mysterious crashes if both libraries are loaded.
> >
> > *3.* nepomuk-core installs headers under nepomuk2 and the namespace is
> > changed to nepomuk2.
> > *Problem:* A lot more work :(
> 
> Well, I suppose we could make this work with some sed magic. :P
> I would vote for option 3 which could then be reverted (or not) for
> kde5.
> 
> 
> I would prefer option 2.
> 
> The mysterious crashes would only happen if an application's plugin
> links to the incorrect libraries.
> 
> Is that a possibility for us?

I already experienced that. Took me a while to find the reason.

> We have about 8-10 known nepomukservices, which are basically plugins
> but *they exist in their own process*, so each has their own libraries.
> 
> -- 
> Vishesh Handa
> 

Re: The Nepomuk Situation

[Sebastian Trüg]

On 05/07/2012 03:47 PM, ivan.cu...@gmail.com wrote:
> Maybe there could be something like qt has - BEGIN_NEPOMUK_NAMESPACE... So 
> that if the same needs to be done in the future, we could just change the 
> macro value.

That would be much more work since each cpp file has the namespaces in
the method definitions.

> I don't know, thinking that Nepomuk2 namespace is looking rather ugly :)

it is indeed.

> The dirtiest solution library-wise would be to have everything in 
> NepomukCore::Nepomuk::Something so that the only change in the current code 
> of nepomuk users would be a using namespace NepomukCore;
>
> Sorry for being a bit vague, I'm writing from my phone.
> 
> Cheerio,
> IvanOn 7.5.12. 14.49 Vishesh Handa wrote:
> 
> 
> 
> On Mon, May 7, 2012 at 6:13 PM, Sebastian Trüg  wrote:
> 
> On 05/07/2012 02:35 PM, Vishesh Handa wrote:
>>
>>
>> On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg  
>> <mailto:tr...@kde.org>> wrote:
>>
>>
>> On 05/07/2012 12:09 PM, Vishesh Handa wrote:
>>
>> > So, we're down to 3 options -
>> >
>> > *1.* nepomuk-core become a dependency of kdelibs. Kdelibs is not
>> touched.
>> > *Problem:* Overlapping headers and possible mysterious crashes if both
>> > libraries are loaded.
>> >
>> > *2.* nepomuk-core installs headers under nepomuk2. It's released
>> > independently.
>> > *Problem:* Mysterious crashes if both libraries are loaded.
>> >
>> > *3.* nepomuk-core installs headers under nepomuk2 and the namespace is
>> > changed to nepomuk2.
>> > *Problem:* A lot more work :(
>>
>> Well, I suppose we could make this work with some sed magic. :P
>> I would vote for option 3 which could then be reverted (or not) for
>> kde5.
>>
>>
>> I would prefer option 2.
>>
>> The mysterious crashes would only happen if an application's plugin
>> links to the incorrect libraries.
>>
>> Is that a possibility for us?
> 
> 
> I already experienced that. Took me a while to find the reason.
> 
> 
> Alright.
> 
> I would like the Nepomuk2 namespace and include directories be removed for 
> the frameworks, but I guess it is not a big deal if that doesn't happen.
> 
> 
>  
> Okay, everyone. This is the point where you chime in and say - "We're okay 
> with this" or you raise your objections. We would like to get this mess 
> sorted in time for the 4.9 release.
> 
> 
> 
> 

Re: [Nepomuk] The Nepomuk Situation

[Sebastian Trüg]

Just as a reminder: most of the issues were already discussed and
decided on:
http://community.kde.org/Projects/Nepomuk/Irc_meeting_nepomuk_frameworks

On 05/11/2012 09:35 AM, Vishesh Handa wrote:
> 
> On Fri, May 11, 2012 at 12:55 PM, Sebastian Trüg  <mailto:tr...@kde.org>> wrote:
> 
> Sounds great. However, it requires one more step:
> 
> Create the new repositories we decided on a while ago for the kcm, the
> kio slaves and such. This basically means to do "git filter-branch"[1]
> as I did for nepomuk-core.
> 
> 
> Have fun :) Btw, what do you want to call it? nepomuk-kde?
> 
> I think we should even include the stuff from kdelibs/nepomuk/utils/.
>  
> 
> 
> [1]
> 
> http://gbayer.com/development/moving-files-from-one-git-repository-to-another-preserving-history/
> 
> On 05/10/2012 09:32 PM, Vishesh Handa wrote:
> > Does anyone have any objections to the current plan?
> >
> > * Remove kde-runtime/nepomuk
> > * All nepomuk development happens in nepomuk-core
> > * nepomuk-core will install everything with a Nepomuk2 namespace
> > * Applications will have to explicitly depend on nepomuk-core if they
> > want to use the new APIs
> >
> > The old APIs will continue to work exactly the way they work right
> now.
> >
> > --
> > Vishesh Handa
> >
> >
> >
> > ___
> > Nepomuk mailing list
> > nepo...@kde.org <mailto:nepo...@kde.org>
> > https://mail.kde.org/mailman/listinfo/nepomuk
> ___
> Nepomuk mailing list
> nepo...@kde.org <mailto:nepo...@kde.org>
> https://mail.kde.org/mailman/listinfo/nepomuk
> 
> 
> 
> 
> -- 
> Vishesh Handa
> 

Re: [Nepomuk] The Nepomuk Situation

[Sebastian Trüg]

I now prepared the required repositories:

scratch/trueg/nepomuk-kde-kio
  contains the 3 Nepomuk kio slaves

scratch/trueg/nepomuk-kde-config
  contains the KCM and the controller systray app

The question is: where should we move them? Something like "KDE/Base"?
I suppose questions like these have already been discussed with respect
to KDE5?

Cheers,
Sebastian

On 05/07/2012 03:58 PM, Sebastian Trüg wrote:
> On 05/07/2012 03:47 PM, ivan.cu...@gmail.com wrote:
>> Maybe there could be something like qt has - BEGIN_NEPOMUK_NAMESPACE... So 
>> that if the same needs to be done in the future, we could just change the 
>> macro value.
> 
> That would be much more work since each cpp file has the namespaces in
> the method definitions.
> 
>> I don't know, thinking that Nepomuk2 namespace is looking rather ugly :)
> 
> it is indeed.
> 
>> The dirtiest solution library-wise would be to have everything in 
>> NepomukCore::Nepomuk::Something so that the only change in the current code 
>> of nepomuk users would be a using namespace NepomukCore;
>>
>> Sorry for being a bit vague, I'm writing from my phone.
>>
>> Cheerio,
>> IvanOn 7.5.12. 14.49 Vishesh Handa wrote:
>>
>>
>>
>> On Mon, May 7, 2012 at 6:13 PM, Sebastian Trüg  wrote:
>>
>> On 05/07/2012 02:35 PM, Vishesh Handa wrote:
>>>
>>>
>>> On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg >
>>> <mailto:tr...@kde.org>> wrote:
>>>
>>>
>>> On 05/07/2012 12:09 PM, Vishesh Handa wrote:
>>>
>>> > So, we're down to 3 options -
>>> >
>>> > *1.* nepomuk-core become a dependency of kdelibs. Kdelibs is not
>>> touched.
>>> > *Problem:* Overlapping headers and possible mysterious crashes if both
>>> > libraries are loaded.
>>> >
>>> > *2.* nepomuk-core installs headers under nepomuk2. It's released
>>> > independently.
>>> > *Problem:* Mysterious crashes if both libraries are loaded.
>>> >
>>> > *3.* nepomuk-core installs headers under nepomuk2 and the namespace is
>>> > changed to nepomuk2.
>>> > *Problem:* A lot more work :(
>>>
>>> Well, I suppose we could make this work with some sed magic. :P
>>> I would vote for option 3 which could then be reverted (or not) for
>>> kde5.
>>>
>>>
>>> I would prefer option 2.
>>>
>>> The mysterious crashes would only happen if an application's plugin
>>> links to the incorrect libraries.
>>>
>>> Is that a possibility for us?
>>
>>
>> I already experienced that. Took me a while to find the reason.
>>
>>
>> Alright.
>>
>> I would like the Nepomuk2 namespace and include directories be removed for 
>> the frameworks, but I guess it is not a big deal if that doesn't happen.
>>
>> 
>>  
>> Okay, everyone. This is the point where you chime in and say - "We're okay 
>> with this" or you raise your objections. We would like to get this mess 
>> sorted in time for the 4.9 release.
>>
>>
>>
>>
> ___
> Nepomuk mailing list
> nepo...@kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk

Re: [Nepomuk] The Nepomuk Situation

[Sebastian Trüg]

On 05/16/2012 08:23 PM, Vishesh Handa wrote:
> What about kdelibs/nepomuk/utils/* and the other ui stuff?
> 
> Or since those are just APIs they can wait.

I say let's postpone them, they are still in kdelibs.

The facets are quite weird and I am not sure about releasing them again.
The ui stuff - not sure.

> On Wed, May 16, 2012 at 11:49 PM, Sebastian Trüg  <mailto:tr...@kde.org>> wrote:
> 
> I now prepared the required repositories:
> 
> scratch/trueg/nepomuk-kde-kio
>  contains the 3 Nepomuk kio slaves
> 
> scratch/trueg/nepomuk-kde-config
>  contains the KCM and the controller systray app
> 
> The question is: where should we move them? Something like "KDE/Base"?
> I suppose questions like these have already been discussed with respect
> to KDE5?
> 
> Cheers,
> Sebastian
> 
> On 05/07/2012 03:58 PM, Sebastian Trüg wrote:
> > On 05/07/2012 03:47 PM, ivan.cu...@gmail.com
> <mailto:ivan.cu...@gmail.com> wrote:
> >> Maybe there could be something like qt has -
> BEGIN_NEPOMUK_NAMESPACE... So that if the same needs to be done in
> the future, we could just change the macro value.
> >
> > That would be much more work since each cpp file has the namespaces in
> > the method definitions.
> >
> >> I don't know, thinking that Nepomuk2 namespace is looking rather
> ugly :)
> >
> > it is indeed.
> >
> >> The dirtiest solution library-wise would be to have everything in
> NepomukCore::Nepomuk::Something so that the only change in the
> current code of nepomuk users would be a using namespace NepomukCore;
> >>
> >> Sorry for being a bit vague, I'm writing from my phone.
> >>
> >> Cheerio,
> >> IvanOn 7.5.12. 14.49 Vishesh Handa wrote:
> >>
> >>
> >>
> >> On Mon, May 7, 2012 at 6:13 PM, Sebastian Trüg  <mailto:tr...@kde.org>> wrote:
> >>
> >> On 05/07/2012 02:35 PM, Vishesh Handa wrote:
> >>>
> >>>
> >>> On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg  <mailto:tr...@kde.org>
> >>
> >>> <mailto:tr...@kde.org <mailto:tr...@kde.org>>> wrote:
> >>>
> >>>
> >>> On 05/07/2012 12:09 PM, Vishesh Handa wrote:
> >>>
> >>> > So, we're down to 3 options -
> >>> >
> >>> > *1.* nepomuk-core become a dependency of kdelibs. Kdelibs
> is not
> >>> touched.
> >>> > *Problem:* Overlapping headers and possible mysterious
> crashes if both
> >>> > libraries are loaded.
> >>> >
> >>> > *2.* nepomuk-core installs headers under nepomuk2. It's
> released
> >>> > independently.
> >>> > *Problem:* Mysterious crashes if both libraries are loaded.
> >>> >
> >>> > *3.* nepomuk-core installs headers under nepomuk2 and the
> namespace is
> >>> > changed to nepomuk2.
> >>> > *Problem:* A lot more work :(
> >>>
> >>> Well, I suppose we could make this work with some sed magic. :P
> >>> I would vote for option 3 which could then be reverted (or
> not) for
> >>> kde5.
> >>>
> >>>
> >>> I would prefer option 2.
> >>>
> >>> The mysterious crashes would only happen if an application's plugin
> >>> links to the incorrect libraries.
> >>>
> >>> Is that a possibility for us?
> >>
> >>
> >> I already experienced that. Took me a while to find the reason.
> >>
> >>
> >> Alright.
> >>
> >> I would like the Nepomuk2 namespace and include directories be
> removed for the frameworks, but I guess it is not a big deal if that
> doesn't happen.
> >>
> >> 
> >>
> >> Okay, everyone. This is the point where you chime in and say -
> "We're okay with this" or you raise your objections. We would like
> to get this mess sorted in time for the 4.9 release.
> >>
> >>
> >>
> >>
> > ___
> > Nepomuk mailing list
> > nepo...@kde.org <mailto:nepo...@kde.org>
> > https://mail.kde.org/mailman/listinfo/nepomuk
> ___
> Nepomuk mailing list
> nepo...@kde.org <mailto:nepo...@kde.org>
> https://mail.kde.org/mailman/listinfo/nepomuk
> 
> 
> 
> 
> -- 
> Vishesh Handa
> 

Re: [Nepomuk] The Nepomuk Situation

[Sebastian Trüg]

On 05/16/2012 08:37 PM, Vishesh Handa wrote:
> 
> 
> On Thu, May 17, 2012 at 12:02 AM, Sebastian Trüg  <mailto:tr...@kde.org>> wrote:
> 
> On 05/16/2012 08:23 PM, Vishesh Handa wrote:
> > What about kdelibs/nepomuk/utils/* and the other ui stuff?
> >
> > Or since those are just APIs they can wait.
> 
> I say let's postpone them, they are still in kdelibs. 
> 
> 
> The facets are quite weird and I am not sure about releasing them again.
> The ui stuff - not sure.
> 
> 
> We have all the runtime stuff and nepomuk-core, that's all that matters
> right now.
> 
> So, we just need to do -
> 
> 1. use the Nepomuk2 namespace, and nepomuk2 include directory
> 2. Remove kde-runtime/nepomuk
> 
> Regarding 1, I like Ivan's suggestion about BEGIN_NEPOMUK_NAMESPACE. If
> you want I can take care of it.

Ah, damn, I forgot about that. I am in the process of replacing
everything with "Nepomuk2". I want to put it all into easily revertable
commits.
The problem with Ivan's idea is that it does not cover the includes -
although I suppose we could handle that with a cmake definition...

> 
> > On Wed, May 16, 2012 at 11:49 PM, Sebastian Trüg  <mailto:tr...@kde.org>
> > <mailto:tr...@kde.org <mailto:tr...@kde.org>>> wrote:
> >
> > I now prepared the required repositories:
> >
> > scratch/trueg/nepomuk-kde-kio
> >  contains the 3 Nepomuk kio slaves
> >
> > scratch/trueg/nepomuk-kde-config
> >  contains the KCM and the controller systray app
> >
> > The question is: where should we move them? Something like
> "KDE/Base"?
> > I suppose questions like these have already been discussed
> with respect
> > to KDE5?
> >
> > Cheers,
> > Sebastian
> >
> > On 05/07/2012 03:58 PM, Sebastian Trüg wrote:
> > > On 05/07/2012 03:47 PM, ivan.cu...@gmail.com
> <mailto:ivan.cu...@gmail.com>
> > <mailto:ivan.cu...@gmail.com <mailto:ivan.cu...@gmail.com>> wrote:
> > >> Maybe there could be something like qt has -
> > BEGIN_NEPOMUK_NAMESPACE... So that if the same needs to be done in
> > the future, we could just change the macro value.
> > >
> > > That would be much more work since each cpp file has the
> namespaces in
> > > the method definitions.
> > >
> > >> I don't know, thinking that Nepomuk2 namespace is looking
> rather
> > ugly :)
> > >
> > > it is indeed.
> > >
> > >> The dirtiest solution library-wise would be to have
> everything in
> > NepomukCore::Nepomuk::Something so that the only change in the
> > current code of nepomuk users would be a using namespace
> NepomukCore;
> > >>
> > >> Sorry for being a bit vague, I'm writing from my phone.
> > >>
> > >> Cheerio,
> > >> IvanOn 7.5.12. 14.49 Vishesh Handa wrote:
> > >>
> > >>
> > >>
> > >> On Mon, May 7, 2012 at 6:13 PM, Sebastian Trüg
> mailto:tr...@kde.org>
> > <mailto:tr...@kde.org <mailto:tr...@kde.org>>> wrote:
> > >>
> > >> On 05/07/2012 02:35 PM, Vishesh Handa wrote:
> > >>>
> > >>>
> > >>> On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg
> mailto:tr...@kde.org>
> > <mailto:tr...@kde.org <mailto:tr...@kde.org>>
> > >>
> > >>> <mailto:tr...@kde.org <mailto:tr...@kde.org>
> <mailto:tr...@kde.org <mailto:tr...@kde.org>>>> wrote:
> > >>>
> > >>>
> > >>> On 05/07/2012 12:09 PM, Vishesh Handa wrote:
> > >>>
> > >>> > So, we're down to 3 options -
> > >>> >
> > >>> > *1.* nepomuk-core become a dependency of kdelibs.
> Kdelibs
> > is not
> > >>> touched.
> > >>> > *Problem:* Overlapping headers and possible mysterious
> > crashes if both
> > >>> > libraries are load

Re: [Nepomuk] The Nepomuk Situation

[Sebastian Trüg]

Pushed my stuff to branch "feature/nepomuk2Includes".

Feel free to implement Ivan's fancier solution. In that case my branch
might at least help in finding the places where stuff needs replacing.
If you do not I would appreciate a look over my branch to check if I
missed sth.

Cheers,
Sebastian

On 05/16/2012 08:37 PM, Vishesh Handa wrote:
> 
> 
> On Thu, May 17, 2012 at 12:02 AM, Sebastian Trüg  <mailto:tr...@kde.org>> wrote:
> 
> On 05/16/2012 08:23 PM, Vishesh Handa wrote:
> > What about kdelibs/nepomuk/utils/* and the other ui stuff?
> >
> > Or since those are just APIs they can wait.
> 
> I say let's postpone them, they are still in kdelibs. 
> 
> 
> The facets are quite weird and I am not sure about releasing them again.
> The ui stuff - not sure.
> 
> 
> We have all the runtime stuff and nepomuk-core, that's all that matters
> right now.
> 
> So, we just need to do -
> 
> 1. use the Nepomuk2 namespace, and nepomuk2 include directory
> 2. Remove kde-runtime/nepomuk
> 
> Regarding 1, I like Ivan's suggestion about BEGIN_NEPOMUK_NAMESPACE. If
> you want I can take care of it.
> 
> 
> > On Wed, May 16, 2012 at 11:49 PM, Sebastian Trüg  <mailto:tr...@kde.org>
> > <mailto:tr...@kde.org <mailto:tr...@kde.org>>> wrote:
> >
> > I now prepared the required repositories:
> >
> > scratch/trueg/nepomuk-kde-kio
> >  contains the 3 Nepomuk kio slaves
> >
> > scratch/trueg/nepomuk-kde-config
> >  contains the KCM and the controller systray app
> >
> > The question is: where should we move them? Something like
>     "KDE/Base"?
> > I suppose questions like these have already been discussed
> with respect
> > to KDE5?
> >
> > Cheers,
> > Sebastian
> >
> > On 05/07/2012 03:58 PM, Sebastian Trüg wrote:
> > > On 05/07/2012 03:47 PM, ivan.cu...@gmail.com
> <mailto:ivan.cu...@gmail.com>
> > <mailto:ivan.cu...@gmail.com <mailto:ivan.cu...@gmail.com>> wrote:
> > >> Maybe there could be something like qt has -
> > BEGIN_NEPOMUK_NAMESPACE... So that if the same needs to be done in
> > the future, we could just change the macro value.
> > >
> > > That would be much more work since each cpp file has the
> namespaces in
> > > the method definitions.
> > >
> > >> I don't know, thinking that Nepomuk2 namespace is looking
> rather
> > ugly :)
> > >
> > > it is indeed.
> > >
> > >> The dirtiest solution library-wise would be to have
> everything in
> > NepomukCore::Nepomuk::Something so that the only change in the
> > current code of nepomuk users would be a using namespace
> NepomukCore;
> > >>
> > >> Sorry for being a bit vague, I'm writing from my phone.
> > >>
> > >> Cheerio,
> > >> IvanOn 7.5.12. 14.49 Vishesh Handa wrote:
> > >>
> > >>
> > >>
> > >> On Mon, May 7, 2012 at 6:13 PM, Sebastian Trüg
> mailto:tr...@kde.org>
> > <mailto:tr...@kde.org <mailto:tr...@kde.org>>> wrote:
> > >>
> > >> On 05/07/2012 02:35 PM, Vishesh Handa wrote:
> > >>>
> > >>>
> > >>> On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg
> mailto:tr...@kde.org>
> > <mailto:tr...@kde.org <mailto:tr...@kde.org>>
> > >>
> > >>> <mailto:tr...@kde.org <mailto:tr...@kde.org>
> <mailto:tr...@kde.org <mailto:tr...@kde.org>>>> wrote:
> > >>>
> > >>>
> > >>> On 05/07/2012 12:09 PM, Vishesh Handa wrote:
> > >>>
> > >>> > So, we're down to 3 options -
> > >>> >
> > >>> > *1.* nepomuk-core become a dependency of kdelibs.
> Kdelibs
> > is not
> > >>> touched.
> > >>> > *Problem:* Overlapping headers and possible mysterious
> > crashes if both
> > >>> > libra

Re: [Nepomuk] The Nepomuk Situation

[Sebastian Trüg]

On 05/16/2012 09:16 PM, Vishesh Handa wrote:
> 
> 
> On Thu, May 17, 2012 at 12:29 AM, Sebastian Trüg  <mailto:tr...@kde.org>> wrote:
> 
> Pushed my stuff to branch "feature/nepomuk2Includes".
> 
> Feel free to implement Ivan's fancier solution. In that case my branch
> might at least help in finding the places where stuff needs replacing.
> If you do not I would appreciate a look over my branch to check if I
> missed sth.
> 
> 
> I will implement it, but not today. You'd missed one place. I've
> corrected it.
> 
> So now you just need to use the same script on your scratch
> repositories. 

Well, if you want to implement Ivan's idea that should be applied to the
scratch repos, too.

> Also, do you know anything about translations?

Hm, we should ask the l10n team about it before removing the code from
kde-runtime.

> 
> 
> Cheers,
> Sebastian
> 
> On 05/16/2012 08:37 PM, Vishesh Handa wrote:
> >
> >
> > On Thu, May 17, 2012 at 12:02 AM, Sebastian Trüg  <mailto:tr...@kde.org>
> > <mailto:tr...@kde.org <mailto:tr...@kde.org>>> wrote:
> >
> > On 05/16/2012 08:23 PM, Vishesh Handa wrote:
> > > What about kdelibs/nepomuk/utils/* and the other ui stuff?
> > >
> > > Or since those are just APIs they can wait.
> >
> > I say let's postpone them, they are still in kdelibs.
> >
> >
> > The facets are quite weird and I am not sure about releasing
> them again.
> > The ui stuff - not sure.
> >
> >
> > We have all the runtime stuff and nepomuk-core, that's all that
> matters
> > right now.
> >
> > So, we just need to do -
> >
> > 1. use the Nepomuk2 namespace, and nepomuk2 include directory
> > 2. Remove kde-runtime/nepomuk
> >
> > Regarding 1, I like Ivan's suggestion about
> BEGIN_NEPOMUK_NAMESPACE. If
> > you want I can take care of it.
> >
> >
> > > On Wed, May 16, 2012 at 11:49 PM, Sebastian Trüg
> mailto:tr...@kde.org>
> > <mailto:tr...@kde.org <mailto:tr...@kde.org>>
> > > <mailto:tr...@kde.org <mailto:tr...@kde.org>
> <mailto:tr...@kde.org <mailto:tr...@kde.org>>>> wrote:
> > >
> > > I now prepared the required repositories:
> > >
> > > scratch/trueg/nepomuk-kde-kio
> > >  contains the 3 Nepomuk kio slaves
> > >
> > > scratch/trueg/nepomuk-kde-config
> > >  contains the KCM and the controller systray app
> > >
> > > The question is: where should we move them? Something like
> > "KDE/Base"?
> > > I suppose questions like these have already been discussed
> > with respect
> > > to KDE5?
> > >
> > > Cheers,
> > > Sebastian
> > >
> > > On 05/07/2012 03:58 PM, Sebastian Trüg wrote:
> > > > On 05/07/2012 03:47 PM, ivan.cu...@gmail.com
> <mailto:ivan.cu...@gmail.com>
> > <mailto:ivan.cu...@gmail.com <mailto:ivan.cu...@gmail.com>>
> > > <mailto:ivan.cu...@gmail.com
> <mailto:ivan.cu...@gmail.com> <mailto:ivan.cu...@gmail.com
> <mailto:ivan.cu...@gmail.com>>> wrote:
> > > >> Maybe there could be something like qt has -
> > > BEGIN_NEPOMUK_NAMESPACE... So that if the same needs to
> be done in
> > > the future, we could just change the macro value.
> > > >
> > > > That would be much more work since each cpp file has the
> > namespaces in
> > > > the method definitions.
> > > >
> > > >> I don't know, thinking that Nepomuk2 namespace is looking
> > rather
> > > ugly :)
> > > >
> > > > it is indeed.
> > > >
> > > >> The dirtiest solution library-wise would be to have
> > everything in
> > > NepomukCore::Nepomuk::Something so that the only change
>     in the
> > > current code of nepomuk users would be a

Re: [Nepomuk] The Nepomuk Situation

[Sebastian Trüg]

On 05/16/2012 09:52 PM, Vishesh Handa wrote:
> 
> 
> On Thu, May 17, 2012 at 1:06 AM, Sebastian Trüg  <mailto:tr...@kde.org>> wrote:
> 
> 
> 
> On 05/16/2012 09:16 PM, Vishesh Handa wrote:
> >
> >
> > On Thu, May 17, 2012 at 12:29 AM, Sebastian Trüg  <mailto:tr...@kde.org>
> > <mailto:tr...@kde.org <mailto:tr...@kde.org>>> wrote:
> >
> > Pushed my stuff to branch "feature/nepomuk2Includes".
> >
> > Feel free to implement Ivan's fancier solution. In that case
> my branch
> > might at least help in finding the places where stuff needs
> replacing.
> > If you do not I would appreciate a look over my branch to
> check if I
> > missed sth.
> >
> >
> > I will implement it, but not today. You'd missed one place. I've
> > corrected it.
> >
> > So now you just need to use the same script on your scratch
> > repositories.
> 
> Well, if you want to implement Ivan's idea that should be applied to the
> scratch repos, too.
> 
> 
> Lets just get this done, before we try anything fancy. The hard feature
> freeze is tomorrow.
> 
> 
> > Also, do you know anything about translations?
> 
> Hm, we should ask the l10n team about it before removing the code from
> kde-runtime.
> 
> 
> Probably. Do you want me to email everyone? (packagers, release-team and
> i18n)
>  

please.

> 
> 
> >
> >
> > Cheers,
> > Sebastian
> >
> > On 05/16/2012 08:37 PM, Vishesh Handa wrote:
> > >
> > >
> > > On Thu, May 17, 2012 at 12:02 AM, Sebastian Trüg
> mailto:tr...@kde.org>
> > <mailto:tr...@kde.org <mailto:tr...@kde.org>>
> > > <mailto:tr...@kde.org <mailto:tr...@kde.org>
> <mailto:tr...@kde.org <mailto:tr...@kde.org>>>> wrote:
> > >
> > > On 05/16/2012 08:23 PM, Vishesh Handa wrote:
> > > > What about kdelibs/nepomuk/utils/* and the other ui stuff?
> > > >
> > > > Or since those are just APIs they can wait.
> > >
> > > I say let's postpone them, they are still in kdelibs.
> > >
> > >
> > > The facets are quite weird and I am not sure about releasing
> > them again.
> > > The ui stuff - not sure.
> > >
> > >
> > > We have all the runtime stuff and nepomuk-core, that's all that
> > matters
> > > right now.
> > >
> > > So, we just need to do -
> > >
> > > 1. use the Nepomuk2 namespace, and nepomuk2 include directory
> > > 2. Remove kde-runtime/nepomuk
> > >
> > > Regarding 1, I like Ivan's suggestion about
> > BEGIN_NEPOMUK_NAMESPACE. If
> > > you want I can take care of it.
> > >
> > >
> > > > On Wed, May 16, 2012 at 11:49 PM, Sebastian Trüg
> > mailto:tr...@kde.org> <mailto:tr...@kde.org
> <mailto:tr...@kde.org>>
> > > <mailto:tr...@kde.org <mailto:tr...@kde.org>
> <mailto:tr...@kde.org <mailto:tr...@kde.org>>>
> > > > <mailto:tr...@kde.org <mailto:tr...@kde.org>
> <mailto:tr...@kde.org <mailto:tr...@kde.org>>
> > <mailto:tr...@kde.org <mailto:tr...@kde.org>
> <mailto:tr...@kde.org <mailto:tr...@kde.org>>>>> wrote:
> > >     >
> > > > I now prepared the required repositories:
> > > >
> > > > scratch/trueg/nepomuk-kde-kio
> > > >  contains the 3 Nepomuk kio slaves
> > > >
> > > > scratch/trueg/nepomuk-kde-config
> > > >  contains the KCM and the controller systray app
> > > >
> > > > The question is: where should we move them?
> Something like
> > > "KDE/Base"?
> > > > I suppose questions like these have already been
> discussed
> > > with respect
> > >

Re: [Nepomuk] The Nepomuk Situation

[Sebastian Trüg]

On 05/16/2012 10:40 PM, Stephen Kelly wrote:
> Sebastian Trüg wrote:
> 
>> On 05/16/2012 08:23 PM, Vishesh Handa wrote:
>>> What about kdelibs/nepomuk/utils/* and the other ui stuff?
>>>
>>> Or since those are just APIs they can wait.
>>
>> I say let's postpone them, they are still in kdelibs.
>>
> 
> Just so there's no surprises later: all nepomuk stuff in kdelibs was removed 
> from frameworks a long time ago when we were told that the continuation of 
> nepomuk would be in the nepomuk-core and other repos.

that is fine.

Re: Nepomuk - Moving out of kde-runtime

[Sebastian Trüg]

I think we can manage BC. The only thing that would be hard are the DBus
interfaces. But since nepomuk-core contains client libs which are
supposed to be used instead of the dbus interfaces...

On 05/17/2012 09:19 PM, Sune Vuorela wrote:
> On 2012-05-17, Vishesh Handa  wrote:
>> @Packagers: We will not be maintaining binary compatibility in
>> nepomuk-core. At least not for KDE 4.10. We still need to break a lot of
>> things.
> 
> NACK.
> 
> this is a completely no go.
> 
> /Sune
> 
> 

Re: [Nepomuk] Nepomuk - Moving out of kde-runtime

[Sebastian Trüg]

On 05/17/2012 10:08 PM, Vishesh Handa wrote:
> 
> 
> On Fri, May 18, 2012 at 1:29 AM, Sune Vuorela  <mailto:nos...@vuorela.dk>> wrote:
> 
> On 2012-05-17, Sebastian Trüg mailto:tr...@kde.org>>
> wrote:
> > I think we can manage BC. The only thing that would be hard are
> the DBus
> > interfaces. But since nepomuk-core contains client libs which are
> > supposed to be used instead of the dbus interfaces...
> 
> Great. thanks.
> 
> 
> Can't we just break binary compatibility for 4.10. Just this once?
> 
> @Sebastian: Do you really want to have to deprecate the
> QueryServiceClient as mentioned in [1]? I rather not have stuff like
> that lying around in Nepomuk2. I'd like to not have to make hasty
> decisions right now (before 4.9).

Do you think we will do that change for 4.10?
If we wait until K5 we can break as much as we like...

> Plus, it's not like you'll have to recompile a lot of stuff. The only
> things that depend on nepomuk-core right now are nepomuk-kde-config and
> nepomuk-kde-kio.
> 
> [1] http://community.kde.org/Projects/Nepomuk/Irc_meeting_nepomuk_frameworks
> 
> 
> hugs and kisses
> 
> /Sune
> 
> >
> > On 05/17/2012 09:19 PM, Sune Vuorela wrote:
> >> On 2012-05-17, Vishesh Handa mailto:m...@vhanda.in>>
> wrote:
> >>> @Packagers: We will not be maintaining binary compatibility in
> >>> nepomuk-core. At least not for KDE 4.10. We still need to break
> a lot of
> >>> things.
> >>
> >> NACK.
> >>
> >> this is a completely no go.
> >>
> >> /Sune
> >>
> >>
> >
> 
> 
> 
> 
> -- 
> Vishesh Handa
> 
> 
> 
> ___
> Nepomuk mailing list
> nepo...@kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk

Re: Nepomuk - Moving out of kde-runtime

[Sebastian Trüg]

darn.
Now that I did it all

On 05/23/2012 01:34 AM, Vishesh Handa wrote:
> Sebastian
> 
> Change of plans. As per recent discussions with tsdgeos and kde_pepo on
> #kde-devel -
> 
> They would like to avoid too many new repositories. So, if it's okay
> with you we'll keep the nepomuk-kde-config and nepomuk-kde-kio code in
> kde-runtime, while the rest can be removed as it is there in nepomuk-core.
> 
> If you have the time to port some of the stuff to Nepomuk2 it would be
> nice, otherwise I'll take care of all of it tomorrow.
> 
> Good Night
>  
> On Tue, May 22, 2012 at 5:31 PM, Vishesh Handa  <mailto:m...@vhanda.in>> wrote:
> 
> 
> Does anyone have suggestions on where nepomuk-kde-kio and
> nepomuk-kde-config should be placed?
> 
> I was thinking under kde-baseaps, but that might not be correct. Any
> suggestions?
> 
> 
> On Fri, May 18, 2012 at 1:45 AM, Kevin Krammer  <mailto:kram...@kde.org>> wrote:
> 
> On Thursday, 2012-05-17, Sebastian Trüg wrote:
> > I think we can manage BC. The only thing that would be hard
> are the DBus
> > interfaces. But since nepomuk-core contains client libs which are
> > supposed to be used instead of the dbus interfaces...
> 
> I think as long as you didn't advertise the D-Bus interfaces as
> a kind of
> public API, e.g. by installing D-Bus introspection XML files,
> that should be
> fine.
> 
> Cheers,
> Kevin
> 
> >
> > On 05/17/2012 09:19 PM, Sune Vuorela wrote:
> > > On 2012-05-17, Vishesh Handa  <mailto:m...@vhanda.in>> wrote:
> > >> @Packagers: We will not be maintaining binary compatibility in
> > >> nepomuk-core. At least not for KDE 4.10. We still need to
> break a lot of
> > >> things.
> > >
> > > NACK.
> > >
> > > this is a completely no go.
> > >
> > > /Sune
> > >
> > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> > >> unsubscribe <<
> 
> --
> Kevin Krammer, KDE developer, xdg-utils developer
> KDE user support, developer mentoring
> 
> 
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
> 
> 
> 
> 
> -- 
> Vishesh Handa
> 
> 
> 
> 
> -- 
> Vishesh Handa
> 

Re: KDE SC 4.8.4 important problems

[Sebastian Trüg]

On 06/10/2012 12:57 PM, Andreas Pakulat wrote:

Hi,

Am Sonntag, 10. Juni 2012 schrieb Peter Penz :

On 06/10/2012 11:20 AM, Aaron J. Seigo wrote:

On Sunday, June 10, 2012 03:23:04 José Manuel Santamaría Lema wrote:

#1 dolphin:
#2 gwenview
#6 kontact executing various components: calendar, to-do
list, journal
#7 kmail links


these are all the same crash, or at least related to each other.
it is
crashing in KServiceTypeTrader::__defaultOffers or
KMimeTypeTrader::query
apparently at times in KSycocaDict::find_string.


The issue has been tracked at
https://bugs.kde.org/show_bug.__cgi?id=268064
 - updating Soprano to
the latest master resolves the crash. But I don't know more about
the root-cause of this. Probably a Nepomuk-related update missed a
proper versioning-check of Soprano?


There has been an abi breakage in soparano's latest release (fixed in
the repository already), so updating to that soprano release requires
rebuilding all other code that uses it. I've seen backtraces ending in
qstring::ref having such abi incompatibilities as cause, so it would fit
at least those cases.


Can someone explain how a missing class declaration (that is all that 
changed) can result in such a crash?

I simply want to understand, not challenge it.

Cheers,
Sebastian

Re: KDE SC 4.8.4 important problems

[Sebastian Trüg]

On 06/12/2012 06:43 PM, Vishesh Handa wrote:



On Tue, Jun 12, 2012 at 7:58 PM, Sune Vuorela mailto:nos...@vuorela.dk>> wrote:

On 2012-06-12, Vishesh Handa mailto:m...@vhanda.in>> wrote:
 > --bcaec554d60626569204c246cba9
 > Content-Type: text/plain; charset=ISO-8859-1
 >
 > Yeah. So Nepomuk is the cause of the problems -
 >
 > Here our our options -
 >
 > 1. I revert Sebastian's commits in kdelibs. This should fix the
issue, but
 > we would need to reintroduce the changes for 4.9, and since we do
not have
 > separate branches ...
 >
 > 2. Sebastian should release a new version (2.8) of Soprano any
day now,
 > packagers will need to get everyone to update.

3. Actually track the bug down and fix it rather than try to do
workarounds?
This sounds like the most obvious thing to me.


I'm not familiar with the code or the changes that have been made, so
I'm not going to try to do that right now. Probably.

@Sebastian: Do you have the time?


I do not have much time. But the real problem is that I am not sure 
where to look. It has to do with my own implementation of unix socket 
communication. Someone with experience in that area might want to review 
the *Socket* classes in soprano/client...





/Sune




--
Vishesh Handa

Re: KDE SC 4.8.4 important problems

[Sebastian Trüg]

I am totally lost. What is the problem with that commit?

On 06/12/2012 07:40 PM, José Manuel Santamaría Lema wrote:



Therefore, I tend to think the kdelibs commit mentioned in that bug report
(3d66d429cb48781881af3e735f2a80af2114ab25) shouldn't have been done for
4.8.4. A confirmation from a Nepomuk developer would be highly
appreciated.


Just in case it isn't obvious enough, actually I meant this one shouldn't have
been done for 4.8.4:
http://quickgit.kde.org/index.php?p=kdelibs.git&a=commit&h=a43824a200ed76cef48a90bd3aee8547698b7c91
which is the kdelibs one. I just pasted the wrong hash.

Re: KDE SC 4.8.4 important problems

[Sebastian Trüg]

On 06/13/2012 10:58 PM, Albert Astals Cid wrote:

El Dimecres, 13 de juny de 2012, a les 17:43:10, Vishesh Handa va escriure:

On Wed, Jun 13, 2012 at 2:34 PM, Sebastian Trüg  wrote:

I am totally lost. What is the problem with that commit?


AFAIK, the problem is that changes were made in both Soprano and KDElibs
for 4.9, but for 4.8.4, they are using this "changed" kdelibs with the old
soprano.


Why did this happen? kdelibs is frozen so there should not be a commit that
needs to be only in kdelibs 4.9 and not in kdelibs 4.8.4


Simple: it is a bugfix. But apparently that fix reveals another bug 
which I only fixed in Soprano 2.8.



Cheers,
   Albert




On 06/12/2012 07:40 PM, José Manuel Santamaría Lema wrote:

  Therefore, I tend to think the kdelibs commit mentioned in that bug


report
(**3d66d429cb48781881af3e735f2a80**af2114ab25) shouldn't have been done
for
4.8.4. A confirmation from a Nepomuk developer would be highly
appreciated.


Just in case it isn't obvious enough, actually I meant this one shouldn't
have
been done for 4.8.4:
http://quickgit.kde.org/index.**php?p=kdelibs.git&a=commit&h=**
a43824a200ed76cef48a90bd3aee85**47698b7c91<http://quickgit.kde.org/index.
php?p=kdelibs.git&a=commit&h=a43824a200ed76cef48a90bd3aee8547698b7c91>
which is the kdelibs one. I just pasted the wrong hash.