unclear about bug reporting for provisional kde repos
by Petrus de Calguarium
Should bugs be reported for kde-4.4.92 rpms that are provisionally provided by
the out-of-fedora kde-unstable repo?
Or should one wait for kde-4.5 to enter at least (fedora) updates-testing
(since these are most likely kde programming, not fedora packaging, issues)?
Eg., since a couple of weeks, wobbly windows no longer wobble; since a couple
of weeks, desktop cube no longer works; possibly others...
13 years, 10 months
4.5-rc2/QT-4.7 Beta2 working very well
by Colin J Thomson
Hi,
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..
Colin
--
Fedora release 13 (Goddard)
Registered Linux user number #342953
13 years, 10 months
Fedora/KDE + Windows contact list
by Timothy Murphy
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?
--
Timothy Murphy
e-mail: gayleard /at/ eircom.net
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
13 years, 10 months
Desktop validation testing expansion
by Adam Williamson
Hi, everyone.
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
testing.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
13 years, 10 months
kdesvn doc build failure
by Orion Poplawski
http://koji.fedoraproject.org/koji/taskinfo?taskID=2223537
[ 9%] Generating index.cache.bz2
cd /builddir/build/BUILD/kdesvn-1.5.3/doc/nl && /usr/bin/meinproc4 --check
--cache
/builddir/build/BUILD/kdesvn-1.5.3/i686-redhat-linux-gnu/doc/nl/index.cache.bz2 /builddir/build/BUILD/kdesvn-1.5.3/doc/nl/index.docbook
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
/usr/share/kde4/apps/ksgmltools2/customization/dtd/kdex.dtd
Anyone know where it has moved to or what replaces it?
--
Orion Poplawski
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
13 years, 10 months
Fwd: [Kde-pim] KDEPIM 4.5 releases
by Ryan Rix
---------- 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>
To: kde-pim(a)kde.org
Hi,
we had a KDEPIM BoF at Akademy today, the meeting notes can be found at
http://community.kde.org/KDE_PIM/Meetings/Akademy-2010.
Basically the state of KMail 2 is not something that can be called "beta",
too
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,
we
only can communicate it correctly to manage expectations
- We release a beta version of KDEPIM from the 4.5 branch each time a
minor
release of KDE SC 4.5.x is done. This means next beta gets released with
KDE
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
only
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
- etc
- The Komo branch, where the development for the mobile PIM applications
was
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
Ebrahim
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.
Should
happen soon.
Please correct me if I missed anything or if something is not correct.
Also,
please add any additions if you have.
Regards,
Thomas
-----------------------------------------
--
Ryan Rix
== http://hackersramblings.wordpress.com | http://rix.si/ ==
== http://rix.si/page/contact/ if you need a word ==
13 years, 10 months
kdepim-4.5-beta1 to kde-unstable
by Rex Dieter
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*
-- Rex
13 years, 10 months
kdepim-4.5-beta1
by Colin J Thomson
Hi,
looks like kdepim-runtime is missing for kdepim-4.5b1 (i386)
Colin
--
Fedora release 13 (Goddard)
Registered Linux user number #342953
13 years, 10 months
kdepim4.5
by Christoph Kaulich
Hello,
just a short question, will there be a kdepim 4.5 beta1 build for fc13?
Thanks
Christoph
13 years, 10 months
kvkbd too sensitive when pressing a key
by Kyle
Hello,
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-0.6-3.fc13.x86_64
Description:
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.
Kyle
13 years, 10 months
