I see there are some updates for kde-workspace but notice the updates also
want to install nepomuk-core* and virtuoso-opensource. I thought nepomuk was
not not required now we have Baloo?
F20 - kde-4.13.0
Fedora 20 - (Heisenbug)
Registered Linux user number #342953
KDE 4.13 from kde-unstable works just fine here
only one iusse i faced: in knqueror the mousover
preview don't work - there is a spinning wheel
and nothing happens
that's a cool feature i'd love to come back :)
Background (to frame the quandry):
In KDE, when you go to a website using firefox, the master password window
appears on top of the main firefox window and it stays there, no matter
where the mouse pointer happens to be, and it waits until you enter a
password or cancel the password entry window. This is highly desirable.
However, when kmail is opened, the kwallet window briefly appears and then
immediately slides behind the kmail window, unless the mouse pointer
happens to be positioned directly over the newly appeared password entry
window. This is a real nuisance.
How can I get the first behaviour as a default behaviour for all appearing
password entry windows (or other windows that require input before the
application canbe used)?
On 04/04/2014 02:52 PM, Ernesto Manríquez Mendoza wrote:
> 1. Will KDE 4.13 be included in Fedora 20, starting with the kde-unstable
> repositories? Any ETA? Or will an upgrade to Fedora 21 (Rawhide, technically)
> be required?
Yes, kde-4.13.0 has been available in both rawhide and f20/kde-unstable
repos since this past weekend.
> 2. Will a rebuild of Qt 4 and Qt 5 against libxcb 1.10 be provided? The
> "libxcb0-compat" solution provided in the fschwarz Copr repository doesn't
> work, because it crashes every program using Qt 5 (I rely on Sigil, so, it's
> not an option for me).
I'm not aware of the issue(s) involved here, can you please clarify or
provide more detail?
On 04/17/2014 08:29 AM, Ernesto Manríquez Mendoza wrote:
> If Fedora 20 begins to require libxcb 1.10, a rebuild of all the KDE and Qt
> stack will be needed.
Eep! that will definitely be a deal-breaker as far as I'm concerned.
I installed Fedora 20 KDE on Thinkpad T420i and upgraded to the latest
which left the system unbootable. My initial impression was that this was
kernel related as kernel was upgraded from 3.11.10 to 3.13.9 and booting
into 3.11.10 was working fine.
I have tried this several times to replicate the issue.
In another try I did the same installed, upgraded and system was left
unbootable. This time I disabled kdm and logged into tty. System was
working fine. I installed i3 and used it for a while under 3.13.9 without
any problem. Then I decided to run KDE and it was working fine.
So in a nutshell install, upgrade and KDE won't boot but if you log in once
in tty or another window manager and then back into KDE and it would work
I filed a kernel bug report which might not be even valid anymore.
I have been using Fedora 20 KDE since the release and it had always worked
fine. I am not so sure about the current oddities.
On 04/17/2014 08:53 AM, Rex Dieter wrote:
> On 04/17/2014 08:29 AM, Ernesto Manríquez Mendoza wrote:
>> If Fedora 20 begins to require libxcb 1.10, a rebuild of all the KDE
>> and Qt
>> stack will be needed.
> Eep! that will definitely be a deal-breaker as far as I'm concerned.
Just checked as far as I can tell,
libxcb-1.10 is built only on rawhide (so far)
On 04/17/2014 07:44 AM, Rex Dieter wrote:
> On 04/04/2014 02:52 PM, Ernesto Manríquez Mendoza wrote:
>> 1. Will KDE 4.13 be included in Fedora 20, starting with the kde-unstable
>> repositories? Any ETA? Or will an upgrade to Fedora 21 (Rawhide,
>> be required?
Ah, just noticed this post originated on Apr 04, and there have been
followup posts from you about since then, but I would still appreciate
more info about the libxcb thing.
I am running kde-4.13 (the apps I mean :-) ) and I have baloo running for a long time.
Where I can I find details about what baloo is doing, I read (in .xsession-error that baloo is failing on some files and so it is black listing them). The problem is that it always refers to a number.
My point/question is that I can not find the need feedback to know (as an example among others):
* how many files it needs to process to finish this stage?
* what are the file it fails and what can be done about it?
The first was available with nepomuk, and I must recognize that for a first iteration baloo is better behaved that nepomuk was most of the time. In any case baloo is taking a long time, and in my laptop it is I/O bounded while most of the time it does not clogs the cpu to 100% but the disk access led is permanently on.
On 04/14/2014 05:56 AM, Laurent Rineau wrote:
> Le Monday 14 April 2014 10:13:20 José Matos a écrit :
>> On Thursday 10 April 2014 23:29:57 José Matos wrote:
>>> Hi Daniel,
>>> the akonadi server seems to be trapped in a continuous loop. If I
>>> kill one another one is started. So it is not obvious how to proceed.
>>> Looking to top I notice that there is a mysqld process running for 55
>>> min (the computer is now up for 7h24m).
>>> This seems to be the same pattern of yesterday.
>> Just a followup, in case anyone has the same problem.
>> I have solved this last Thursday with Daniel's help.
>> The culprit was:
>> Sql error: The total number of locks exceeds the lock table size QMYSQL:
>> Unable to execute query
>> Query: ALTER TABLE PartTable ADD FOREIGN KEY (pimItemId) REFERENCES
>> PimItemTable(id) ON UPDATE CASCADES ON DELETE CASCADE
>> and the solution was, since I am using an internal mysql server, was to
>> increase the value of the innodb_buffer_pool_size parameter on
>> The value that was there was of 8M and I have set it to 128M.
> I was impacted by that bug too, but I did not found the correct fix. I removed
> my Akonadi database last Friday.
> I think that should be reported to upstream KDE, so that they find a way to
> smooth the upgrade.
As a downstream/packaging issue, fedoras akonadi packaging currently
opts to default to using the values in:
(ie, compare each to /etc/aknoadi/mysql-global.conf)
The rationale being that the -big config, well, was *too* big,
especially for casual users. Perhaps we will have to rethink that.
In the meantime, yes, if the values in -mobile are problematic, then
upstream should also consider adjusting things too.