ther, while optional and at runtime,
> > dependency for the SC 4.5 release, for the network:/ kio-slave in
> >
> > kdebase/runtime/kioslave/network:
> > Cagibi 0.1(.0) from kdesupport (tagged in /tags/cagibi/0.1.0)
> >
> > Cagibi is a daemon for SSDP (the discove
ve in
> kdebase/runtime/kioslave/network:
> Cagibi 0.1(.0) from kdesupport (tagged in /tags/cagibi/0.1.0)
>
> Cagibi is a daemon for SSDP (the discovery part of UPnP) and, if accessable
> via D-Bus, used to also show UPnP devices/services in the network:/
> kio-slave listing
Hi,
due to a broken laptop and other real life circumstances I completely missed
to announce in time another, while optional and at runtime, dependency for the
SC 4.5 release, for the network:/ kio-slave in
kdebase/runtime/kioslave/network:
Cagibi 0.1(.0) from kdesupport (tagged in
On Tuesday 09 February 2010 11:53:58 David Faure wrote:
> SVN commit 1087546 by dfaure:
>
> And now the real fix for the dbus connection leak problem :/
>
> Next step: doing the same (but not the same) in kdelibs/nepomuk.
> But at least the akonadiserver leak (triggered by kmail) is fixed by this.
queryserviceclient.cpp
--- trunk/kdesupport/akonadi/server/src/search/queryserviceclient.cpp
#1087545:1087546
@@ -40,21 +40,34 @@
{
public:
QDBusConnectionPerThreadHelper()
-: m_counter( 0 ) {
+: m_connection( QDBusConnection::connectToBus
eg.de, release-team@kde.org, thi...@kde.org
M +1 -0 queryserviceclient.cpp
--- trunk/kdesupport/akonadi/server/src/search/queryserviceclient.cpp
#1087523:1087524
@@ -143,6 +143,7 @@
Nepomuk::Search::QueryServiceClient::~QueryServiceClient()
{
+delete d->queryServiceInterface;
codebase until it lands in kdesupport, we look forward to
this so we can have a clean solution.
Also I plan to port Amarok's social about dialog to kdelibs for 4.5
and I would need LibAttica for that.
Cheers
Téo
___
release-team mailing list
release-team@kde.o
already use LibAttica in Amarok, currently it's just crudely copied
> inside our codebase until it lands in kdesupport, we look forward to
> this so we can have a clean solution.
> Also I plan to port Amarok's social about dialog to kdelibs for 4.5
> and I would need LibAtti
Hi Frederik,
On Tuesday 17 November 2009, Frederik Gladhorn wrote:
> Hi,
> I'd like to move libattica to kdesupport (it has spent its two weeks
> in review now), so that it can be released with KDE 4.4.
> This will allow great improvements in the Get Hot New Stuff, things
>
Hi,
I'd like to move libattica to kdesupport (it has spent its two weeks
in review now), so that it can be released with KDE 4.4.
This will allow great improvements in the Get Hot New Stuff, things
like the new "Social About Dialog" that Amarok has and big
improvements in the Ope
Op Monday 05 January 2009 00:07 schreef u:
> 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) ?
Yes, even after it...
Toma___
release-team
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
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/kd
On Sunday 04 January 2009 13:09:30 Alexander Neundorf wrote:
> 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
&
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 branch in the future. Trunk's version of kdesupport should
>
Hi,
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 branch in the future. Trunk's version of kdesupport
> s
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 branch in the future. Trunk's version of kdesupport should be used to
compile KDE trunk (which would be KDE 4.3.0).
At least Ak
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 wh
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
> In Eigen, we plan to branch 2.0 and use trunk for wildly broken
> development in january. Which means that in the worst case
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 th
Op vrijdag 03 oktober 2008 15:29 schreef u:
> On Sunday 28 September 2008, Tom Albers wrote:
> > Hi,
> >
> > I think we have come to a conclusion, but not to a descision. Let's try to
> change that. Below you find the proposal based on the various mails to this
> list. I will wait untill there ar
On Sunday 28 September 2008, Tom Albers wrote:
> Hi,
>
> I think we have come to a conclusion, but not to a descision. Let's try to
> change that. Below you find the proposal based on the various mails to this
> list. I will wait untill there are a few supporters for this proposal, before
> po
Using these tags is going to be the recommended way of building KDE,
with /trunk/kdesupport becoming only for kdesupport development and
proactive testing by adventurous KDE developers.
So we don't want to require svn >= 1.5 until most people have it. Here
on Kubuntu Hardy I have svn 1.4.
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
> SVN client >= 1.5
Since these tags are only for convenience anyway, what is the problem with
requiring svn client
t an expert though!
Cheers,
Benoit
2008/9/29, Pino Toscano <[EMAIL PROTECTED]>:
> Hi,
>
>> For each main kde tree we will create a tag. For example for the current
>> stable KDE release we create a tags/kdesupport-for-4.1/. Within that
>> folder
>> there are (cheap)c
Hi,
> For each main kde tree we will create a tag. For example for the current
> stable KDE release we create a tags/kdesupport-for-4.1/. Within that folder
> there are (cheap)copies of the kdesupport libraries which should be used
> for compiling the KDE 4.1 tree. For example:
>
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
On Monday 29 September 2008, Benoit Jacob wrote:
> /trunk/kdesupport for kdesupport development
> /tags/kdesupport-stable-for-trunk
> /tags/kdesupport-for-4.1
> /tags/kdesupport-for-4.2
Looks fine to me.
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Kon
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
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 working on kdesupport (or fixing
the occasional bug) expect it to be in trunk/kdesu
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)
On Monday 29 September 2008, Mark Constable wrote:
> On 2008-09-29, Benoit Jacob wrote:
> > 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 /br
+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
On 2008-09-29, Benoit Jacob wrote:
> 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).
T
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
>
> The release-team has decided to change the organisation of the kdesupport
> system we use. Please read the details below.
>
> Problem
>
> KDE development is devided in several branches, especially the current stable
> KDE branch and the unsta
e too.
Best,
Toma
The release-team has decided to change the organisation of the kdesupport
system we use. Please read the details below.
Problem
KDE developme
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/kdesupp
hout affecting our users. So, I support your plan.
> > > There seems to be another set of kdesupport developers who
> > > rely on the KDE folks to help test their stuff in-progress, just
> > > like any other KDE code. Hence the push-back on this idea.
> >
> &
On Wednesday 10 September 2008 19:06:36 you wrote:
> On Sunday 07 September 2008, Allen Winter wrote:
>
> > > development branch of Eigen be a place where we can experiment and
> > > break stuff without affecting our users. So, I support your plan.
> > There seems t
On Thursday 11 September 2008, Dirk Mueller wrote:
> that could have been solved in the source code with
> less work than this thread already took
Done (at least 4.1-branch and trunk compile with both versions of strigi now)
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on K
On Thursday 11 September 2008, Dirk Mueller wrote:
> > Well what I was thinking is we could make a kdesupport 4.1 branch for
> > instance to do the same thing. (unless you mean kdesupport-stable which
> > simply tracks the latest stable release of KDE).
>
> It doesn&
elopment version of eigen? ;-)
You'll get angry users after you release a new version, as opposed to getting
earlier reports from friendly developers, no? :-)
Overall I completely agree with a "use this kdesupport tag [which would be a
collection of tags, pointing to the tag for t
On 2008-09-11, Dirk Mueller wrote:
> ...
> I think what is missing here is regular snapshots of things that should be
> used for /trunk development, and a timeline on when they're required (e.g.
> only on mondays).
I the mean time, until a thorough policy is fleshed out, would it
be possible to
On Sunday 07 September 2008, Allen Winter wrote:
> > development branch of Eigen be a place where we can experiment and
> > break stuff without affecting our users. So, I support your plan.
> There seems to be another set of kdesupport developers who
> rely on the KDE folks
On Tuesday 26 August 2008, Michael Pyne wrote:
> Well what I was thinking is we could make a kdesupport 4.1 branch for
> instance to do the same thing. (unless you mean kdesupport-stable which
> simply tracks the latest stable release of KDE).
It doesn't make sense to me - t
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 recommended to build KDE SVN?
> I
> mean e.g. on the techbase page,
> http://techba
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-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
orner cases. So far no big glitch has
happened but we're still scared of having users relying on our
development tree.
By contrast, other libs in kdesupport may have bugs but (normally)
won't break compilation of the programs using them.
Cheers,
Benoit
2008/9/7 Allen Winter <[EMAIL
can experiment and
> break stuff without affecting our users. So, I support your plan.
>
There seems to be another set of kdesupport developers who
rely on the KDE folks to help test their stuff in-progress, just
like any other KDE code. Hence the p
.
Cheers,
Benoit
2008/9/7 Tom Albers <[EMAIL PROTECTED]>:
> At Tuesday 02 September 2008 16:01, you wrote:
>> 1. Is /trunk/kdesupport going to be no longer recommended to build KDE SVN?
>> I
>> mean e.g. on the techbase page,
>> http://techbase.kde.org/Getting
At Tuesday 02 September 2008 16:01, you wrote:
> 1. Is /trunk/kdesupport going to be no longer recommended to build KDE SVN?
> I
> mean e.g. on the techbase page,
> http://techbase.kde.org/Getting_Started/Build/KDE4/Prerequisites#kdesupport
That would be the idea, yes.
> Any plan
release-team/2008-August/002433.html
>
> 5. After we create a tag does that mean that we can do whatever we want
> in /trunk/kdesupport/eigen2 without risking to break compilation for other
> people? This is related to question 1. As long as we tell people to use
> trunk/kdesupport, m
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
On Tuesday 26 August 2008, Tom Albers wrote:
> Op dinsdag 26 augustus 2008 22:12 schreef u:
> > i.e. /tags/kdesupport/latest-release would have cherry-picked subdirs of
> > the latest phonon, strigi, qca, etc. releases from their appropriate tag
> > or branch. As new release
Op dinsdag 26 augustus 2008 22:12 schreef u:
> i.e. /tags/kdesupport/latest-release would have cherry-picked subdirs of the
> latest phonon, strigi, qca, etc. releases from their appropriate tag or
> branch. As new releases occur the tag could be updated as well.
I like and support th
in branch. Or maybe their
> > > API matures over the years and it doesn't become such a big deal.
> > > etc.
> >
> > For people taking stuff from svn, for instance kdesvn users, couldn't
> > there be a kdesupport tag of what is good to use with kde ?
&g
remove that version and use the one from your distro instead..."
>
> I'm not sure I will like this idea.
> First off, it will break many (all?) scripts, including the widely used
> kdesvn-build.
You can use the branch option to control what version of kdesupport you build.
Howdy,
If you are a developer of a kdesupport project, please make sure
that your latest-and-greatest stable version is tagged
in our subversion tags repository.
The "lastest-and-greatest stable version" should be the version
that we need to use when building trunk.
If you need help
t doesn't become such a big deal.
> > etc.
> For people taking stuff from svn, for instance kdesvn users, couldn't there
> be
> a kdesupport tag of what is good to use with kde ?
>
yes, and the tags already exists for akonadi, decibel, kdewin-installer,
phonon, qca, s
svn, for instance kdesvn users, couldn't there be
a kdesupport tag of what is good to use with kde ?
--
Cyrille Berger
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
ystem... but that would upset eveyone else that did not.
>
> Sure, so the kdesupport devs need to give the distros and the
> developers fair warning time. They also need to tell us where
> to pick up stable source code so we can build ourselves.
And hopefully the "tell us" part
system... but that would upset eveyone else that did not.
>
Sure, so the kdesupport devs need to give the distros and the
developers fair warning time. They also need to tell us where
to pick up stable source code so we can build ourselves.
So maybe they need put up a website with tarballs.
his idea.
> First off, it will break many (all?) scripts, including the widely used
> kdesvn-build.
It would most likely ruin my scripts ability to automatically
build daily Archlinux packages.
As a suggestion, all of trunk/kdesupport could probably be
replaced with a single file, say trunk/KDE/
I'm not sure I will like this idea.
First off, it will break many (all?) scripts, including the widely used
kdesvn-build. Then, compiling kdesupport has always been great for me so that
I didn't have to wonder around look for each individual subpackage
(especially on distros that I do not
Op dinsdag 26 augustus 2008 01:30 schreef u:
> That's correct. And if someone complains we can say that "you are using a
> development
> version of Foo which is not supported in KDE yet. please remove that version
> and use
> the one from your distro instead..."
+1 for me.
Toma_
On Monday 25 August 2008 12:52:57 Tom Albers wrote:
> Op zaterdag 23 augustus 2008 01:18 schreef u:
> > Howdy,
> >
> > The recent build problems in our kdesupport package dependencies
> > needs to be addressed.
> >
> > I think we need to treat kdesu
Op zaterdag 23 augustus 2008 01:18 schreef u:
> Howdy,
>
> The recent build problems in our kdesupport package dependencies
> needs to be addressed.
>
> I think we need to treat kdesupport libs just like any other external
> dependency.
>
> Something like the follow
On Monday 25 August 2008 06:57:18 Dirk Mueller wrote:
> On Saturday 23 August 2008, Allen Winter wrote:
>
> > I think we need to treat kdesupport libs just like any other external
> > dependency.
>
> The suggestion you describe is already our policy.
Ok, good to know.
On Saturday 23 August 2008, Allen Winter wrote:
> I think we need to treat kdesupport libs just like any other external
> dependency.
The suggestion you describe is already our policy. If you refer to the strigi
mess, then I think this should have been fixed with a cmake inducted #def
On Sunday 24 August 2008 10:16:22 Albert Astals Cid wrote:
> A Dissabte 23 Agost 2008, Allen Winter va escriure:
> > Howdy,
> >
> > The recent build problems in our kdesupport package dependencies
> > needs to be addressed.
> >
> > I think we need to tr
A Dissabte 23 Agost 2008, Allen Winter va escriure:
> Howdy,
>
> The recent build problems in our kdesupport package dependencies
> needs to be addressed.
>
> I think we need to treat kdesupport libs just like any other external
> dependency.
>
> Something like the follo
On Aug 22, 2008, at 6:18 PM, Allen Winter wrote:
> Howdy,
>
> The recent build problems in our kdesupport package dependencies
> needs to be addressed.
>
> I think we need to treat kdesupport libs just like any other
> external dependency.
>
> Something like the f
Howdy,
The recent build problems in our kdesupport package dependencies
needs to be addressed.
I think we need to treat kdesupport libs just like any other external
dependency.
Something like the following guidelines:
No KDE code (in trunk) changes should be necessary until:
- a real release
Op maandag 28 juli 2008 11:51 schreef u:
> On Sunday 27 July 2008, Tom Albers wrote:
>
> > When I upload the tarballs I can upload them to the 'extra' folder,
> > packagers will find it.
>
> Please don't put the "support stuff" under extra. They're separate, as
> they're
> needed for building K
On Sunday 27 July 2008, Tom Albers wrote:
> When I upload the tarballs I can upload them to the 'extra' folder,
> packagers will find it.
Please don't put the "support stuff" under extra. They're separate, as they're
needed for building KDE, rather than the other way around.
Greetings,
Dirk
_
Op zaterdag 19 juli 2008 16:06 schreef u:
> > (I would like if kdesupport would be released together with the rest of
> > KDE, or at least be tagged, so later on it is easier to find a matching
> > version)
>
> I think the automoc (and phonon for that matter) releases n
Rex Dieter wrote:
> Alexander Neundorf wrote:
>> On Tuesday 22 July 2008, Dirk Mueller wrote:
>>> On Saturday 19 July 2008, Matthias Kretz wrote:
That's not entirely right. For the last beta I asked dirk to do the
automoc4 0.9.83 tarball. You can find it on ftp.kde.org.
>>> unstable/suppo
Alexander Neundorf wrote:
> On Tuesday 22 July 2008, Dirk Mueller wrote:
>> On Saturday 19 July 2008, Matthias Kretz wrote:
>>> That's not entirely right. For the last beta I asked dirk to do the
>>> automoc4 0.9.83 tarball. You can find it on ftp.kde.org.
>> unstable/support/automoc4
>>
>>> I need
On Tuesday 22 July 2008, Matthias Kretz wrote:
> I suggest to have a toplevel directory for automoc4 and phonon and not put
> it in support.
Why? Well, done, but I thought that putting it inside a support directory is a
lot cleaner :)
I've uploaded phonon-4.2.0 to stable/phonon/4.2.0 now and au
On Tuesday 22 July 2008 22:20:08 Alexander Neundorf wrote:
> On Tuesday 22 July 2008, Matthias Kretz wrote:
> > On Tuesday 22 July 2008 14:13:17 Dirk Mueller wrote:
> > > On Saturday 19 July 2008, Matthias Kretz wrote:
> > > > That's not entirely right. For the last beta I asked dirk to do the
> >
On Tuesday 22 July 2008, Matthias Kretz wrote:
> On Tuesday 22 July 2008 14:13:17 Dirk Mueller wrote:
> > On Saturday 19 July 2008, Matthias Kretz wrote:
> > > That's not entirely right. For the last beta I asked dirk to do the
> > > automoc4 0.9.83 tarball. You can find it on ftp.kde.org.
> >
> >
On Tuesday 22 July 2008, Dirk Mueller wrote:
> On Saturday 19 July 2008, Matthias Kretz wrote:
> > That's not entirely right. For the last beta I asked dirk to do the
> > automoc4 0.9.83 tarball. You can find it on ftp.kde.org.
>
> unstable/support/automoc4
>
> > I need an automoc4 0.9.84 release a
On Saturday 19 July 2008, Matthias Kretz wrote:
> That's not entirely right. For the last beta I asked dirk to do the
> automoc4 0.9.83 tarball. You can find it on ftp.kde.org.
unstable/support/automoc4
> I need an automoc4 0.9.84 release as soon as possible, though. (I already
> released one pa
On Tuesday 22 July 2008 14:13:17 Dirk Mueller wrote:
> On Saturday 19 July 2008, Matthias Kretz wrote:
> > That's not entirely right. For the last beta I asked dirk to do the
> > automoc4 0.9.83 tarball. You can find it on ftp.kde.org.
>
> unstable/support/automoc4
I suggest to have a toplevel dir
On Saturday 19 July 2008 15:49:30 Alexander Neundorf wrote:
> Hi,
>
> several weeks ago we (me and Matthias) moved automoc from kdelibs to
> kdesupport so that the automoc-functionality ( #include "foo.moc" and all
> the rest happens magically) can be used also by non-K
Hi,
several weeks ago we (me and Matthias) moved automoc from kdelibs to
kdesupport so that the automoc-functionality ( #include "foo.moc" and all the
rest happens magically) can be used also by non-KDE apps, as e.g. phonon,
akonadi, etc..
This works so far, but we kept automoc in
Op maandag 07 juli 2008 14:56 schreef u:
> On Monday 07 July 2008, Tom Albers wrote:
>
> > As this seems to hit quite a few people, we might want a fix for this
> > before Dirk tags rc1.
>
> unless I'm missing something, the crash is only in strigi? strigi is not part
> of the RC1 release.
Tech
On Monday 07 July 2008, Tom Albers wrote:
> As this seems to hit quite a few people, we might want a fix for this
> before Dirk tags rc1.
unless I'm missing something, the crash is only in strigi? strigi is not part
of the RC1 release.
Greetings,
Dirk
__
t; > I'd appreciate if you can fix the CMakeLists.txt, since I cannot do this
> > from work (the next 6 hours).
>
> I've disabled avithroughanalyzer.cpp in CMakeLists.txt - I did a recompile of
> kdesupport + kdelibs, but the crash in bug 164296 still occurs.
>
> I
On 2008-05-23 16:41, Pino Toscano wrote:
> [EMAIL PROTECTED] fur such question please.
> And reading the replies to the same problem might help:
> http://mail.kde.org/pipermail/release-team/2008-May/002065.html
Doh, apologies for the noise. I better sign up to kde-devel again.
--markc
__
Alle venerdì 23 maggio 2008, Mark Constable ha scritto:
> Apologies for posting this again to this list but I have no idea
> where or who should be notified about this.
[EMAIL PROTECTED] fur such question please.
And reading the replies to the same problem might help:
http://mail.kde.org/pipermail
Apologies for posting this again to this list but I have no idea
where or who should be notified about this. Could someone please
pass this on to anyone who can fix this please.
An anonymous checkout should not require any authorization.
==> svn up kdesupport from svn://anonsvn.kde.org/home/
Hi,
> I'm not sure where to post this so apologies if this is not the right
> list for an anonymous checkout bug.
[EMAIL PROTECTED]
> Fetching external item into 'taglib/admin'
> Authentication realm: <https://svn.kde.org:443> KDE SVN account
> Password for
Mark Constable wrote:
> I'm not sure where to post this so apologies if this is not the right
> list for an anonymous checkout bug.
>
> # /home/sources/kdesupport svn up
> Uemerge/portage/kdesupport/akonadi/akonadi-0.80.0-20080423.py
> Uemerge/portage/kdesupport/a
I'm not sure where to post this so apologies if this is not the right
list for an anonymous checkout bug.
# /home/sources/kdesupport svn up
Uemerge/portage/kdesupport/akonadi/akonadi-0.80.0-20080423.py
Uemerge/portage/kdesupport/automoc/automoc-20080426.py
Uemerge/portage/kde/kde
Op Tuesday 25 March 2008 16:56 schreef u:
> But maybe I have a weird logic, and everything is beautiful and nice how
> it is.
No, it is a mess, but by making another branch, the mess gets bigger, not less
;-)
Remember that we could not use kdesupport/qca trunk to compile kde trunk just
On Tuesday 25 March 2008, Tom Albers wrote:
> I just don't see the need, if the kdesupport authors request it, it's
> a totally different discussion though.
Where are kdesupport apps developed? In /trunk/kdesupport? In other svn
servers? Again why do we keep it here, if it is
At Tuesday 25 March 2008 16:27, you wrote:
> On Tuesday 25 March 2008, Tom Albers wrote:
> > To be able to ship 4.0 to the customers distro's /must/ have version
> > of all the dependencies of KDE4. Including the ones which live in
> > kdesupport. How else can they ship i
On Tuesday 25 March 2008, Tom Albers wrote:
> To be able to ship 4.0 to the customers distro's /must/ have version
> of all the dependencies of KDE4. Including the ones which live in
> kdesupport. How else can they ship it?
I'm not seeing how this is relevant. If you want t
1 - 100 of 137 matches
Mail list logo
