Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-23 Thread Alexander Neundorf 
On Saturday 23 January 2010, Arno Rehn wrote:
> On Friday 22 January 2010 17:52:12 Alexander Neundorf wrote:
> > Also make sure your FindQt4.cmake is current (i.e. at least 1076819).
> >
> > > /usr/lib/libQtCore.so;_linkInterfaceLibs-NOTFOUND;-
> > > lpthread;/usr/lib/libQtDBus.so;_linkInterfaceLibs-
> > > NOTFOUND;/usr/lib/libQtGui.so;_linkInterfaceLibs-
> > > NOTFOUND;/usr/lib/libQtNetwork.so;_linkInterfaceLibs-
> > > NOTFOUND;/usr/lib/libQtOpenGL.so;_linkInterfaceLibs-
> > > NOTFOUND;/usr/lib/libQtXml.so;_linkInterfaceLibs-
> > > NOTFOUND;/usr/lib/libQtSvg.so;_linkInterfaceLibs-NOTFOUND
> > >
> > > I used this:
> > >
> > > include (HandleImportedTargetsInCMakeRequiredLibraries)
> > > set(CMAKE_REQUIRED_INCLUDES ${CMAKE_SYSTEM_INCLUDE_PATH}
> > > ${QT_INCLUDE_DIR}) set(CMAKE_REQUIRED_LIBRARIES ${QT_QTCORE_LIBRARY}
> > > ${QT_QTDBUS_LIBRARY} ${QT_QTGUI_LIBRARY} ${QT_QTNETWORK_LIBRARY}
> > > ${QT_QTOPENGL_LIBRARY} ${QT_QTXML_LIBRARY} ${QT_QTSVG_LIBRARY})
> > > HANDLE_IMPORTED_TARGETS_IN_CMAKE_REQUIRED_LIBRARIES(_CMAKE_REQUIRED_LIB
> > >RA RI ES) message("${_CMAKE_REQUIRED_LIBRARIES}")
> > >
> > > What are linkInterfaceLibs? Wouldn't it be better if they weren't added
> > > to the list if they don't exist?
> >
> > Sure, that's what the patch mentioned above should do.
> > If it doesn't let's fix it.
>
> Ok, the macro works fine now. Next problem is the following:
>
> Linking CXX shared library ../../lib/libsmokekdecore.so
> /usr/bin/ld: cannot find -lQt4__QTDBUS
> collect2: ld returned 1 exit status

You're kdelibs are not current, please update them e.g. to at least rev. 
1076826 from the 4.4 branch.
Let me know if yu then still have this problem (the names of the imported 
targets changed from Qt4__QTFOO to Qt4::QtFoo, this needed to be done before 
4.4.0)

Alex
___
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

2010-01-23 Thread Arno Rehn 
On Friday 22 January 2010 17:52:12 Alexander Neundorf wrote:
> Also make sure your FindQt4.cmake is current (i.e. at least 1076819).
> 
> > /usr/lib/libQtCore.so;_linkInterfaceLibs-NOTFOUND;-
> > lpthread;/usr/lib/libQtDBus.so;_linkInterfaceLibs-
> > NOTFOUND;/usr/lib/libQtGui.so;_linkInterfaceLibs-
> > NOTFOUND;/usr/lib/libQtNetwork.so;_linkInterfaceLibs-
> > NOTFOUND;/usr/lib/libQtOpenGL.so;_linkInterfaceLibs-
> > NOTFOUND;/usr/lib/libQtXml.so;_linkInterfaceLibs-
> > NOTFOUND;/usr/lib/libQtSvg.so;_linkInterfaceLibs-NOTFOUND
> >
> > I used this:
> >
> > include (HandleImportedTargetsInCMakeRequiredLibraries)
> > set(CMAKE_REQUIRED_INCLUDES ${CMAKE_SYSTEM_INCLUDE_PATH}
> > ${QT_INCLUDE_DIR}) set(CMAKE_REQUIRED_LIBRARIES ${QT_QTCORE_LIBRARY}
> > ${QT_QTDBUS_LIBRARY} ${QT_QTGUI_LIBRARY} ${QT_QTNETWORK_LIBRARY}
> > ${QT_QTOPENGL_LIBRARY} ${QT_QTXML_LIBRARY} ${QT_QTSVG_LIBRARY})
> > HANDLE_IMPORTED_TARGETS_IN_CMAKE_REQUIRED_LIBRARIES(_CMAKE_REQUIRED_LIBRA
> >RI ES) message("${_CMAKE_REQUIRED_LIBRARIES}")
> >
> > What are linkInterfaceLibs? Wouldn't it be better if they weren't added
> > to the list if they don't exist?
> 
> Sure, that's what the patch mentioned above should do.
> If it doesn't let's fix it.
Ok, the macro works fine now. Next problem is the following:

Linking CXX shared library ../../lib/libsmokekdecore.so
/usr/bin/ld: cannot find -lQt4__QTDBUS
collect2: ld returned 1 exit status

the cmake code is:
target_link_libraries(smokekdecore
${QT_QTCORE_LIBRARY}
${QT_QTNETWORK_LIBRARY}
${QT_QTDBUS_LIBRARY}
${KDE4_KDECORE_LIBS}
smokeqtcore
smokeqtnetwork
smokeqtdbus
)

If I comment out the KDECORE libs, the above mentioned error goes away and I 
only get a whole lot of undefined reference errors (as was to be expected). So 
I guess FindKDE4Internal.cmake is doing something wrong. I just checked for 
updates, but my cmake macros are up-to-date.

--
Arno Rehn
a...@arnorehn.de
___
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

2010-01-22 Thread Alexander Neundorf 
On Friday 22 January 2010, Arno Rehn wrote:
> On Thursday 21 January 2010 23:31:32 Alexander Neundorf wrote:
> > On Thursday 21 January 2010, Arno Rehn wrote:
> > > On Thursday 21 January 2010 22:50:55 Alexander Neundorf wrote:
> >
> > ...
> >
> > > >  HandleImportedTargetsInCMakeRequiredLibraries.cmake, which doesn't
> > > > depend on any other additional KDE-specific cmake modules.
> > >
> > > I didn't try them because I thought they probably suffer from the same
> > > bug. Since I also was too lazy to look at their code, I didn't
> > > recognize that they work around it.
> > > Now that it doesn't seem to be a problem for the macros, I think we'll
> > > go with CheckCXXSourceCompiles.cmake.
> >
> > Let me know (tomorrow) if it doesn't work.
>
> So I just tried to make it work with
> HandleImportedTargetsInCMakeRequiredLibraries only. It fails with many of
> the following errors:
>
> CMake Error: The following variables are used in this project, but they are
> set to NOTFOUND.
> Please set them or make sure they are set and tested correctly in the CMake
> files:
> _linkInterfaceLibs
> linked by target "cmTryCompileExec" in directory
> /home/pumphaus/dev/KDE/kdebindings-build2/smoke/qt/test-
> QT_NO_DEBUG/CMakeFiles/CMakeTmp

Is this with a current HandleImportedTargetsInCMakeRequiredLibraries.cmake 
i.e. at least 1073213 ? This commit on January 11th should have fixed that.
http://websvn.kde.org/?view=revision&revision=1073213


