My initial tests with KDE-4.4.92 (4.5-RC2) is that it is working very well, a
perfect and smooth update. There are some issues from the previous release I
need to check and will do so later today.
I also decided to give qt-4.7.0-0.26.beta2.fc13 a test and some of the bugs I
experienced with the earlier QT beta's have been fixed :)
Thanks again to all involved..
Fedora release 13 (Goddard)
Registered Linux user number #342953
Does kdepim/kaddressbook enable one now
to keep a common mailing list for Fedora/KDE
and the unspeakable OS?
Maybe LDAP is the simplest solution?
e-mail: gayleard /at/ eircom.net
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
I'm sending this email to more widely announce something we've been
working on for a while. I've spoken to leaders of the XFCE, KDE and LXDE
teams about this. We'd like to propose expanding the desktop validation
testing that was initiated in the Fedora 13 cycle.
During F13, these tests were used to check for blocker bugs only for the
GNOME desktop. We did run the tests against some of the other desktops
at some checkpoints, but failures from those runs weren't considered as
blocking the release.
For the Fedora 14 cycle, I'd like to try to run the desktop validation
test set - that's the testing documented at
https://fedoraproject.org/wiki/QA:Desktop_validation_testing - on all
four major desktops at each checkpoint, and consider failures at the
relevant level to be release blocking bugs.
We've made some adjustments to the test suite already to reflect the
input from each SIG, and we may yet work on refining the procedure a
little more, but the outline of the plan is simple enough.
This would be technically on an experimental basis, as the GNOME testing
was during the F13 cycle; if it seems to be causing too much trouble and
making it impractical to work to our release plans, we might reconsider
the idea during the cycle. But we didn't have to do that for F13, and
I'd hope we won't have to for F14 either.
The leaders of the various desktop SIGs are fairly confident that their
SIGs will be able to contribute in running the tests and fixing blocker
issues promptly as they're identified. I think the QA group will also be
able to contribute to this process, particularly in carrying out the
If anyone from QA or any of the SIGs has comments or concerns on the
proposal, please air them now! Thanks a lot :)
If we do end up going ahead with the idea, I'll follow up with all of
the SIGs when we hit the first round of validation testing to keep you
all informed on how the process works and how to contribute to it.
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
[ 9%] Generating index.cache.bz2
cd /builddir/build/BUILD/kdesvn-1.5.3/doc/nl && /usr/bin/meinproc4 --check
index.docbook:14: warning: failed to load external entity "dtd/kdex.dtd"
Looks like kdex.dtd is gone from kdelibs 6:4.4.80-3.fc14.
On my F13 box:
# rpm -ql kdelibs | grep kdex.dtd
Anyone know where it has moved to or what replaces it?
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
---------- Forwarded Message ----------
Subject: [Kde-pim] KDEPIM 4.5 releases
Date: Wed 7 July 2010, 1:32:29 am
From: Thomas McGuire <mcguire(a)kde.org>
we had a KDEPIM BoF at Akademy today, the meeting notes can be found at
Basically the state of KMail 2 is not something that can be called "beta",
many problems with it, mainly with migration and filtering, but also some
other blocking issues.
So the plan we discussed basically is:
- The tarball that was created recently and named "beta1" is nowhere near
beta1 quality. It is already packaged though, so we can't withdraw it,
only can communicate it correctly to manage expectations
- We release a beta version of KDEPIM from the 4.5 branch each time a
release of KDE SC 4.5.x is done. This means next beta gets released with
SC 4.5.0, the one after that with KDE SC 4.5.1 and so on. We release the
final version of KDEPIM from the 4.5 branch once we deem it is in a
releasable state, at the very least with KDE SC 4.6.0.
- The bugfixing work will take place in the 4.5 branch, not trunk. More on
that in a separate email.
- Trunk is open for all commits again, including new strings and features.
People should work on the 4.5 branch as their main branch though, and
commit to trunk in exceptions. Use 4.5 as the main branch to make KDEPIM
ready for the release!
Exceptions to that being, for example:
- Feature merges from e35, e4 and komo
- Patches that introduce new features from non-core developers
- The Komo branch, where the development for the mobile PIM applications
done, will be merged this or next week to trunk, and then removed.
- kdepim and kdepimlibs will depend on kdelibs 4.5.x, _not_ kdelibs trunk.
That means no new API from kdelibs trunk may be used.
As an exception, the macro KDE_IS_VERSION can be used to conditionally
compile in stuff that depends on kdelibs trunk. The RTL patch from
comes to my mind here.
Note that for now we still depend on kdelibs 4.4, please wait for an
announcement from Volker that we can actually depend on kdelibs 4.5.
Please correct me if I missed anything or if something is not correct.
please add any additions if you have.
== http://hackersramblings.wordpress.com | http://rix.si/ ==
== http://rix.si/page/contact/ if you need a word ==
OK, the much ballyhoo'd kdepim-4.5-beta1 builds are queud'd to
kde-unstable (f13 only at first, f12 coming soon).
If you want to opt out of getting this, you can add to
/etc/yum.repos.d/kde.repo in the [kde-unstable] section:
exclude=kdepim kdepim-libs kdepim-devel kdepim-runtime*
I use kvkbd frequently and ever since I rebooted, kvkbd seems to be
very sensitive when pressing a key. For example when I click the letter
k, it will print it 4 times. I do not know what changed. Any help
would be grateful.
Kvkbd is a virtual keyboard for KDE, it contains many feature like
system tray and dock support, autodetection and on the fly change of the
keyboard layout, scripting with DBus, etc.