2009/6/24 Dirk Mueller :
>
> Hi,
>
> I've finished creating the first set of tarballs and uploaded them to ktown
> (unstable/4.2.95). Expected release is tuesday/wednesday next week.
>
> kdepim tarball has been split into kdepim and kdepim-runtime (currently only
> containing akonadi related stuff)
2009/6/4 Sune Vuorela :
> 3) eigen people start to work fast to get a stable release out before 4.3,
> maybe just backporting the needed things to 2.0 ?
This is done now. The eigen 2.0 stable branch now allows to build the
latest Step (r977545). I'll tag it as 2.0.3 after it has received some
t
2009/6/4 Cyrille Berger :
> On Thursday 04 June 2009, Benoit Jacob wrote:
>> > 3) eigen people start to work fast to get a stable release out before
>> > 4.3, maybe just backporting the needed things to 2.0 ?
> There is a 4) since eigen is purely template, would it be poss
2009/6/4 Sune Vuorela :
> On Thursday 04 June 2009 03:07:48 Benoit Jacob wrote:
>> kdeedu (step) relies on the development version of eigen, that will
>> become eigen 2.1.
>> but eigen 2.1 won't be released before kde 4.3.
>
> I'm quite puzzled by this, especi
2009/6/4 Tom Albers :
> At Thursday 04 June 2009 03:07, you wrote:
>> kdeedu (step) relies on the development version of eigen, that will
>> become eigen 2.1.
>> but eigen 2.1 won't be released before kde 4.3.
>
> Hi,
>
> That's a violation of what we have discussed earlier iirc. KDE should only
>
2009/6/3 Maciej Mrozowski :
> On Wednesday 03 of June 2009 22:24:05 Ingmar Vanhassel wrote:
>
>> At least kdebase-runtime [1], and kdebindings [2] fail here if I use the
>> latest soprano release. Is soprano trunk required or will a soprano release
>> follow?
>
> Further "yet unstatisfied" (but at
OK, I made eigen2 require cmake 2.6.2.
Cheers,
Benoit
2009/1/4 Alexander Neundorf :
> On Saturday 03 January 2009, Tom Albers wrote:
>> Hi,
>>
>> In preparation of the release of 4.2.0, I've created the
>> tags/kdesupport-for-4.2. This tag of kdesupport should be used when you
>> compile the 4.2 b
There I added eigen2.
It is 2.0-beta4 which I just released too. I hope I'll be allowed to
update the tag here to 2.0 final when I release it (before KDE 4.2) ?
Cheers,
Benoit
2009/1/3 Tom Albers :
> Hi,
>
> In preparation of the release of 4.2.0, I've created the
> tags/kdesupport-for-4.2. This
2008/12/22 Tom Albers :
> Op maandag 22 december 2008 16:28 schreef u:
>> So nobody did it?
>
> Yes he did:
> http://markmail.org/message/6ys7shf5dmw2e24p?q=kde-core-devel+kdesupport+faure
>
Uh.. ok!
I wasn't subscribed to kde-core-devel and I don't know what proportion
of the kdesupport develope
So nobody did it?
In Eigen, we plan to branch 2.0 and use trunk for wildly broken
development in january. Which means that in the worst case I'll have
to do the 'kdesupport rearrangement' myself. But as a punition for
everyone's lack of interest in kdesupport, i'd then also port a few
random proje
Cheers,
Benoit
2008/9/29, Marijn Kruisselbrink <[EMAIL PROTECTED]>:
> On Monday 29 September 2008 15:59:01 Benoit Jacob wrote:
>> There are a couple of issues with svn external...
>>
>> AFAIK relative svn externals (like "../../path") are only handled by
>
There are a couple of issues with svn external...
AFAIK relative svn externals (like "../../path") are only handled by
SVN client >= 1.5
absolute svn externals are a pain, they have to point to anonsvn which
causes several issues, e.g. svn:// blocked by firewalls.
I'm not an expert though!
Chee
Great. By the way, looking back at Tom's original proposal, the only
difference is renaming "kdesupport-for-trunk" to
"kdesupport-stable-for-trunk" to reduce confusion with
/trunk/kdesupport.
2008/9/29, David Faure <[EMAIL PROTECTED]>:
> On Monday 29 September 2
2008/9/29, David Faure <[EMAIL PROTECTED]>:
> On Monday 29 September 2008, Benoit Jacob wrote:
>> If we remove /trunk/kdesupport, then we can use the name
>> kdesupport-for-trunk without any risk of confusion.
>
> I don't think we want to do that. People workin
If we remove /trunk/kdesupport, then we can use the name
kdesupport-for-trunk without any risk of confusion.
Also, why couldn't we have /trunk/kdesupport-for-4.1etc. in parallel
with these tags ?
I propose:
tags/kdesupport-devel
tags/kdesupport-for-trunk (what we called kdesupport-stable)
tags/k
+1
(although i only recently learned the difference between a tag and a
branch so i'm not an expert)
2008/9/29, Mark Constable <[EMAIL PROTECTED]>:
> On 2008-09-29, Benoit Jacob wrote:
>> The only nitpick is that there is a risk of confusion between
>> /tags/kdesu
I support this plan too. Thanks for getting this rolling.
The only nitpick is that there is a risk of confusion between
/tags/kdesupport-for-trunk and /trunk/kdesupport, which is why I also
suggested to move /trunk/kdesupport to /branches/kdesupport (or
whatever you feel is appropriate).
Cheers,
2008/9/14, Allen Winter <[EMAIL PROTECTED]>:
> In the meantime, dfaure's proposal (snippet below) looks good. I think this
> is basically
> what many of us have suggested but for some reason the simplicity got lost
> in the noise.
> Should we also commit a tags/kdesupport-for-4.1/CMakeLists.txt fi
Sorry!!
I sent this message a week ago, but it seemed to have been lost! Please ignore.
Benoit
2008/9/1, Benoît Jacob <[EMAIL PROTECTED]>:
> Hi,
>
> I just found out these discussions on the release-team list, to which I am
> not
> subscribed:
>
> http://mail.kde.org/pipermail/release-team/2008-
PROTECTED]>:
> On Sunday 07 September 2008 10:03:47 Benoit Jacob wrote:
>> Aah thanks for the detailed reply.
>>
>> I have been very concerned about the risk of breaking KDE compilation,
>> so I welcome these changes very much. I would like that the
>> development
Aah thanks for the detailed reply.
I have been very concerned about the risk of breaking KDE compilation,
so I welcome these changes very much. I would like that the
development branch of Eigen be a place where we can experiment and
break stuff without affecting our users. So, I support your plan.
Hi,
I just found out these discussions on the release-team list, to which I was
not
subscribed:
http://mail.kde.org/pipermail/release-team/2008-August/002395.html
http://mail.kde.org/pipermail/release-team/2008-August/002433.html
My questions are:
1. Is /trunk/kdesupport going to be no longer r
As far as I'm concerned, I can confirm that the following two
subdirectories of kdesupport/ can remain API-stable:
kdesupport/eigen/(the Eigen 1 library)
kdesupport/gmm/ (snapshot of the GMM++ library)
Actually, I'm working on eigen2 in /branches/work/eigen2. Once it'll be
ready, it'l
23 matches
Mail list logo