Also make sure your FindQt4.cmake is current (i.e. at least 1076819).

> /usr/lib/libQtCore.so;_linkInterfaceLibs-NOTFOUND;-
> lpthread;/usr/lib/libQtDBus.so;_linkInterfaceLibs-
> NOTFOUND;/usr/lib/libQtGui.so;_linkInterfaceLibs-
> NOTFOUND;/usr/lib/libQtNetwork.so;_linkInterfaceLibs-
> NOTFOUND;/usr/lib/libQtOpenGL.so;_linkInterfaceLibs-
> NOTFOUND;/usr/lib/libQtXml.so;_linkInterfaceLibs-
> NOTFOUND;/usr/lib/libQtSvg.so;_linkInterfaceLibs-NOTFOUND
>
> I used this:
>
> include (HandleImportedTargetsInCMakeRequiredLibraries)
> set(CMAKE_REQUIRED_INCLUDES ${CMAKE_SYSTEM_INCLUDE_PATH} ${QT_INCLUDE_DIR})
> set(CMAKE_REQUIRED_LIBRARIES ${QT_QTCORE_LIBRARY} ${QT_QTDBUS_LIBRARY}
> ${QT_QTGUI_LIBRARY} ${QT_QTNETWORK_LIBRARY} ${QT_QTOPENGL_LIBRARY}
> ${QT_QTXML_LIBRARY} ${QT_QTSVG_LIBRARY})
> HANDLE_IMPORTED_TARGETS_IN_CMAKE_REQUIRED_LIBRARIES(_CMAKE_REQUIRED_LIBRARI
>ES) message("${_CMAKE_REQUIRED_LIBRARIES}")
>
> What are linkInterfaceLibs? Wouldn't it be better if they weren't added to
> the list if they don't exist?

Sure, that's what the patch mentioned above should do.
If it doesn't let's fix it.

Alex
___
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

2010-01-22 Thread Arno Rehn 
On Thursday 21 January 2010 23:31:32 Alexander Neundorf wrote:
> On Thursday 21 January 2010, Arno Rehn wrote:
> > On Thursday 21 January 2010 22:50:55 Alexander Neundorf wrote:
> 
> ...
> 
> > >  HandleImportedTargetsInCMakeRequiredLibraries.cmake, which doesn't
> > > depend on any other additional KDE-specific cmake modules.
> >
> > I didn't try them because I thought they probably suffer from the same
> > bug. Since I also was too lazy to look at their code, I didn't recognize
> > that they work around it.
> > Now that it doesn't seem to be a problem for the macros, I think we'll go
> > with CheckCXXSourceCompiles.cmake.
> 
> Let me know (tomorrow) if it doesn't work.
So I just tried to make it work with 
HandleImportedTargetsInCMakeRequiredLibraries only. It fails with many of the 
following errors:

CMake Error: The following variables are used in this project, but they are 
set to NOTFOUND.
   
Please set them or make sure they are set and tested correctly in the CMake 
files:  
   
_linkInterfaceLibs  

   
linked by target "cmTryCompileExec" in directory 
/home/pumphaus/dev/KDE/kdebindings-build2/smoke/qt/test-
QT_NO_DEBUG/CMakeFiles/CMakeTmp

The macro writes the following to the result variable:

/usr/lib/libQtCore.so;_linkInterfaceLibs-NOTFOUND;-
lpthread;/usr/lib/libQtDBus.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtGui.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtNetwork.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtOpenGL.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtXml.so;_linkInterfaceLibs-
NOTFOUND;/usr/lib/libQtSvg.so;_linkInterfaceLibs-NOTFOUND

I used this:

include (HandleImportedTargetsInCMakeRequiredLibraries)
set(CMAKE_REQUIRED_INCLUDES ${CMAKE_SYSTEM_INCLUDE_PATH} ${QT_INCLUDE_DIR})
set(CMAKE_REQUIRED_LIBRARIES ${QT_QTCORE_LIBRARY} ${QT_QTDBUS_LIBRARY} 
${QT_QTGUI_LIBRARY} ${QT_QTNETWORK_LIBRARY} ${QT_QTOPENGL_LIBRARY} 
${QT_QTXML_LIBRARY} ${QT_QTSVG_LIBRARY})
HANDLE_IMPORTED_TARGETS_IN_CMAKE_REQUIRED_LIBRARIES(_CMAKE_REQUIRED_LIBRARIES)
message("${_CMAKE_REQUIRED_LIBRARIES}")

What are linkInterfaceLibs? Wouldn't it be better if they weren't added to the 
list if they don't exist?

-- 
Arno Rehn
a...@arnorehn.de
___
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

2010-01-21 Thread Alexander Neundorf 
On Thursday 21 January 2010, Arno Rehn wrote:
> On Thursday 21 January 2010 22:50:55 Alexander Neundorf wrote:
...
> >  HandleImportedTargetsInCMakeRequiredLibraries.cmake, which doesn't
> > depend on any other additional KDE-specific cmake modules.
>
> I didn't try them because I thought they probably suffer from the same bug.
> Since I also was too lazy to look at their code, I didn't recognize that
> they work around it.
> Now that it doesn't seem to be a problem for the macros, I think we'll go
> with CheckCXXSourceCompiles.cmake.

Let me know (tomorrow) if it doesn't work.

