Re: To help the release management

2007-10-02 Thread Dirk Mueller
On Monday, 1. October 2007, Johann Ollivier Lapeyre wrote:

 I just saw there are maybe a plan to which KDE to bugzilla 3, but bugzilla
 3 doesn't seems to improve these criticals points...

Bugzilla 3 supports flags on bugs, thats exactly the same like those release 
plans. It would definitely be a step forward to use such a tool for release 
management (not talking about KDE Games only here). 

 Could we think on a better KDE-wise tool and organisation? Should we
 (kdegames) build up your own tool to manage the module?

To be honest, Trac only works for single projects. even KDE Games would be 
too broad to track in Trac. It also doesn't help you in keeping wiki pages in 
sync, and learning yet-another-tool for yet-another-KDE-subproject is an 
additional burden for an outsider who might become interested in helping with 
KDE Games. if all you want to do is to lock in and have your own playground 
exactly the way you want to, then go for Trac. 


Greetings,
Dirk




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


Re: [Kde-bindings] Questions About the New Schedule

2007-10-02 Thread Richard Dale
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

2007-10-02 Thread Richard Dale
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: blockers.

2007-10-02 Thread Thomas Zander
Missing email-adres from the debian packaging team, which I think is great 
to have on this list is interrested parties :)

 Kde3libs and kde4libs is afaik currently coinstallable in the same
 prefix (But is quite unusable, unless kde4base also can be installed
 there)

This I don't understand,  what kdebase stuff needs to be coinstallable, 
but is not yet able to do so?

Icon themes either replace but mostly have a different name, which is the 
same for all things in 'runtime', even applications in runtime simply 
replace the old ones.
Looking at workspace I think that debian wants to package that as a 
separate thing and make that package conflict with their kde3 
counterparts (i.e. only have one installed at a time) because they really 
replace the kde3 *desktop*.
This to me is like you the long standing concept that you can not have two 
versions of one application installed. (like apt 0.6 and apt 0.7)

Am I missing some problems?
-- 
Thomas Zander


pgp0I4Ve65TwA.pgp
Description: PGP signature
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team