Re: [Kde-bindings] Akonadi Meeting: exception request.
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 difficult to implement no new features during such a meeting. More importantly there will be an API review of new API introduced in the KDE 4.5 development cycle. This usually means tons of little changes, such as renames and additional consts, etc. I hereby ask an exception from the soft API freeze and Feature Freeze during this meeting. In practise, that means we might slip in one or two features and we won't mail the kde-bindings people on API changes for kdepimlibs and kdepim. I would like to remove the akonadi Smoke bindings from the kdebindings module for KDE 4.5. I would prefer only Smoke library bindings for kdelibs, kdesupport, 3rd party Qt-only bindings and the Qt libs bindings in kdebindings. We are very happy to help you move the existing Ruby (plus C#, Perl, PHP etc if needed) and Smoke libraries to an Akonadi kde module and help support it in the KDE 4.5 release. I not sure what Simon Edwards and the PyKDE guys think about this. They have already moved some python bindings out of kdebindiings and into the svn modules that the bindings wrap (eg Marble). -- Richard ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Fwd: [Fwd: KDE 4.4.2 tarballs (try #1) uploaded]
This looks like a bug that I thought Arno has already fixed. I'm just building the smoke phonon library against the version of phonon I have installed with Kubuntu KDE 4.4. I assume this is some version of the version of Phonon that is in Gitorius. -- Richard -- Forwarded Message -- 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...@simonzone.com | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. - ---BeginMessage--- Hi, now I have this error with revision 1108301: [ 46%] Building CXX object smoke/phonon/CMakeFiles/smokephonon.dir/x_1.o cd smoke/phonon /usr/lib/ccache/c++ -Dsmokephonon_EXPORTS -D_BSD_SOURCE - D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DQT_NO_STL -DQT_NO_CAST_TO_ASCII - D_REENTRANT -DKDE_DEPRECATED_WARNINGS -DQT3_SUPPORT -DSMOKE_BUILDING - DGCC_VISIBILITY -Wall -g -O2 -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef - Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno- exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden -fvisibility-inlines-hidden - DNDEBUG -DQT_NO_DEBUG -fPIC -I. -I../../../smoke/phonon -I../../.. -I../.. - I../../../smoke -I/usr/include/KDE -I/usr/include/qt4/KDE -I/usr/include/qt4 - I/usr/include/qt4/phonon -I/usr/include/qt4/QtXmlPatterns - I/usr/include/qt4/QtXml -I/usr/include/qt4/QtWebKit - I/usr/include/qt4/QtUiTools -I/usr/include/qt4/QtTest -I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtSql -I/usr/include/qt4/QtScriptTools - I/usr/include/qt4/QtScript -I/usr/include/qt4/QtOpenGL - I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtMultimedia - I/usr/include/qt4/QtHelp -I/usr/include/qt4/QtDesigner - I/usr/include/qt4/QtDBus -I/usr/include/qt4/QtAssistant - I/usr/include/qt4/Qt3Support -I/usr/include/qt4/QtGui - I/usr/include/qt4/QtCore -I/usr/include/qt4/Qt - I/usr/share/qt4/mkspecs/default -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -o CMakeFiles/smokephonon.dir/x_1.o -c x_1.cpp /usr/include/qt4/QtCore/qscopedpointer.h: In member function 'void __smokephonon::x_Phonon__AbstractMediaStream::x_26(Smoke::StackItem*)': /usr/include/qt4/QtCore/qscopedpointer.h:170: error: 'QScopedPointerT, Cleanup QScopedPointerT, Cleanup::operator=(const QScopedPointerT, Cleanup) [with T = Phonon::AbstractMediaStreamPrivate, Cleanup = QScopedPointerDeleterPhonon::AbstractMediaStreamPrivate]' is private x_1.cpp:287: error: within this context /usr/bin/cmake -E cmake_progress_report /tmp/buildd/kdebindings-4.4.2/obj- x86_64-linux-gnu/CMakeFiles [ 46%] make[3]: *** [smoke/phonon/CMakeFiles/smokephonon.dir/x_1.o] Error 1 make[3]: Leaving directory `/tmp/buildd/kdebindings-4.4.2/obj-x86_64-linux- gnu' make[2]: *** [smoke/phonon/CMakeFiles/smokephonon.dir/all] Error 2 make[2]: *** Waiting for unfinished jobs On Sunday 28 March 2010 05:07:27 pm Simon Edwards wrote: Hello all, Eric Hameleers wrote: On Fri, 26 Mar 2010, Dirk Mueller wrote: I just finished uploading the first set of KDE 4.4.2 tarballs. Please let me know of any issues that you might experience. Intended release date is next week Tuesday/Wednesday (I'm sorry that I'm a day late with tagging). The kdebindings tarball fails to build with this error: It is fixed up on the 4.4 branch (rev 1108301). cheers, ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team ---End Message--- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Wednesday 20 January 2010 07:17:08 pm Simon Edwards wrote: Hello, Dirk Mueller wrote: On Thursday 07 January 2010, Simon Edwards wrote: [python/pykde4/CMakeFiles/python_module_PyKDE4_plasma.dir/all] Error 2 make: *** [all] Error 2 It should work fine with a recent SIP and PyQt snapshot. A new stable release of PyQt is imminent, then can I up the version check in CMakeLists.txt. Sorry for the inconvenience guys. Is it possible to make the bindings only use released versions of sip/pyqt? A new SIP and PyQt stable are out and PyKDE now requires it and checks for it in CMakeLists. Although annoying, not using SIP/PyQt snapshots during the 4.4 dev cycle would have required dropping most of the new changes to Plasma which depend on new functionality in Qt 4.6. This is really one of the risks of KDE requiring a bleeding edge Qt functionality (4.6) which wasn't released until quite late in the KDE dev cycle. Other things like PyQt depend on Qt and don't get much time to react and be updated once a new Qt version is out. with RC2, there is a new problem: /usr/bin/cmake -E cmake_progress_report kdebindings-1077263/build/CMakeFiles What 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 with their (new) APIs. I don't think we need a strict ban. I think the problem is that the kde bindings release schedule is unavoidably slightly behind the KDE libraries release schedule. However, the overall KDE release schedule doesn't take this into account. 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. -- Richard ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
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. Hi Richard, I don't understand - this is exactly what happened - we've branched from trunk one month before the targetted final release. Yes, but what I meant was that for kdebindings that doesn't make sense. If you are working on a KDE application then it is a good idea to be able to start adding new features to the trunk while fixing things in the 4.4 branch a month before the release. But we don't even quite have the time to fix the 4.4 branch, let alone be adding things for the 4.5 release in the trunk at the moment. So I think splitting off the 4.4 release from trunk about a week before the final release would be best for kdebindings. How can we get kdebindings to build for RC2? This is currently blocking the release. there are several reports on kde-packager@ and release-team@ about this, I can collect my own list of compile errors, I just don't know how to solve them. I had a look a the compile error about the printer method, and there is supposed to be a configure check for the Smoke libs generation that tests for printer functionality built in the Qt libs. It looks as though there is a problem with that. Arno Rehn is the expert on the bindings generator, but he doesn't seem to be around at the moment. -- Richard ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] [RED] Re: KDE 4.3 Beta1 packages (4.2.85)
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. Please help. Release delayed until tomorrow morning. There was no solution to all the building problems of kdebindings, so I had to remove it from 4.3 beta1 release.This is very embarassing, I hope we can fix it for beta2 :-( I haven't seen any reports of kdebindings not building - a Mandriva packager first made us aware of some missing files in csharp/soprano. What errors do you get? And please send them to this list since I don't think many bindings people are reading the release/packaging lists (at least I'm not, but maybe I should join). The details are always available on http://developer.kde.org/~dirk/dashboard/, or by listening to dashbot on irc. E.g. the current build failure is the following: [Thu Jun 4 2009] [00:26:42] dashbot 4.2/kdebindings r971528 failed (details under http://developer.kde.org/~dirk/dashboard/ ): [Thu Jun 4 2009] [00:26:42] dashbot smoke/soprano/x_10.cpp: In member function 'void x_Soprano__LiteralValue::x_57(Smoke::StackItem*) const': [Thu Jun 4 2009] [00:26:42] dashbot smoke/soprano/x_10.cpp:516: error: 'LanguageTag' was not declared in this scope But I guess that's just a wrong soprano version? If the current Smoke sources were generated with an old version of soprano it might explain the error. I think dashbot needs to do a 'make clean' to remove the sources and then 'make' to regenerate them against the current soprano headers. If that still doesn't work then it is a bug. -- Richard ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] Pre-approved Languages
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 another module we're going to be in this same boat again aren't we? i wonder if later on it might make sense to split up kdebindings into modules that reflect the KDE/ modules ... so kdebindings-libs, kdebindings-base, kdebindings-pim ... i assume this would be a major pain for the bindings teams, but would it be feasible? if so, when would be a realistic time frame for such a modification? Or, maybe each current module can have a bindings subdir? i.e. kdelibs/bindings, kdebase/bindings, kdepimlibs/bindings, ...? The second suggestion seems sensible to me, with subdirs for each language like kdelibs/bindings/python etc. Having a whole new set of modules in parallel with the existing libs just seems to complicate things. But I don't know enough about this discussion to know what problem we're trying to solve. -- Richard ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] Replacing kalyptus
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 printf(QT_NO_FOOBAR\n); #endif for every define that should be tested, compile it and run it. It should run way faster than the perl script and be more convenient to maintain. The source could be autogenerated from a list of defines that should be tested. I think there is a built in facility of cmake that does exactly this. As I thought the current build system was working, I haven't treated changing to that as urgent. 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 framework headers working, broke the code to get qt in place build headers working. I haven't worked out how to get both working at once yet. -- Richard ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] Replacing kalyptus
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 framework headers working, broke the code to get qt in place build headers working. I haven't worked out how to get both working at once yet. Sorry 'bout that. I'll take a look when time permits. No, problem - it was much more important to get mac frameworks working for qtruby. But for kde4 it is more important to have in place qt builds working at present. Hence, my choice not to promote the code from qt to the kde smoke bindings. -- Richard ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] Questions About the New Schedule
On Monday 01 October 2007, Simon Edwards wrote:
Hello all,
Sebastian Kügler wrote:
On Monday 01 October 2007 10:37:06 Andreas Pakulat wrote:
On 01.10.07 06:30:25, Dirk Mueller wrote:
On Saturday, 8. September 2007, Albert Astals Cid wrote:
5) Should language bindings be part 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 not compile, and after
I spent an hour or so looking, I'm sure that it can not compile for
anyone at all, given the fundamental bugs in the build system.
it is my understanding that Richard uses a completely different build
system to maintain the bindings, at least thats what he used to do in
KDE3 times. There has to be at least somebody who maintains the
official build system, and that person has to be != me.
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.
http://ktown.kde.org/~dirk/dashboard/
I just did a diff from the kalyptus code as it was in 2004, and how it is
today and the line with the error is much the same:
@@ -226,17 +217,18 @@
# Otherwise, compile the default ones. Used for filtering in readCxxLine.
if ( my @qt_defines = map { ($_=~m/^QT_(.*)/)[0] } keys %defines)
{
-my $regexp = m/^#\\s*ifn?def\\s+QT_(?: . join('|', map
{ \$qt_defines[$_] } 0..$#qt_defines).)/o;
+my $regexp = m/^#\\s*if\\s*[n!]?\\s*def(ined\\()?\\s*QT_(?: . join('|',
map { \$qt_defines[$_] } 0..$#qt_defines).)/o;
$match_qt_defines = eval sub { my \$s=shift;
- \$s=~/^#\\s*if(n)?def/ || return 0;
+ \$s=~/^#\\s*if\\s*([n!])?\s*def(ined\\()?
\\s*QT_/ || return 0;
if(!\$1) { return \$s=~$regexp ? 0:1 }
else { return \$s=~$regexp ? 1:0 }
};
+
die if $@;
I couldn't understand the perl in 2004, and I don't really understand it now.
Certainly lots of people have run kalyptus to build the smoke bindings, and
only dashboard has this error:
Global symbol $qt_defines requires explicit package name at (eval 1) line 4.
Global symbol $qt_defines requires explicit package name at (eval 1) line 4.
Global symbol $qt_defines requires explicit package name at (eval 1) line 4.
...propagated at kdebindings-717467/kalyptus/kalyptus line 227.
make: *** [smoke/plasma/smokedata.cpp] Error 255
make: *** [smoke/plasma/CMakeFiles/smokeplasma.dir/all] Error 2
make: *** [all Error 2
This is the code that is failing:
# Check the %defines hash for QT_* symbols and compile the corresponding RE
# Otherwise, compile the default ones. Used for filtering in readCxxLine.
if ( my @qt_defines = map { ($_=~m/^QT_(.*)/)[0] } keys %defines)
{
my $regexp = m/^#\\s*if\\s*[n!]?\\s*def(ined\\()?\\s*QT_(?: . join('|',
map { \$qt_defines[$_] } 0..$#qt_defines).)/o;
$match_qt_defines = eval sub { my \$s=shift;
\$s=~/^#\\s*if\\s*([n!])?\s*def(ined\\()?
\\s*QT_/ || return 0;
if(!\$1) { return \$s=~$regexp ? 0:1 }
else { return \$s=~$regexp ? 1:0 }
};
die if $@;
}
Would it help to move the 'my @qt_defines' outside the 'if' statement? Without
being able to reproduce the bug, this is impossible to fix for me.
my @qt_defines;
if (@qt_defines = map { ($_=~m/^QT_(.*)/)[0] } keys %defines)
{
-- Richard
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] Questions About the New Schedule
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 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] Questions About the New Schedule
On Monday 01 October 2007, Dirk Mueller wrote: On Monday, 1. October 2007, Cyrille Berger wrote: According to that, it has not build in almost 2 and a half months. Hum right I have disabled plasma, maybe it should be disabled by default. CCing kde-bindings. I have it disabled as well. 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 to a desynchronized copy of qtguess.pl.in), but no result so far. Well it all built for me until Dirk changed the smoke/kde/qtguess.pl.cmake file. 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 for smoke/kde (and smoke/plasma). I find these perl scripts largely unmaintainable and they should all be removed and cmake-only tests used. The Qt build options for building KDE need to be pretty much complete, and we should only need to test for which we are on a Mac, Windows or Linux type build env for the window styles QT_ defines. -- Richard ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDE/kdebindings/smoke
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 mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] Questions About the New Schedule
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 for smoke/kde (and smoke/plasma). ^^^ Wouldn't it be easier to have a single FindQt4 cmake file instead of the *eight* different ones we have now? (http://lists.kde.org/?l=kde-core-develm=119116801902968w=2) What a nightmare! -- Richard ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