> > Also, I actually would be happy if you could file this as a bug report in
> >  the cmake bugtracker (http://public.kitware.com/Bugs) that try_compile()
> >  doesn't handle imported targets.
>
> You've already done that yourself, nearly one year ago ;)
> http://public.kitware.com/Bug/view.php?id=8761

Oh, indeed. I remembered that discussion but I thought it was via email.

> The bug's still open, though.

Yes, I know. Feel free to add a comment in the bug report.

Alex

___
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

2010-01-21 Thread Arno Rehn 
On Thursday 21 January 2010 22:50:55 Alexander Neundorf wrote:
> On Thursday 21 January 2010, Arno Rehn wrote:
> ...
> 
> > Sorry, I was a bit busy in the last two weeks.
> >
> > After doing a clean build I saw that the QtGuess.txt file returned
> > "[defined]" for every QT_NO_FOO define, i.e. that compilation failed for
> > every test (so it also defines QT_NO_PRINTDIALOG, even though that's
> > wrong).
> >
> > Digging through the cmake files, I found that FindQt4.cmake was changed
> > between KDE 4.3 and 4.4. It now uses aliases for the Qt4 libs by
> > importing them as targets (as Qt4__QTCORE, Qt4_QTGUI, etc.).
> >
> > Unfortunately, this completely screws QtGuess.txt, because TRY_COMPILE
> > (built- in cmake command) can't handle imported targets. We can only use
> > normal paths here. A workaround would be to resolve all imported targets,
> > but that doesn't seem like the perfect solution to me.
> >
> > I'm CC'ing Alexander Neundorf, as he seems to be the guy who implemented
> > the imported targets.
> 
> If there are problems with building, don't hesitate to send a mail to
> kde-buildsys...@kde.org.
> I'd say this is usually a better idea for build problems than kde-packager
>  or kde-release-team.
> 
> > Alexander, can you shed some light on why this was
> > done and how to solve this issue best?
> 
> On demand of developers.
> We have our own copy of FindQt4.cmake, which with the time went relatively
>  far away from the shipping with CMake.
> 
> We had several issues there.
> Developers complained that our FindQt4.cmake didn't have all the features
>  of the one shipping with cmake (some libs not supported etc.).
> Our FindQt4.cmake was not working properly with Qt as frameworks on OSX.
> There was a lot of unnecessary special casing for Windows in our copy.
> Getting too faw away from each other also means that we might become
> incompatible, which also breaks applications.
> 
> So I took the time and merged most of the changes from both side into each
> other. Which also meant to always check for both release and debug
>  versions. This lead to the effect that QT_QTFOO_LIBRARY now could be
>  "optimized libQtFoo.so debug libQtFood.so".
> 
> Now this change broke some places.
> This way of specifying which lib is for release builds and which is for
>  debug builds is not good (which build types are considered debug, which
> optimized ?) and is syntax-wise also a hack (from the POV of the cmake
>  devs).
> 
> So, what is the best way to fix this.
> It's to introduce imported targets for the various Qt libraries.
> Then there exist library targets, which can be referenced. They can be
> assigned different locations (file paths) for different buildtypes.
> Dependencies can be tracked.
Ah yes, I see.

> I tried to get this in as compatible as possible, there cannot be much left
> now.
> 
> Why are you using TRY_COMPILE() directly ? This is quite low-level, and I
> would always advice against it directly.
> There are the check_cxx_source_compiles() and check_cxx_source_runs()
>  macros installed with kdelibs (CheckCXXSourceCompiles.cmake and
> CheckCXXSourceRuns.cmake), which both handle imported targets.
>
> What is speaking against using these macros ?
> Both do check if a library is an imported target and if so retrieve the
>  path, this is implemented in
>  HandleImportedTargetsInCMakeRequiredLibraries.cmake, which doesn't depend
>  on any other additional KDE-specific cmake modules.
I didn't try them because I thought they probably suffer from the same bug. 
Since I also was too lazy to look at their code, I didn't recognize that they 
work around it.
Now that it doesn't seem to be a problem for the macros, I think we'll go with 
CheckCXXSourceCompiles.cmake.

> Also, I actually would be happy if you could file this as a bug report in
>  the cmake bugtracker (http://public.kitware.com/Bugs) that try_compile()
>  doesn't handle imported targets.
You've already done that yourself, nearly one year ago ;) 
http://public.kitware.com/Bug/view.php?id=8761
The bug's still open, though.

-- 
Arno Rehn
a...@arnorehn.de
___
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

2010-01-21 Thread Alexander Neundorf 
On Thursday 21 January 2010, Arno Rehn wrote:
...
> Sorry, I was a bit busy in the last two weeks.
>
> After doing a clean build I saw that the QtGuess.txt file returned
> "[defined]" for every QT_NO_FOO define, i.e. that compilation failed for
> every test (so it also defines QT_NO_PRINTDIALOG, even though that's
> wrong).
>
> Digging through the cmake files, I found that FindQt4.cmake was changed
> between KDE 4.3 and 4.4. It now uses aliases for the Qt4 libs by importing
> them as targets (as Qt4__QTCORE, Qt4_QTGUI, etc.).
>
> Unfortunately, this completely screws QtGuess.txt, because TRY_COMPILE
> (built- in cmake command) can't handle imported targets. We can only use
> normal paths here. A workaround would be to resolve all imported targets,
> but that doesn't seem like the perfect solution to me.
>
> I'm CC'ing Alexander Neundorf, as he seems to be the guy who implemented
> the imported targets. 

If there are problems with building, don't hesitate to send a mail to 
kde-buildsys...@kde.org.
I'd say this is usually a better idea for build problems than kde-packager or 
kde-release-team.

> Alexander, can you shed some light on why this was
> done and how to solve this issue best?

On demand of developers.
We have our own copy of FindQt4.cmake, which with the time went relatively far 
away from the shipping with CMake.

We had several issues there.
Developers complained that our FindQt4.cmake didn't have all the features of 
the one shipping with cmake (some libs not supported etc.).
Our FindQt4.cmake was not working properly with Qt as frameworks on OSX.
There was a lot of unnecessary special casing for Windows in our copy.
Getting too faw away from each other also means that we might become 
incompatible, which also breaks applications.

So I took the time and merged most of the changes from both side into each 
other. Which also meant to always check for both release and debug versions. 
This lead to the effect that QT_QTFOO_LIBRARY now could be "optimized 
libQtFoo.so debug libQtFood.so".

Now this change broke some places.
This way of specifying which lib is for release builds and which is for debug 
builds is not good (which build types are considered debug, which 
optimized ?) and is syntax-wise also a hack (from the POV of the cmake devs).

So, what is the best way to fix this.
It's to introduce imported targets for the various Qt libraries. 
Then there exist library targets, which can be referenced. They can be 
assigned different locations (file paths) for different buildtypes. 
Dependencies can be tracked.

I tried to get this in as compatible as possible, there cannot be much left 
now.

Why are you using TRY_COMPILE() directly ? This is quite low-level, and I 
would always advice against it directly.
There are the check_cxx_source_compiles() and check_cxx_source_runs() macros 
installed with kdelibs (CheckCXXSourceCompiles.cmake and 
CheckCXXSourceRuns.cmake), which both handle imported targets.

What is speaking against using these macros ?
Both do check if a library is an imported target and if so retrieve the path, 
this is implemented in HandleImportedTargetsInCMakeRequiredLibraries.cmake, 
which doesn't depend on any other additional KDE-specific cmake modules.

Also, I actually would be happy if you could file this as a bug report in the 
cmake bugtracker (http://public.kitware.com/Bugs) that try_compile() doesn't 
handle imported targets.

Alex
___
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

2010-01-21 Thread Arno Rehn 
On Thursday 21 January 2010 14:13:27 Richard Dale wrote:
> 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.
Sorry, I was a bit busy in the last two weeks.

After doing a clean build I saw that the QtGuess.txt file returned "[defined]" 
for every QT_NO_FOO define, i.e. that compilation failed for every test (so it 
also defines QT_NO_PRINTDIALOG, even though that's wrong).

Digging through the cmake files, I found that FindQt4.cmake was changed 
between KDE 4.3 and 4.4. It now uses aliases for the Qt4 libs by importing 
them as targets (as Qt4__QTCORE, Qt4_QTGUI, etc.).

Unfortunately, this completely screws QtGuess.txt, because TRY_COMPILE (built-
in cmake command) can't handle imported targets. We can only use normal paths 
here. A workaround would be to resolve all imported targets, but that doesn't 
seem like the perfect solution to me.

I'm CC'ing Alexander Neundorf, as he seems to be the guy who implemented the 
imported targets. Alexander, can you shed some light on why this was done and 
how to solve this issue best?

-- 
Arno Rehn
a...@arnorehn.de
___
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

2010-01-21 Thread Maciej Mrozowski 
On Thursday 21 of January 2010 12:22:43 Richard Dale wrote:

> 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.

Not to mention that 4.4 branch actually suffers from the fact it's being 
created so early as not everyone is willing to backport all changes from trunk 
(and some changes cannot be backported) which means some developers are 
already commited to work in trunk in many cases while 4.4 is not even released 
yet.

-- 
regards
MM
___
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

2010-01-21 Thread Richard Dale 
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] KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-21 Thread Dirk Mueller 
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. 

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. 

Thanks,
Dirk
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-21 Thread Eric Hameleers 
On Wed, 20 Jan 2010, Eric Hameleers wrote:

> Date: Wed, 20 Jan 2010 08:30:10 -0800 (PST)
> From: Eric Hameleers 
> To: Dirk Mueller 
> Cc: kde-bindi...@kde.org, kde-packa...@kde.org,
> Simon Edwards ,
> KDE release coordination 
> Subject: Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded
> 
> On Wed, 20 Jan 2010, 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?
>>
>> with RC2, there is a new problem:
>>
>> /usr/bin/cmake -E cmake_progress_report kdebindings-1077263/build/CMakeFiles
>> Building CXX object smoke/qt/CMakeFiles/smokeqt.dir/x_1.o
>> cd kdebindings-1077263/build/smoke/qt && /usr/bin/c++ -Dsmokeqt_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 -DBASE_SMOKE_BUILDING -O2 -march=i586 -
>> mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -
>> funwind-tables -fasynchronous-unwind-tables -Werror=format-security 
>> -Wmissing-
>> format-attribute -Werror=return-type -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 -g -O2 -fno-reorder-blocks -fno-schedule-insns -fno-inline -
>> fPIC -Ikdebindings-1077263/build/smoke/qt -Ikdebindings-1077263/smoke/qt -
>> Ikdebindings-1077263 -Ikdebindings-1077263/build -Ikdebindings-1077263/smoke 
>> -
>> Iinclude -Iinclude/KDE -I/usr/include/KDE -I/usr/include/QtXmlPatterns -
>> I/usr/include/QtXml -I/usr/include/QtWebKit -I/usr/include/QtUiTools -
>> I/usr/include/QtTest -I/usr/include/QtSvg -I/usr/include/QtSql -
>> I/usr/include/QtScriptTools -I/usr/include/QtScript -I/usr/include/QtOpenGL -
>> I/usr/include/QtNetwork -I/usr/include/QtMultimedia -I/usr/include/QtHelp -
>> I/usr/include/QtDesigner -I/usr/include/QtDBus -I/usr/include/QtAssistant -
>> I/usr/include/Qt3Support -I/usr/include/QtGui -I/usr/include/QtCore -
>> I/usr/include/Qt -I/usr/share/qt4/mkspecs/default -D_GNU_SOURCE -
>> D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -o CMakeFiles/smokeqt.dir/x_1.o 
>> -c
>> kdebindings-1077263/build/smoke/qt/x_1.cpp
>> kdebindings-1077263/build/smoke/qt/x_1.cpp: In static member function 'static
>> void __smokeqt::x_QAbstractPrintDialog::x_8(Smoke::StackItem*)':
>> kdebindings-1077263/build/smoke/qt/x_1.cpp:4175: error: cannot allocate an
>> object of abstract type '__smokeqt::x_QAbstractPrintDialog'
>> kdebindings-1077263/build/smoke/qt/x_1.cpp:4131: note: because the following
>> virtual functions are pure within '__smokeqt::x_QAbstractPrintDialog':
>> /usr/include/QtGui/qabstractprintdialog.h:87: note: virtual int
>> QAbstractPrintDialog::exec()
>> kdebindings-1077263/build/smoke/qt/x_1.cpp: In constructor
>> '__smokeqt::x_QAbstractPrintDialog::x_QAbstractPrintDialog()':
>> kdebindings-1077263/build/smoke/qt/x_1.cpp:4178: error: no matching function
>> for call to 'QAbstractPrintDialog::QAbstractPrintDialog()'
>> /usr/include/QtGui/qabstractprintdialog.h:114: note: candidates are:
>> QAbstractPrintDialog::QAbstractPrintDialog(const QAbstractPrintDialog&)
>> /usr/include/QtGui/qabstractprintdialog.h:111: note:
>> QAbstractPrintDialog::QAbstractPrintDialog(QAbstractPrintDialogPrivate&,
>> QPrinter*, QWidget*)
>> /usr/include/QtGui/qabstractprintdialog.h:84: note:
>> QAbstractPrintDialog::QAbstractPrintDialog(QPrinter*, QWidget*)
>>
>> What is the solution here?
>>
>> Thanks,
>> Dirk
>
> I want to add that I got these errors with sip-4.10 and PyQt-4.7
> installed, i.e. these are not the snapshot versions which were
> available for RC1.

Dirk

Your commit 1077826 solved the above issue, but this is the next error 
I get in compiling kdebindings:

parsing 
"/tmp/kdebindings-4.3.95/smoke/qimageblitz/qimageblitz_includes.h"
Generating SMOKE sources...
preparing SMOKE data [qimageblitz]
writing out smokedata.cpp [qimageblit

Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-21 Thread Tom Albers 
Op Thursday 21 January 2010 12:22 schreef u:
> 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. 

Can you send me an email with how the release schedule should be adapted in 
your opinion? When I create the 4.5 schedule I can incorporate your wishes - if 
possible of course..

Best,

Toma___
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

2010-01-21 Thread Richard Dale 
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 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-20 Thread Tom Albers 
Op Wednesday 20 January 2010 20:17 schreef u:
> 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'ld rather use my.cdash.org's nightly builds and make the module maintainer 
responsible to keep it green at all times during rc phase and simply revert 
offending commits.

Toma
-- 
KDE Developer___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-20 Thread Simon Edwards 
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.

cheers,

-- 
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."
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-20 Thread Eric Hameleers 
On Wed, 20 Jan 2010, 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?
>
> with RC2, there is a new problem:
>
> /usr/bin/cmake -E cmake_progress_report kdebindings-1077263/build/CMakeFiles
> Building CXX object smoke/qt/CMakeFiles/smokeqt.dir/x_1.o
> cd kdebindings-1077263/build/smoke/qt && /usr/bin/c++ -Dsmokeqt_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 -DBASE_SMOKE_BUILDING -O2 -march=i586 -
> mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -
> funwind-tables -fasynchronous-unwind-tables -Werror=format-security -Wmissing-
> format-attribute -Werror=return-type -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 -g -O2 -fno-reorder-blocks -fno-schedule-insns -fno-inline -
> fPIC -Ikdebindings-1077263/build/smoke/qt -Ikdebindings-1077263/smoke/qt -
> Ikdebindings-1077263 -Ikdebindings-1077263/build -Ikdebindings-1077263/smoke -
> Iinclude -Iinclude/KDE -I/usr/include/KDE -I/usr/include/QtXmlPatterns -
> I/usr/include/QtXml -I/usr/include/QtWebKit -I/usr/include/QtUiTools -
> I/usr/include/QtTest -I/usr/include/QtSvg -I/usr/include/QtSql -
> I/usr/include/QtScriptTools -I/usr/include/QtScript -I/usr/include/QtOpenGL -
> I/usr/include/QtNetwork -I/usr/include/QtMultimedia -I/usr/include/QtHelp -
> I/usr/include/QtDesigner -I/usr/include/QtDBus -I/usr/include/QtAssistant -
> I/usr/include/Qt3Support -I/usr/include/QtGui -I/usr/include/QtCore -
> I/usr/include/Qt -I/usr/share/qt4/mkspecs/default -D_GNU_SOURCE -
> D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -o CMakeFiles/smokeqt.dir/x_1.o -c
> kdebindings-1077263/build/smoke/qt/x_1.cpp
> kdebindings-1077263/build/smoke/qt/x_1.cpp: In static member function 'static
> void __smokeqt::x_QAbstractPrintDialog::x_8(Smoke::StackItem*)':
> kdebindings-1077263/build/smoke/qt/x_1.cpp:4175: error: cannot allocate an
> object of abstract type '__smokeqt::x_QAbstractPrintDialog'
> kdebindings-1077263/build/smoke/qt/x_1.cpp:4131: note: because the following
> virtual functions are pure within '__smokeqt::x_QAbstractPrintDialog':
> /usr/include/QtGui/qabstractprintdialog.h:87: note: virtual int
> QAbstractPrintDialog::exec()
> kdebindings-1077263/build/smoke/qt/x_1.cpp: In constructor
> '__smokeqt::x_QAbstractPrintDialog::x_QAbstractPrintDialog()':
> kdebindings-1077263/build/smoke/qt/x_1.cpp:4178: error: no matching function
> for call to 'QAbstractPrintDialog::QAbstractPrintDialog()'
> /usr/include/QtGui/qabstractprintdialog.h:114: note: candidates are:
> QAbstractPrintDialog::QAbstractPrintDialog(const QAbstractPrintDialog&)
> /usr/include/QtGui/qabstractprintdialog.h:111: note:
> QAbstractPrintDialog::QAbstractPrintDialog(QAbstractPrintDialogPrivate&,
> QPrinter*, QWidget*)
> /usr/include/QtGui/qabstractprintdialog.h:84: note:
> QAbstractPrintDialog::QAbstractPrintDialog(QPrinter*, QWidget*)
>
> What is the solution here?
>
> Thanks,
> Dirk

I want to add that I got these errors with sip-4.10 and PyQt-4.7 
installed, i.e. these are not the snapshot versions which were 
available for RC1.

Cheers, Eric

-- 
Eric Hameleers 
Jabber: al...@jabber.xs4all.nl


___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-20 Thread Dirk Mueller 
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?

with RC2, there is a new problem: 

/usr/bin/cmake -E cmake_progress_report kdebindings-1077263/build/CMakeFiles
Building CXX object smoke/qt/CMakeFiles/smokeqt.dir/x_1.o
cd kdebindings-1077263/build/smoke/qt && /usr/bin/c++ -Dsmokeqt_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 -DBASE_SMOKE_BUILDING -O2 -march=i586 -
mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -
funwind-tables -fasynchronous-unwind-tables -Werror=format-security -Wmissing-
format-attribute -Werror=return-type -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 -g -O2 -fno-reorder-blocks -fno-schedule-insns -fno-inline -
fPIC -Ikdebindings-1077263/build/smoke/qt -Ikdebindings-1077263/smoke/qt -
Ikdebindings-1077263 -Ikdebindings-1077263/build -Ikdebindings-1077263/smoke -
Iinclude -Iinclude/KDE -I/usr/include/KDE -I/usr/include/QtXmlPatterns -
I/usr/include/QtXml -I/usr/include/QtWebKit -I/usr/include/QtUiTools -
I/usr/include/QtTest -I/usr/include/QtSvg -I/usr/include/QtSql -
I/usr/include/QtScriptTools -I/usr/include/QtScript -I/usr/include/QtOpenGL -
I/usr/include/QtNetwork -I/usr/include/QtMultimedia -I/usr/include/QtHelp -
I/usr/include/QtDesigner -I/usr/include/QtDBus -I/usr/include/QtAssistant -
I/usr/include/Qt3Support -I/usr/include/QtGui -I/usr/include/QtCore -
I/usr/include/Qt -I/usr/share/qt4/mkspecs/default -D_GNU_SOURCE -
D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -o CMakeFiles/smokeqt.dir/x_1.o -c 
kdebindings-1077263/build/smoke/qt/x_1.cpp
kdebindings-1077263/build/smoke/qt/x_1.cpp: In static member function 'static 
void __smokeqt::x_QAbstractPrintDialog::x_8(Smoke::StackItem*)':
kdebindings-1077263/build/smoke/qt/x_1.cpp:4175: error: cannot allocate an 
object of abstract type '__smokeqt::x_QAbstractPrintDialog'
kdebindings-1077263/build/smoke/qt/x_1.cpp:4131: note: because the following 
virtual functions are pure within '__smokeqt::x_QAbstractPrintDialog':
/usr/include/QtGui/qabstractprintdialog.h:87: note: virtual int 
QAbstractPrintDialog::exec()
kdebindings-1077263/build/smoke/qt/x_1.cpp: In constructor 
'__smokeqt::x_QAbstractPrintDialog::x_QAbstractPrintDialog()':
kdebindings-1077263/build/smoke/qt/x_1.cpp:4178: error: no matching function 
for call to 'QAbstractPrintDialog::QAbstractPrintDialog()'
/usr/include/QtGui/qabstractprintdialog.h:114: note: candidates are: 
QAbstractPrintDialog::QAbstractPrintDialog(const QAbstractPrintDialog&)
/usr/include/QtGui/qabstractprintdialog.h:111: note: 
QAbstractPrintDialog::QAbstractPrintDialog(QAbstractPrintDialogPrivate&, 
QPrinter*, QWidget*)
/usr/include/QtGui/qabstractprintdialog.h:84: note: 
QAbstractPrintDialog::QAbstractPrintDialog(QPrinter*, QWidget*)

What is the solution here?

Thanks,
Dirk
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Eric Hameleers 
On Thu, 7 Jan 2010, Dirk Mueller wrote:

> Can anybody else confirm that it builds? I would release the tarballs then.
>
> Greetings,
> Dirk

I have the following build error in kdebase after having built 
kdelibs and kdepimlibs:

[ 74%] Building CXX object 
apps/konqueror/sidebar/trees/CMakeFiles/konqsidebar_tree.dir/konqsidebar_tree_final_cpp.o
In file included from 
/tmp/kdebase-4.3.90/apps/konqueror/sidebar/module_manager.cpp:21,
  from 
/tmp/kdebase-4.3.90/build/apps/konqueror/sidebar/konq_sidebar_final_cpp.cpp:4:
/tmp/kdebase-4.3.90/apps/konqueror/sidebar/module_manager.h:31: error: 
redefinition of 'class ModuleManager'
/tmp/kdebase-4.3.90/apps/konqueror/sidebar/module_manager.h:32: error: 
previous definition of 'class ModuleManager'
[ 75%] Building CXX object 
apps/keditbookmarks/CMakeFiles/kdeinit_keditbookmarks.dir/settings.o
In file included from 
/tmp/kdebase-4.3.90/build/apps/konqueror/sidebar/trees/konqsidebar_tree_final_cpp.cpp:3:
/tmp/kdebase-4.3.90/apps/konqueror/sidebar/trees/konq_sidebartree.cpp:497:2: 
warning: #warning TODO port to QDrag (only possible once porting away 
from Q3ListView?)
make[2]: *** 
[apps/konqueror/sidebar/CMakeFiles/konq_sidebar.dir/konq_sidebar_final_cpp.o] 
Error 1
make[1]: *** [apps/konqueror/sidebar/CMakeFiles/konq_sidebar.dir/all] 
Error 2
make[1]: *** Waiting for unfinished jobs


Cheers, Eric

-- 
Eric Hameleers 
Jabber: al...@jabber.xs4all.nl
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Eric Hameleers 
On Thu, 7 Jan 2010, Lubos Lunak wrote:

> On Thursday 07 of January 2010, Eric Hameleers wrote:
>> I have the following build error in kdebase after having built
>> kdelibs and kdepimlibs:
>>
>> [ 74%] Building CXX object
>> apps/konqueror/sidebar/trees/CMakeFiles/konqsidebar_tree.dir/konqsidebar_tr
>> ee_final_cpp.o In file included from
>> /tmp/kdebase-4.3.90/apps/konqueror/sidebar/module_manager.cpp:21,
>>   from
>> /tmp/kdebase-4.3.90/build/apps/konqueror/sidebar/konq_sidebar_final_cpp.cpp
>> :4: /tmp/kdebase-4.3.90/apps/konqueror/sidebar/module_manager.h:31: error:
>> redefinition of 'class ModuleManager'
>> /tmp/kdebase-4.3.90/apps/konqueror/sidebar/module_manager.h:32: error:
>> previous definition of 'class ModuleManager'
>
> Oh, somebody else uses final build mode too :) ? I've fixed this in SVN, but
> I don't think final build failures have even been blockers for tarball
> release (I'd guess there's a number such failures nowadays). Just build it
> normally or get r1071282 from SVN.

I used your diff 
(http://websvn.kde.org/trunk/KDE/kdebase/apps/konqueror/sidebar/module_manager.h?r1=1048689&r2=1071281&view=patch)
 
and now kdebase builds fine, thanks Lubos.

Cheers, Eric

-- 
Eric Hameleers 
Jabber: al...@jabber.xs4all.nl
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Andrea Scarpino 
2010/1/7 Dirk Mueller :
> while I had the problem originally, after updating to 4.4 kdebase/workspace it
> builds fine for me.
But kdebase-workspace requires kdebindings-python to enable KDE Python
support, if your solution work, one needs to build kdebase-workspace
twice??

-- 
Andrea `bash` Scarpino
Arch Linux Developer
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Eric Hameleers 

On Thu, 7 Jan 2010, Christophe Giboudeaux wrote:


On Thursday 07 January 2010 14:28:22 Eric Hameleers wrote:


Here, kdelibs 4.3.90 fails to find shared-desktop-ontologies. The
4.3.85 tarball did not have any problem finding and using
shared-desktop-ontologies.
The shared-desktop-ontologies which I have installed has not changed
at all in the meantime (this is v0.2).

I see that kdelibs/cmake/modules/FindSharedDesktopOntologies.cmake has
changed since, to make v 0.2 a requirement (the previous version
would just use /usr/share/ontologies as a fallback which is indeed
correct)


Well, no, this wasn't correct. When SDO 0.2 wasn't found, CMake was indeed
looking in /usr/share/ontologies and was setting SDO_FOUND = true even if the
required version didn't match the one installed.


but I do not understand why cmake does not find my installed
SDO 0.2. I have
/usr/share/cmake/SharedDesktopOntologies/SharedDesktopOntologiesConfig.cmak
e with this content:


The only reason I see is the CMake version.
cmake < 2.6.3 will only look in $prefix/share/SharedDesktopOntologies/cmake/.
Any higher version will also look in
$prefix/share/cmake/SharedDesktopOntologies/

Christophe.


Indeed, and as  Sebastian Kügler also suggested, cmake was too old, 
being 2.6.2 here. With cmake 2.8.0, SDO was found alright.


My suggestion would be to force the cmake version in building KDE 4.4 
to be at least 2.6.3.


Cheers, Eric

--
Eric Hameleers 
Jabber: al...@jabber.xs4all.nl___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Eric Hameleers 
On Thu, 7 Jan 2010, Dirk Mueller wrote:

> On Thursday 07 January 2010, Eric Hameleers wrote:
>
>> SDO 0.2. I have
>> /usr/share/cmake/SharedDesktopOntologies/SharedDesktopOntologiesConfig.cmak
>> e with this content:
>
> you need
> /usr/share/cmake/SharedDesktopOntologies/SharedDesktopOntologiesConfigVersion.cmake
>
> as well, this is installed by my package here.
>
> Greetings,
> Dirk

Yeah I have that too, it can not be the problem. But I am going to try 
updating the cmake and see if that helps. My current cmake is 2.6.2 
which may be too old.

Cheers, Eric

-- 
Eric Hameleers 
Jabber: al...@jabber.xs4all.nl
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Lubos Lunak 
On Thursday 07 of January 2010, Eric Hameleers wrote:
> I have the following build error in kdebase after having built
> kdelibs and kdepimlibs:
>
> [ 74%] Building CXX object
> apps/konqueror/sidebar/trees/CMakeFiles/konqsidebar_tree.dir/konqsidebar_tr
>ee_final_cpp.o In file included from
> /tmp/kdebase-4.3.90/apps/konqueror/sidebar/module_manager.cpp:21,
>   from
> /tmp/kdebase-4.3.90/build/apps/konqueror/sidebar/konq_sidebar_final_cpp.cpp
>:4: /tmp/kdebase-4.3.90/apps/konqueror/sidebar/module_manager.h:31: error:
> redefinition of 'class ModuleManager'
> /tmp/kdebase-4.3.90/apps/konqueror/sidebar/module_manager.h:32: error:
> previous definition of 'class ModuleManager'

 Oh, somebody else uses final build mode too :) ? I've fixed this in SVN, but 
I don't think final build failures have even been blockers for tarball 
release (I'd guess there's a number such failures nowadays). Just build it 
normally or get r1071282 from SVN.

-- 
 Lubos Lunak
 openSUSE Boosters team, KDE developer
 l.lu...@suse.cz , l.lu...@kde.org
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Simon Edwards 
Hello,

Rex Dieter wrote:
> Simon Edwards wrote:
>>> Hi, kdebindings fails to build here:
>> A new stable release of PyQt is imminent, then can I up the version 
>> check in CMakeLists.txt. Sorry for the inconvenience guys.
> 
> As I just commented in kde-bindings, the newer sip release appears to be 
> binary incompatible (ie, 4.9.x had SIP_API_MAJOR 6, and 4.10 has 
> SIP_API_MAJOR 7), so requires a rebuild of all things using sip. :( 
> (unless I'm missing something).

Yes that is true. The SIP binary API changes quite often, and requires 
that PyQt & PyKDE be recompiled against the new version.

cheers,

-- 
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."
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Rex Dieter 
Rex Dieter wrote:
> Simon Edwards wrote:
>> Andrea Scarpino wrote:
>>> 2010/1/6 Dirk Mueller :
 I just finished the first set of 4.3.90 (KDE 4.4 RC1) tarballs and uploaded
 them. kde-l10n still takes a few more hours, I'll upload them later.

 Please let me know of any urgent issues, we'd like to release this asap.
>>> Hi, kdebindings fails to build here:
>>>
>>> Linking CXX shared library ../../lib/pykde/phonon.so
>>> [ 83%] Built target python_module_PyKDE4_phonon
>>> [ 84%] Generating sip/plasma/sipplasmapart0.cpp,
>>> sip/plasma/sipplasmapart1.cpp, sip/plasma/sipplasmapart2.cpp,
>>> sip/plasma/sipplasmapart3.cpp, sip/plasma/sipplasmapart4.cpp,
>>> sip/plasma/sipplasmapart5.cpp, sip/plasma/sipplasmapart6.cpp,
>>> sip/plasma/sipplasmapart7.cpp
>>> sip: QAbstractAnimation has not been defined
>>> make[2]: *** [python/pykde4/sip/plasma/sipplasmapart0.cpp] Error 1
>>> make[1]: *** [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.
> 
> Thanks, I'm testing that out myself now.

Confirmed, all builds well (for me on fedora 12 anyway) against latest 
sip/PyQt4 snapshots (I tested sip-4.10-snapshot-20100102 and 
PyQt-x11-gpl-4.7-snapshot-20091231 ).

-- Rex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Rex Dieter 
Simon Edwards wrote:
> Andrea Scarpino wrote:
>> 2010/1/6 Dirk Mueller :
>>> I just finished the first set of 4.3.90 (KDE 4.4 RC1) tarballs and uploaded
>>> them. kde-l10n still takes a few more hours, I'll upload them later.
>>>
>>> Please let me know of any urgent issues, we'd like to release this asap.
>> Hi, kdebindings fails to build here:
>>
>> Linking CXX shared library ../../lib/pykde/phonon.so
>> [ 83%] Built target python_module_PyKDE4_phonon
>> [ 84%] Generating sip/plasma/sipplasmapart0.cpp,
>> sip/plasma/sipplasmapart1.cpp, sip/plasma/sipplasmapart2.cpp,
>> sip/plasma/sipplasmapart3.cpp, sip/plasma/sipplasmapart4.cpp,
>> sip/plasma/sipplasmapart5.cpp, sip/plasma/sipplasmapart6.cpp,
>> sip/plasma/sipplasmapart7.cpp
>> sip: QAbstractAnimation has not been defined
>> make[2]: *** [python/pykde4/sip/plasma/sipplasmapart0.cpp] Error 1
>> make[1]: *** [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.

Thanks, I'm testing that out myself now.

> A new stable release of PyQt is imminent, then can I up the version 
> check in CMakeLists.txt. Sorry for the inconvenience guys.

As I just commented in kde-bindings, the newer sip release appears to be 
binary incompatible (ie, 4.9.x had SIP_API_MAJOR 6, and 4.10 has 
SIP_API_MAJOR 7), so requires a rebuild of all things using sip. :( 
(unless I'm missing something).

-- Rex

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Simon Edwards 
Andrea Scarpino wrote:
> 2010/1/6 Dirk Mueller :
>> I just finished the first set of 4.3.90 (KDE 4.4 RC1) tarballs and uploaded
>> them. kde-l10n still takes a few more hours, I'll upload them later.
>>
>> Please let me know of any urgent issues, we'd like to release this asap.
> 
> Hi, kdebindings fails to build here:
> 
> Linking CXX shared library ../../lib/pykde/phonon.so
> [ 83%] Built target python_module_PyKDE4_phonon
> [ 84%] Generating sip/plasma/sipplasmapart0.cpp,
> sip/plasma/sipplasmapart1.cpp, sip/plasma/sipplasmapart2.cpp,
> sip/plasma/sipplasmapart3.cpp, sip/plasma/sipplasmapart4.cpp,
> sip/plasma/sipplasmapart5.cpp, sip/plasma/sipplasmapart6.cpp,
> sip/plasma/sipplasmapart7.cpp
> sip: QAbstractAnimation has not been defined
> make[2]: *** [python/pykde4/sip/plasma/sipplasmapart0.cpp] Error 1
> make[1]: *** [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.

cheers,

-- 
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."
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Rex Dieter 
Andrea Scarpino wrote:
> 2010/1/7 Dirk Mueller :
>> while I had the problem originally, after updating to 4.4 kdebase/workspace 
>> it
>> builds fine for me.

I can confirm the same failure here, building against 
kdebase-worspace-4.3.90.

> But kdebase-workspace requires kdebindings-python to enable KDE Python
> support, if your solution work, one needs to build kdebase-workspace
> twice??

That's one of those checks for stuff really only needed at runtime, not 
buildtime... (which really irks me(1))

I'd propose that runtime-only checks like that:
1.  not be fatal for the build
2.  output/warning be made clearer that this is a runtime-only 
dependency (or the check be removed altogether).

(though I suppose such a proposal may be better suited for the 
buildsystem list)

-- Rex

p.s.  amarok has a similar type of check for qtscriptgenerator... I'm 
sure there are others.

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Dirk Mueller 
On Thursday 07 January 2010, Andrea Scarpino wrote:

> Hi, kdebindings fails to build here:

while I had the problem originally, after updating to 4.4 kdebase/workspace it 
builds fine for me. 

Can anybody else confirm that it builds? I would release the tarballs then. 

Greetings,
Dirk
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Sebastian Kügler 
On Thursday 07 January 2010 16:46:11 Dirk Mueller wrote:
> On Thursday 07 January 2010, Eric Hameleers wrote:
> > Indeed, and as  Sebastian Kügler also suggested, cmake was too old,
> > being 2.6.2 here. With cmake 2.8.0, SDO was found alright.
> >
> > My suggestion would be to force the cmake version in building KDE 4.4
> > to be at least 2.6.3.
> 
> Okay, I've raised the requirement to 2.6.3 now. Thanks for the report.

Props go to Christophe, he pointed me to that solution when I ran into it. :)
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Dirk Mueller 
On Thursday 07 January 2010, Eric Hameleers wrote:

> Indeed, and as  Sebastian Kügler also suggested, cmake was too old,
> being 2.6.2 here. With cmake 2.8.0, SDO was found alright.
> 
> My suggestion would be to force the cmake version in building KDE 4.4
> to be at least 2.6.3.

Okay, I've raised the requirement to 2.6.3 now. Thanks for the report. 

Greetings,
Dirk
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Christophe Giboudeaux 
Hi,

On Thursday 07 January 2010 14:28:22 Eric Hameleers wrote:
> 
> Here, kdelibs 4.3.90 fails to find shared-desktop-ontologies. The
> 4.3.85 tarball did not have any problem finding and using
> shared-desktop-ontologies.
> The shared-desktop-ontologies which I have installed has not changed
> at all in the meantime (this is v0.2).
> 
> I see that kdelibs/cmake/modules/FindSharedDesktopOntologies.cmake has
> changed since, to make v 0.2 a requirement (the previous version
> would just use /usr/share/ontologies as a fallback which is indeed
> correct)

Well, no, this wasn't correct. When SDO 0.2 wasn't found, CMake was indeed 
looking in /usr/share/ontologies and was setting SDO_FOUND = true even if the 
required version didn't match the one installed.

> but I do not understand why cmake does not find my installed
> SDO 0.2. I have
> /usr/share/cmake/SharedDesktopOntologies/SharedDesktopOntologiesConfig.cmak
> e with this content:

The only reason I see is the CMake version. 
cmake < 2.6.3 will only look in $prefix/share/SharedDesktopOntologies/cmake/. 
Any higher version will also look in 
$prefix/share/cmake/SharedDesktopOntologies/

Christophe.


signature.asc
Description: This is a digitally signed message part.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Sebastian Kügler 
On Thursday 07 January 2010 14:28:22 Eric Hameleers wrote:
> Here, kdelibs 4.3.90 fails to find shared-desktop-ontologies. The

I've also had this problem in a test build last week. Turned out that my cmake 
was 
too old, updating fixed it. Same issue?
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Dirk Mueller 
On Thursday 07 January 2010, Eric Hameleers wrote:

> SDO 0.2. I have
> /usr/share/cmake/SharedDesktopOntologies/SharedDesktopOntologiesConfig.cmak
> e with this content:

you need
/usr/share/cmake/SharedDesktopOntologies/SharedDesktopOntologiesConfigVersion.cmake

as well, this is installed by my package here. 

Greetings,
Dirk
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Andrea Scarpino 
2010/1/7 Eric Hameleers :
> Here, kdelibs 4.3.90 fails to find shared-desktop-ontologies. The
> 4.3.85 tarball did not have any problem finding and using
> shared-desktop-ontologies.
> The shared-desktop-ontologies which I have installed has not changed
> at all in the meantime (this is v0.2).
None problem with shared-desktop-ontologies 0.2 here.

About the sip error I am trying to build it with the last sip snapshot.

-- 
Andrea `bash` Scarpino
Arch Linux Developer
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Eric Hameleers 
On Wed, 6 Jan 2010, Dirk Mueller wrote:

> Hi,
>
> I just finished the first set of 4.3.90 (KDE 4.4 RC1) tarballs and uploaded
> them. kde-l10n still takes a few more hours, I'll upload them later.
>
> Please let me know of any urgent issues, we'd like to release this asap.
>
>
> Greetings,
> Dirk
> ___
> Kde-packager mailing list
> kde-packa...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-packager

Here, kdelibs 4.3.90 fails to find shared-desktop-ontologies. The 
4.3.85 tarball did not have any problem finding and using 
shared-desktop-ontologies.
The shared-desktop-ontologies which I have installed has not changed 
at all in the meantime (this is v0.2).

I see that kdelibs/cmake/modules/FindSharedDesktopOntologies.cmake has 
changed since, to make v 0.2 a requirement (the previous version 
would just use /usr/share/ontologies as a fallback which is indeed 
correct) but I do not understand why cmake does not find my installed 
SDO 0.2. I have 
/usr/share/cmake/SharedDesktopOntologies/SharedDesktopOntologiesConfig.cmake 
with this content:

set(SHAREDDESKTOPONTOLOGIES_VERSION_MAJOR 0)
set(SHAREDDESKTOPONTOLOGIES_VERSION_MINOR 2)
set(SHAREDDESKTOPONTOLOGIES_VERSION 0.2)

set(SHAREDDESKTOPONTOLOGIES_ROOT_DIR /usr/share/ontology)


Cheers, Eric

-- 
Eric Hameleers 
Jabber: al...@jabber.xs4all.nl
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Andrea Scarpino 
2010/1/6 Dirk Mueller :
> Hi,
>
> I just finished the first set of 4.3.90 (KDE 4.4 RC1) tarballs and uploaded
> them. kde-l10n still takes a few more hours, I'll upload them later.
>
> Please let me know of any urgent issues, we'd like to release this asap.

Hi, kdebindings fails to build here:

Linking CXX shared library ../../lib/pykde/phonon.so
[ 83%] Built target python_module_PyKDE4_phonon
[ 84%] Generating sip/plasma/sipplasmapart0.cpp,
sip/plasma/sipplasmapart1.cpp, sip/plasma/sipplasmapart2.cpp,
sip/plasma/sipplasmapart3.cpp, sip/plasma/sipplasmapart4.cpp,
sip/plasma/sipplasmapart5.cpp, sip/plasma/sipplasmapart6.cpp,
sip/plasma/sipplasmapart7.cpp
sip: QAbstractAnimation has not been defined
make[2]: *** [python/pykde4/sip/plasma/sipplasmapart0.cpp] Error 1
make[1]: *** [python/pykde4/CMakeFiles/python_module_PyKDE4_plasma.dir/all]
Error 2
make: *** [all] Error 2

-- 
Andrea `bash` Scarpino
Arch Linux Developer
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-07 Thread Dirk Mueller 
On Thursday 07 January 2010, Andrea Scarpino wrote:
> 2010/1/6 Dirk Mueller :
> > Hi,
> > 
> > I just finished the first set of 4.3.90 (KDE 4.4 RC1) tarballs and
> > uploaded them. kde-l10n still takes a few more hours, I'll upload them
> > later.
> > 
> > Please let me know of any urgent issues, we'd like to release this asap.
> 
> Hi, kdebindings fails to build here:
> 
> Linking CXX shared library ../../lib/pykde/phonon.so
> [ 83%] Built target python_module_PyKDE4_phonon
> [ 84%] Generating sip/plasma/sipplasmapart0.cpp,
> sip/plasma/sipplasmapart1.cpp, sip/plasma/sipplasmapart2.cpp,
> sip/plasma/sipplasmapart3.cpp, sip/plasma/sipplasmapart4.cpp,
> sip/plasma/sipplasmapart5.cpp, sip/plasma/sipplasmapart6.cpp,
> sip/plasma/sipplasmapart7.cpp
> sip: QAbstractAnimation has not been defined
> make[2]: *** [python/pykde4/sip/plasma/sipplasmapart0.cpp] Error 1
> make[1]: *** [python/pykde4/CMakeFiles/python_module_PyKDE4_plasma.dir/all]
> Error 2
> make: *** [all] Error 2

Hi, 

I'm running into the same issue. Any solution? this currently blocks 4.4 RC1 
release.

Thanks,
Dirk
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

KDE 4.4 RC1 (4.3.90) tarballs uploaded

2010-01-06 Thread Dirk Mueller 

Hi, 

I just finished the first set of 4.3.90 (KDE 4.4 RC1) tarballs and uploaded 
them. kde-l10n still takes a few more hours, I'll upload them later. 

Please let me know of any urgent issues, we'd like to release this asap. 


Greetings,
Dirk
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team