On Wednesday 14 April 2010 03:28:35 pm toma wrote:
Dear Release Team, Bindings Team,
Akonadi will have a meeting from may 13th to may 16th. During this meeting
we will hack at some small features. As kdepim is undergoing major changes
due to the conversion to the Akonadi pillar, it is
--
Subject: [Fwd: KDE 4.4.2 tarballs (try #1) uploaded]
Date: Sunday 28 March 2010, 11:06:49 pm
From: Simon Edwards si...@simonzone.com
To: Richard Dale rd...@foton.es
FYI, from the releaseteam mailing list.
--
Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall
si
is the solution here?
You'll have to ask Richard Dale since this error is in smoke and not PyKDE.
A strict ban on header file changes during the RC phase would be a good
way to help reduce these kinds of last minute problems. Even in these
late stages the plasma team are still stuffing around
On Thursday 21 January 2010 01:03:55 pm Dirk Mueller wrote:
On Thursday 21 January 2010, Richard Dale wrote:
Certainly we didn't need the KDE 4.4 release to be branched off from the
trunk a month before the actual release, while we are right in the middle
of trying to sort out kdebindings
On Thursday 04 June 2009 12:18:24 pm David Faure wrote:
On Wednesday 13 May 2009, Arno Rehn wrote:
On Wednesday 13 May 2009 11:51:58 Dirk Mueller wrote:
On Tuesday 12 May 2009, Dirk Mueller wrote:
I still don't have a building kdebindings tarball, in this state we
can not release.
On Wednesday 30 April 2008 08:42:31 Cyrille Berger wrote:
Forwarding to kde-bindings, since they are the people who know better about
this.
On Wednesday 30 April 2008, Allen Winter wrote:
On Tuesday 29 April 2008 18:34:29 Aaron J. Seigo wrote:
of course, if bindings ever get made for
On Wednesday 03 October 2007 17:47:58 Arno Rehn wrote:
It's the build system stuff like 'qtguess.pl.cmake' that is really
difficult to maintain, and I that I would like to get rid of first.
I'd just let gcc resolve which defines exist. Write a small app with
#ifdef QT_NO_FOOBAR
On Wednesday 03 October 2007 18:52:38 Caleb Tennis wrote:
There is other tricky stuff in generate.pl.cmake for finding the Qt and
KDE headers, whether they are ordinary installed ones, Mac OS X
frameworks or a qt built in place and not installed. Caleb's recent
change to get Mac OS X
of the development platform?
Richard Dale says Python and Ruby in good shape by late October, and
possibly C# too.
If Richard says he can do it, i say we can try it :-)
Thats not enough. somebody has at least to be able to confirm that the
bindings *compile*. right now, kdebindings does
On Tuesday 02 October 2007, Richard Dale wrote:
I use cmake to build the smoke libs and the ruby and python bindings, and
it all works fine. I'm afraid I can't reproduce the perl error that the
dashboard build has.
Oops, I meant Ruby and C# of course.
-- Richard
. in fact I only try to build the smoke-qt
bindings. but the qtguess configury (whatever it is good for) runs twice,
and 2nd time it fails completely, aborting the build.
I've mailed the log already to Richard Dale and I already disabled the
smoke-kde bindings (which couldn't be build at all due
SVN commit 719655 by rdale:
* Attempt to remove build errors from the smoke config script
CCMAIL: [EMAIL PROTECTED]
CCMAIL: release-team@kde.org
M +2 -84 kde/qtguess.pl.cmake
M +31 -112 plasma/qtguess.pl.cmake
___
release-team
On Monday 01 October 2007, Pau Garcia i Quiles wrote:
I think the problem is that the FindQt4 cmake file used by the smoke/qt
build sets up a macro called QT_LIBRARIES, but the version of FindQt4 in
KDE doesn't set that up. So we do need different qtguess.pl.cmake files
for smoke/qt, and
13 matches
Mail list logo
