Re: splitting qt4 into pieces

[Ana Guerrero]

On Tue, Feb 12, 2008 at 01:02:27AM +0100, Sune Vuorela wrote:
> Hi!
> 
> This is going to be a long email, so let us start with a executive summary:
> split off libqtdbus and libqtscript from libqt4-core and rename libqt4-core
> keep libqt4-gui
> rework libqt4-sql entirely to make it plugin based
> split -dev package.
> 
> 
> And the real report:
> 
> several times, different requests for splitting qt4 into pieces have been 
> made.
> I find many of them kind of reasonable - and especially when qt4 becomes more 
> and more popular.
> 
> 
> A couple of example use cases:
> 
> John have found it quite easy to write a small network service using qt. He 
> would like to deploy it on some small device, so he would like to only have 
> around what he actually needs: libQtCore && libQtNetwork.  With current 
> packaging, he also needs to install dbus, a xml parser and other similar 
> thintgs
> 
> Brian wants to have a set of cross platform command line utilities, so he 
> writes a set of utils using qt. He only uses QtCore, as he needs no network, 
> no Xml, no anything.
> 
> Joanne does small graphical apps, like a image viewer and text viewer. In 
> order to have her programs installed, only parts of qt that is needed is 
> QtCore and QtGui. no Xml, no openGL, no SVG, ...
> 
> 
> But enough bullshit. let us look at some numbers:
> 
> libQtCore is used by all packages - and have a set of external dependencies.
> libQtCore is 1.5M big
> 
> libQtXml has the same set of external dependencies as libQtCore and is 350K 
> big. No need to split this out unless we care for 350K
> 
> libQtNetwork has the same set of external dependencies as libQtCore and is 
> 575 
> K big. No need to split this out unless we care for 575K (we might do that)
> 
> libQtScript has same set of external dependences and is 1 mb big. I think we 
> should care for 1mb. I don't yet know what uses this.
> 
> libQtDBus has same set of external dependencies as QtCore + QtXml + libdbus. 
> Libdbus + libQtDBus is around 1 mb of extra space and isn't used for quite 
> many things.
> 
> libQtTest has same set external dependencies as QtCore. is 56k big. no need 
> to 
> talk about that.
> 
> This is libqt4-core package.
> 
> 
> libQtGui is used by all gui libraries.
> 
> libQtSvg has the same external dependencies as QtGui. Internally it also 
> pulls 
> in QtXml.  libQtSvg is 275K big.
> 
> libQtOpenGL pulls quite some more dependencies in compared to QtGui (libGL, 
> libGLU, libXdamage, libXxf86vm,libdrm) - but I guess most people still have 
> those installed. QtOpenGL is 500k big
> 
> Is libQtDesigner, libQtDesignerComponents, libQtAssistantClient anything but 
> private libraries of designer and assistant ? and shouldn't they be around 
> them?
> 
> 
> libQt3Support fits nicely in its own package
> 
> 
> libQtSql:
> pulls in all sorts of evilness. and I still don't think we support everything.
> we build in the support for postgresql, mysql, sqlite and sqlite 2. All this 
> can be as modular packages so people don't have to pull in postgresql to get 
> mysqlsupport and the other way around.
> This way, we could also support firebird and odbc
> 
> 
> and for completeness:
> QtWebkit is 10 mb big - and pulls in Gui, Network, XMl - and libsqlite.
> 
> 
> And for the -dev stuff.
> Several people would like to have the possibility to not pull in everything 
> in 
> order to do development. especially the huge QtSql module has had some 
> complaints.
> Some people would also like qmake in a special package.
> A split like the following:
> libqt4-dev: empty meta package depending on the following
> libqt4-gui-dev: gui dev stuff
> libqt4-core-dev: core dev stuff (could also contain the dev stuff for the 
> libraries gets splitted off)
> libqt4-sql-dev: sql stuff.
> 
> I guess we should put qmake either in its own package - or among the core dev 
> stuff. 
> I would like to not have qmake in a seperate package, as it kind of 
> encourages 
> people to use it for anything - while it is only a nice tool for qt 
> development.
> 
> 
> Things to make sure to consider:
> a package called libqt4-core cannot contain any less functionality than 
> libqt4-core does today. that means we have to rename the package if we split 
> stuff off. similar for all other packages.
> 
> there might be a abi breakage on mips in qt4.4, so we might need a package 
> name change here anyway.
> 
> 
> Recomendations:
> 
> Take libqt4-core, split off libqtscript4 and libqtdbus4 to its own packages 
> and rename libqt4-core to libqtcore4
> 
> keep libqt4-gui as is
> 
> rework libqt4-sql to make it plugin based, which it supports and enable the 
> rest of the avilable database connectors
> 
> split libqt4-dev, but keep libqt4-dev as a meta package.
> 
> (move some translations and other data files to correct packagages - 
> translations for assistant is in -core for example)
>

I have not looked in deep to this, but sounds reasonable. If fabo and pyro who 
are the other people working 

Re: when jump to 4.1.X

[Ana Guerrero]

On Mon, Feb 04, 2008 at 11:37:29PM +0100, Fathi Boudra wrote:
> > I meant with the question how active is going the development of the branch
> > 4.1 (current trunk), in the sense of reaching the 4.1 release goals.
> 
> The links we need to look at:
> http://techbase.kde.org/index.php?title=Schedules/KDE4/4.1_Release_Goals
> http://techbase.kde.org/index.php?title=Schedules/KDE4/4.1_Feature_Plan
> 
> I think the main problem will be plasma release goal.
> They need Qt4.4, then rewrite plasma API AFAIK.

good thing is plasma is not in the packages we are shipping in lenny, so we can 
break stuff in experimental more or less happily :)


> Maybe we need to follow kdepim module activity closer.

More stuff that will be in experimental.

So, anybody thinks this is a bad idead? answer please! :-)


Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: gmm

[Ana Guerrero]

On Thu, Feb 07, 2008 at 02:49:27PM -0500, Matthew Rosewarne wrote:
> I already have a package for GETFEM++, which GMM is a part of, but I haven't 
> released it yet, since there were copyright problems with upstream.  After 
> informing them, they've been getting things cleaned up, but I've been waiting 
> for them to release before uploading the package.  I could probably make this 
> package ready and put it somewhere temporary.

Ok, ping me when this is cleared and we can upload gmm to the archive.
For now, I'm uploading koffice2 without gmm support. 

Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Important for KDE 4 users: KDE 4.0.3 and KDE 4.1 trunk

[Ana Guerrero]

Hi,

KDE 4.0.3 will be released tomorrow, but it won't be upload to Debian.
Instead, we, the KDE packagers, have started to work directly on KDE 4.1. We
are currently uploading packages to experimental with  a trunk snapshot from 
KDE's subversion. They are those packages named 4.0.6X+svn

This 4.0.6X packages include _big changes_ in some packages, specially new 
stuff that made some packages go to NEW first, the upgrade path from 3.5.9 
is not fully tested/fixed, and they are being uploaded for i386. 
So if you are using another arch different of i386, you will have to wait
maybe 2 weeks or so for having packages for you arch, and if you are using 
i386 you still will have to wait packages be accepted in NEW and do not be 
surprised if they do not update fine.

My personal piece of advise:

a) if you are a 3.5.9 user waiting to test KDE 4, wait for at least a month
and then we trust KDE 4 packages in experimental will be nice to install and
KDE 4.1 will be nice to use as well.

b) if you are a 4.0.2 user, wait at least 2 weeks.


As always, pretty please only report bugs against pacckages in experimental
when it is clearly a Debian packaging related bug, for bugs in KDE desktop
itself, please use KDE's bugzilla.

Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

KDE version in Lenny: KDE 3.5.9 vs KDE 4.1

[Ana Guerrero]

Hi folks,

We have been delaying taking a decision about this for too much time now, 
the freeze is coming up [0], and we need to have it clear, for our users, 
the release team and the rest of Debian.

Basically we can ship either KDE 3.5.9 or KDE 4.1. For some people in the team
it seems clear we should ship KDE 4.1, for some other it is clear we should 
ship KDE 3.5.9. The latter is my opinion, so here you have a mail explaining 
why we should release with 3.5.9. Feel free to reply with a nice mail of why 
we should ship with KDE 4.1, detailing as well how much time *you* are planning 
to invest in this goal.
By the way, my proposal is shipping KDE 3.5.9 with the KDE 4.1 development 
platform: kde4libs, kdepimlibs and kdebase-runtime.


- No huge advantages in shipping KDE 4.1
Honestly, I do not see any advantage in shipping KDE 4.1 instead of KDE 3.5.9 
besides of coolness and bleeding-edge stuff. I do see this movement more like 
a change of desktop than an improved new version of KDE. The KDE 4 series 
clearly represent a big change in innovation and improvement over KDE 3, 
something that has just started. KDE 4 will have a lot of to tell in the 
future (4.2, 4.3..), you only have to see how much it has improved from 4.0 to 
4.1 beta 1. But I do not see KDE 4.1 still fully replacing all the necessities 
of our users. There is still a bunch of small details there and here, 
I will talk of some here further on this mail (for example, koffice), but 
what worries me here specially is that some are totally unknown for us, 
since we have a lot of users with very different use cases. 

- KDE 4.1 has not been released yet.
KDE 4.1 has not been released yet, looking at the release schedule [1], it is 
supposed to be released July 29th, this is already impossible with current 
Lenny's release, and we would need an exception from the release team that 
will be only granted if it is really worth it. Then, a delay in this schedule 
from KDE release team would be bad for us, since we are so tight in time.
The sooner we could upload something to unstable would be with the RC1 that 
will be released on the 15th of July, 2 weeks before the final version. 
Lenny is supposed to go into full freeze in the mid of July, this could be 
delayed, but what is sure libraries will be frozen in 3-4 weeks, and we need 
ship a huge amount of new libraries.
Besides, it is usually better ship an update of 4.1.x that contains fixes 
to the most important problems found in the 4.1.0 release.

-Build dependencies we need to take care of
And then, it is not only the KDE 4 desktop, there are a set of build 
dependencies we have to maintain and not all of them are already in unstable, 
those dependencies are: akonadi, automoc (already in unstable, but it is a
snapshot), decibel, soprano, tapioca-qt and telepathy-qt.
And we'll have soon phonon, but I do consider phonon part of KDE 4. We'll need 
to ship it anyway in order of upload the development platform to unstable.

-Some widely used apps of the KDE desktop are not ready
Even if they are not shipped with the core packages, some apps belong to the 
KDE desktop and to the KDE project. We have here Koffice, kdevelop or amarok.
I have not idea of the exact status of amarok, but I think it won't be ready. 
Amarok is one of a lot of widely used apps in the KDE desktop that won't have 
a substitute in KDE 4. There is a myriad of small apps in this situation.

Koffice 2 won't be ready so we are shipping with koffice 1 that needs some 
parts of KDE 3 to work properly (like kcontrol), so it will need some hacking 
because it is not currently fully installable in KDE 4... and it won't be 
properly integrated anyway. I'm not sure how well works kdevelop with KDE 4, 
but newer kdevelop (that needs now kdevplatform package) won't be ready.
Quanta needs as well kdevplatform, but quanta is shipped inside kdewebdev 
and it is one of the modules we have not packaged yet (together with 
accessibility and bindings).

Then you have that some interesting apps usually distributed in the core 
modules, are not yet ready, for example kpilot in kdepim. AFAIK, this is 
postponed for KDE 4.2.


-No positive feedback about shipping it
My blog post about how to install KDE 4.1 beta 1 had some feedback of other 
developers in planet and specially from users in several blogs and forums 
that linked my post. Most of the people seem to like it as in "it will be 
cool", but everybody seems to agree that it is not still a replacement 
for KDE 3 in their daily tasks.
Basically, I see 3 kinds of users: developers, power users and average 
users. KDE 4.1 could be ready for developers who are able to cope with 
the lack of some apps, mixing kde3 and kde4 without risks etc, and 
the same goes to power users. But I do not see it ready for final users, 
they won't like this (imposed) change.
We would be shipping the KDE 4.1 desktop just released, and usually in the 
community, average users wait until more advanced users are 

Re: KDE version in Lenny: KDE 3.5.9 vs KDE 4.1

[Ana Guerrero]

On Fri, Jun 06, 2008 at 12:47:54AM +0200, Sune Vuorela wrote:
> On Thursday 05 June 2008, Ana Guerrero wrote:
>

> > Basically we can ship either KDE 3.5.9 or KDE 4.1. For some people in the
> > team it seems clear we should ship KDE 4.1, for some other it is clear we
> > should ship KDE 3.5.9. The latter is my opinion, so here you have a mail
> > explaining why we should release with 3.5.9. Feel free to reply with a nice
> > mail of why we should ship with KDE 4.1, detailing as well how much time
> > *you* are planning to invest in this goal.
> > By the way, my proposal is shipping KDE 3.5.9 with the KDE 4.1 development
> > platform: kde4libs, kdepimlibs and kdebase-runtime.
> 
> My expected times:  
>  - Kde3 as desktop: 0. Maybe instead working on getting interesting kde4 apps 
> available in lenny. or maybe I will just focus on kde4 wherever that is.
>  - Kde4 as desktop: what it takes. Lots. but 15-25 h weekly should definately 
> be possible. Except week 31.
> 
>  - and I have no kde3 desktops around any more to test and work with.
>

One only man 15-25h weekly is not enough for all the testing that needs to be
done, all the answering/checking bug reports, check uploads, read mailing list
related etc. (I have not seen here more people promising devote time to this
goal)

Once kde 4.1 would be in unstable it is a fight against time and almost all
week are hard to be in VAC if you want this in lenny, but the week 31 is from 
28 July to 3 august, is *really* bad timing.. do you plan upload kde 4.1 to
unstable before leaving (release is 29th july) then do not be around for
fixing all the possible stuff you could have broken and not handling all the
issues that prevent a quick migration to testing?

> 
>  - Huge advantage with kde4
> Active upstream development, bugfixings and general work. Kde3 is dead. 
> Nothing in e.g. khtml will be fixed if it doesn't work (I encountered many 
> sites where javascripts were to advanced) (Well - except if it is something 
> really major like google front page)
> 
> Kde4 shows new ways of thingking the desktop which I feel is really 
> interesting and worth to be spreading out as soon as possible.
>

And people should have the option of switch to KDE 4.1 if they want to, you
want to force them.

> Kde4 is new and interesting and the right way to go. And a real improvement 
> to 
> debian and debian's reputation of shipping ancient software.
>

This is all personal opinion, not important here. As well, Debian have a 
reputation 
of delay from the announced date, do you want to contribute to this too?



> > - KDE 4.1 has not been released yet.
> > KDE 4.1 has not been released yet, looking at the release schedule [1], it
> > is supposed to be released July 29th, this is already impossible with
> > current Lenny's release, and we would need an exception from the release
> > team that will be only granted if it is really worth it. Then, a delay in
> > this schedule from KDE release team would be bad for us, since we are so
> > tight in time. The sooner we could upload something to unstable would be
> > with the RC1 that will be released on the 15th of July, 2 weeks before the
> > final version. Lenny is supposed to go into full freeze in the mid of July,
> > this could be delayed, but what is sure libraries will be frozen in 3-4
> > weeks, and we need ship a huge amount of new libraries.
> > Besides, it is usually better ship an update of 4.1.x that contains fixes
> > to the most important problems found in the 4.1.0 release.
> 
> I expect kde4.1 to be on time - but I actually think it is worth to delay 
> lenny for if needed.
> 

Again, let's go to the facts, we have not idea whether it will be released on
time, but we do not know for _sure_ it has not been released yet.
If you look at the release calendar, we should have already KDE 4.1 released
and in unstable, migrating, to be ok with the Lenny release calendar.

> 
> > -Build dependencies we need to take care of
> > And then, it is not only the KDE 4 desktop, there are a set of build
> > dependencies we have to maintain and not all of them are already in
> > unstable, those dependencies are: akonadi, automoc (already in unstable,
> > but it is a snapshot), decibel, soprano, tapioca-qt and telepathy-qt.
> > And we'll have soon phonon, but I do consider phonon part of KDE 4. We'll
> > need to ship it anyway in order of upload the development platform to
> > unstable.
> 
> I don't see any issues here but waving red herrings around.
> But I don't know if anything actually uses decibel, which we then could 
> ignore 
> and with that tapioca and telepathy.
> 
Build dependencies won't be a big deal i

Re: KDE version in Lenny: KDE 3.5.9 vs KDE 4.1

[Ana Guerrero]

On Thu, Jun 05, 2008 at 10:03:50PM +0200, Ana Guerrero wrote:
> proposal is shipping KDE 3.5.9 with the KDE 4.1 development 
> platform: kde4libs, kdepimlibs and kdebase-runtime.
> 

For the record, after quick talk in IRC, we are finally going for KDE 3.5.9 in
Lenny.

Ana


-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: KDE version in Lenny: KDE 3.5.9 vs KDE 4.1

[Ana Guerrero]

On Mon, Jun 09, 2008 at 07:30:24PM +0100, Miguel Figueiredo wrote:
> Hello all,
> 
> KDE3 it's upstream 'dead' and KDE4 it's the current KDE. 
> Is it possible to let each user choose which KDE he/she wants to use?
>

No, we ship either KDE 3 or KDE 4. KDE 3 is not fully dead, there is security
support. KDE 4.0 does not fully replace all the functionality of KDE 3.5.9 and
KDE 4.1 has not been released yet and it does not look like it will be ready on
time.


> I mean, anything prevents to release KDE 3.x and KDE 4.x ?
>

You have 2 versions of every program: 2 konqueror, 2 kopete, etc. Some
distributions have handled install both version using non-standard paths, that
is not allowed in Debian and usually revert the changes made too much
problems.
So it was never considered.

Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: KDE version in Lenny: KDE 3.5.9 vs KDE 4.1

[Ana Guerrero]

On Mon, Jun 09, 2008 at 09:05:14PM +0200, Ana Guerrero wrote:
> On Mon, Jun 09, 2008 at 07:30:24PM +0100, Miguel Figueiredo wrote:
> > Hello all,
> > 
> > KDE3 it's upstream 'dead' and KDE4 it's the current KDE. 
> > Is it possible to let each user choose which KDE he/she wants to use?
> >
> 
> No, we ship either KDE 3 or KDE 4. KDE 3 is not fully dead, there is security
> support. KDE 4.0 does not fully replace all the functionality of KDE 3.5.9 and
> KDE 4.1 has not been released yet and it does not look like it will be ready 
> on
> time.
>

ah, i forgot. There will be KDE 4.1.x backports for Lenny, so users can choose
install then.



-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: KDE version in Lenny: KDE 3.5.9 vs KDE 4.1

[Ana Guerrero]

On Mon, Jun 09, 2008 at 09:07:41PM +0200, Tom Albers wrote:
> Op maandag 09 juni 2008 21:05 schreef u:
> > KDE 4.1 has not been released yet and it does not look like it will be 
> > ready on
> > time.
> 
> What do you know that I don't?
>

Toma, I was talking about being on time to be on Lenny and all the work that
it requires inside Debian. Debian will be in 2-3  weeks in what you would call 
in KDE "feature freeze".

Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: KDE4 in Debian and where and when

[Ana Guerrero]

Hi Matthieu,
I am not sure to understand all the points of your mail, but here goes a try to
reply.

On Mon, Jun 09, 2008 at 10:55:27PM +0200, GALLIEN Matthieu wrote:
> Hi all
> I would like to add my opinion to that question.
> I am an happy Debian powerpc port user for 3 years and half.
> I have an old iBook G4.
> I am not able to test kde4.1 beta 1 in Debian without building myself the 
> debian packages or from kde svn.
> I do not want to build it on my old iBook, so what ?
> If debian devs whant users to test, please help users get the packages built 
> on their arch.
> I am saying that because I believe that kde4 will not be ready for Debian 
> unless it is tested. And I cannot test it because I have only obsolete 
> packages or they are not installable because others have been updated.
> I am sure that it is not only a problem of experimental powerpc buildd.

Actually, yes, it is just a problem with the experimental powerpc buildd, not
much we can do there.

> There is not really an easy way for some people willing to test to just do it.
> 

For people with i386 or amd64 it is easy to test, specially since beta1 was
uploaded for both archs, no need from the autobuilders there.
I'm afraid this cover 90% of the users :(


> I have a more general question. How the other distribution are managing their 
> unstable version ?

I have not idea. Does another distros have the concept of unstable :?

> Is it not possible to work on kde4 in debian without relying on experimental ?
No.

> Is kde4.1 really something experimental ?
Until it is released on the end of July, yes, it is experimental.
In debian the usual rule to upload stuff to experimental is: packages that are
not meant to be shipped in the next stable release.

> I thought kde4.0 was experimental and kde4.1 something working (I do not mean 
> complete, but does it crash ?).
No, kde 4.0 is not experimental. It is officially releaed since months ago and
it already have 5 revisions. It is stable for daily use, but for most of
people it does not fully replace KDE 3.

> How debian managed to include gnome 2 
> Did you wait for one year and half before shipping it ?
>

Again, I have not idea what happens in gnome-land.
You have to wait to ship it in the next stable release until this stable is
released. Usually new stufd is in the archive when it is released.

> I do not want to troll or sound harsh, but I am really convinced of the 
> problem of the chicken and egg. I also want to say thanks for your work and I 
> am sorry if my mail is the cause of hurt or pain, this is not my goal.

I'm very tired of this topic already. Getting a decision about what KDE ship
has been hard and I just want to continue working getting KDE 3.5.9 in shape
for Lenny and work in parallel in KDE 4.

Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

NEW KDE 4 fun

[Ana Guerrero]

Dear people with FTP-powers,

With the upload of the new KDE 4.1 snapshot to experimental, there are some
packages that need to go through NEW. Trying to make your and our life easier, 
here it is a little explanation.

phonon - NEW PACKAGE, it is actually splitted from kde4libs, but with some new 
 layout further that just libphonon*. You will see we wrote a nice 
 copyright file :P

kdebase-runtime - SPLIT STUFF, phonon-backend-xine was split into its own 
  package.

These two packages would need quick processing, I just uploaded phonon, until 
this package is accepted, the rest of packages are blocked, since it is a 
library needed by kde4libs to build and all KDE 4 needs kde4libs to build...:)

kdebase-runtime is not needed to build by the rest of KDE 4, but it is 
necessary 
just for run KDE 4 correctly.
Both packages are important, because we need some testing and feedback from 
users given it belongs to the part of KDE 4 we want to ship in Lenny.

The rest of the packages that will go through NEW, but are not so important:

kdebase - NEW STUFF, kdebase-plasma package
kdegraphics- NEW STUFF, libkdcraw5, libkexiv2-6, libkipi5 packages.
kdeplasmoids - RENAME SOURCE from extragears-plasma
kdepim - RENAMED SOURCE from kde4pim, named in this way due to a 
misunderstanding.


Thank you!

Ana


-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

current status

[Ana Guerrero]

20:13   mmm, let's review the current situation while we are on it
20:14   i have kde3 on its way, nothing really important here, if you are
curious about the status: http://ana.debian.net/ana/tmp/TODO.kde3
20:14   continuing with lenny
20:15   kde 4 parts in lenny, we already uploaded the first
b-d, next are kde4libs kdepimlibs and -runtime
20:15   looking at
http://techbase.kde.org/Schedules/KDE4/4.1_Release_Schedule#July_8th.2C_2008:_Tag_KDE_4.1_RC_1
20:15   it should be snapshop'ed and uploaded this weekend
20:16   only that, no really need to update the rest until rc1, i think
20:16   when uploading the RC bugs needs to be addressed
20:16   some are easy, just close, some are easy too but not fun :)
20:16   (when uploading to unstable i mean)
20:16   runtime licence stuff is not fun
20:17   indeed
20:17   at least for me
20:17   and then after that
20:17   what kde4 apps are we puhing:
20:17   okular, ktorrent? and?
20:17   Why ktorrent?
20:18   because it's kool™
20:18   It won't integrate with anything.
20:18   mukidohime: maintainers decision
20:18   since maintainer is cluefull it is ok on my side
20:18   mukidohime: okular neither :>
20:18   well, how it sounds?


-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: [Pkg-samba-maint] [ANNOUNCE] Samba 3.2.0 Available for Download

[Ana Guerrero]

On Wed, Jul 02, 2008 at 12:47:03AM -0700, Steve Langasek wrote:
> On Wed, Jul 02, 2008 at 07:28:50AM +0200, Christian Perrier wrote:
> > > This is the first stable release of Samba 3.2.0.
> 
> > OK, now we have to make the decision: shall we provide it in lenny?
> 
> > I was initially against that (too close to the release, follow release
> > managers' wish to not bump upstream versions too close from the
> > release, etc.) but upstream insisted for us to use 3.2 in our next
> > stable release.
> 
> > Steve seemed also in favour of providing 3.2 *if we can*.
> 
> > So, I'm now more inclined to say "let's go for it".
> 
> > The only blocker I see are licensing reasons. GPLv3 and programs that
> > build against libsmbclient.
> 
> > I have not investigated this yet because I think that Steve would be
> > more efficient than me on this..:-)
> 
> Here's the original list of packages I found in Debian that depended on
> libsmbclient and appeared to be licensed GPL v2 only according to
> debian/copyright:
> 
> gnome-cups-manager
> mplayer
> smbc
> smbnetfs
> 
> And then, of course, we have kdebase.
> 
> Jelmer pointed out back then that smbc is listed upstream as having an "or
> later" license.
> 
> I've inspected the gnome-cups-manager source, and all references to the GPL
> in the upstream source actually have the "or later" boilerplate.
> 
> A second look at mplayer shows debian/copyright currently quotes the "or
> later" boilerplate, so I'm willing to assume this is applicable to the whole
> work.
> 
> The current version of smbnetfs in the archive also lists "or any later
> version".
> 
> That leaves only kdebase to resolve.
> 
> I've heard from Simo Sorce, the member of the Samba Team who's responsible
> for samba packaging at Red Hat, that they consider the license issue
> resolved and that the next version of Fedora will include samba 3.2 only,
> with KDE linked against it.
> 
> Can the KDE team confirm that this is accurate, and whether the relicensing
> of kdebase applies to the 3.5.9 version currently in lenny, or if it only
> applies to KDE 4 versions?
> 
> I think either way we should try to push forward with samba 3.2 for lenny;
> it's just a question of whether we also have to invest time into getting a
> GPLv2 libsmbclient package ready.
>


When we talked about this some months ago, nobody looked at the exact KDE files 
because the main blocker was Qt3 licence, but this was updated in the beginning 
of this year to GPL v3 too and current qt3 is lenny has an updated copyright 
file.

Then, in kdebase it seems the only code that links against libsmbclient is the 
smb kioslave, the code is placed at kdebase/kioslave/smb/ and all the headers 
say GPL v2.1 or later. If somebody wants to take a quick check to see if i am
overlooking something is welcome.

About KDE 4, Qt4 is gpl v3 too and what needs libsmbclient should be looked
at, but a relicensing in this case will be easy to get, i think :)

Ana

[1] http://techbase.kde.org/Projects/KDE_Relicensing



-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Working with the tools - or around/against the tools

[Ana Guerrero]

On Thu, Jul 03, 2008 at 06:04:36PM +0200, Sune Vuorela wrote:
> [Proposal to change how we do stuff]
> 
> Hi!
> 
> Currently, when working with the changelog, we seem to in the team to have 
> our 
> own specific style, a style that requires to adapt the changelog from the 
> style 
> generated with usually recommended tools like dch and uupdate.
> 
> Every time I work around a tool, I think something is wrong. Either in the 
> tool or in my workflow.
> 
> I hereby suggest that we change our style of doing changelogs into the way 
> dch 
> does it.
> 
> Currently, we have a style like:
> 
> package (1.2.3-4) experimental; urgency=low
> 
>   +++ Changes by Joe User:
> 
>   * doing foo
>   * doing bar
> 
>   +++ Changes by Jane Hacker:
> 
>   * Something third
>   * Something fourth
> 
>   --  Team-name <[EMAIL PROTECTED]> date
> 
> where dch implements it as
> 
> package (1.2.3-4) experimental; urgency=low
> 
>   [ Joe User ]
>   * doing foo
>   * doing bar
> 
>   [ Jane Hacker ]
>   * Something third
>   * Something fourth
> 
>   -- Name of last changer <[EMAIL PROTECTED]> date
> 
> and dch does all the formatting automatically, so when Jack Third needs to 
> add 
> a entry, he just do dch "Fix typo in package description"  and the resulting 
> changelog entry says:
> 
> package (1.2.3-4) experimental; urgency=low
> 
>   [ Joe User ]
>   * doing foo
>   * doing bar
> 
>   [ Jane Hacker ]
>   * Something third
>   * Something fourth
> 
>   [ Jack Third ]
>   * Fix typo in package description
> 
>   -- Jack Third <[EMAIL PROTECTED]> date
> 
> So please. Let us adopt the way dch does it so we don't have to change and 
> adapt the changelog all the time.  This also have the advantage that doing 
> automatic processing, dch can do the changelog handling instead of own 
> scripts.
>

I do not care at all about using +++ Name or [ Name ] but when more than a
person have worked in the package I like uploading it as a team upload as we
have done until now. So not ok about changing that.

> Now speak up - and by the way, I will consider this as accepted if no one 
> speaks against it within the next weeks or so.  

This is not a nice way of handling stuff... so I send a mail with big changes
the week you are off on holidays with the same way of "agreement" and it is ok?
Sometimes mail with proposal do not have answer because well... it is not
worth answer it.

> If most people currently in 
> uploaders fields of the packages accept it, doing it quicker is also possible.
> 
Why? We have plenty of people in the Uploaders field and we all know not
everybody works the same in the team. We should try to reach concensus using
the common sense, not a majority vote that does not make sense when work is
not balanced.


Ana


-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Working with the tools - or around/against the tools

[Ana Guerrero]

On Thu, Jul 03, 2008 at 09:12:18PM +0200, Sune Vuorela wrote:
> 
> On Thursday 03 July 2008 20:46:00 Ana Guerrero wrote:
> 
> > > Now speak up - and by the way, I will consider this as accepted if no one
> > > speaks against it within the next weeks or so.
> >
> > This is not a nice way of handling stuff... so I send a mail with big
> > changes the week you are off on holidays with the same way of "agreement"
> > and it is ok? 
> 
> No one has announced being on vacation - and if people leave without a 
> announcement of vacation, we can't wait forever on them.
> 
> > We have plenty of people in the Uploaders field and we all know not
> > everybody works the same in the team. We should try to reach concensus
> > using the common sense, not a majority vote that does not make sense when
> > work is not balanced.
> 
> Do I read this as you saying "I think I do most work, so I decide" correctly ?
>

As usual, you read what you want to read and attack with wathever excuse you
have. You have people in the team-members file with have worked a lot in the 
pass and is not currently active (schepler), you have people who is limited to 
a set of stuff (dato), you have people who has barely started working with us
(pino), you have people who did 2-3 commits and not longer contributed (Sara) 
and so so. The set of the "usual workers" is 4-5 people and you have 17 listed 
in members-team.  


> And if it was about reaching consensus, we would still be discussing kde3 vs 
> kde4.

Concesus is about sometimes have to give in something realising you may be
wrong even if you do not see it.


-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Classic Debian problem

[Ana Guerrero]

So, we have in the Qt/Debian team the classic Debian problem of 2 developers 
not getting along. It started on IRC some time ago and lately has spilled
on this mailing list. It has been there for some time now, but it grow a lot
with the past KDE3/KDE4 in lenny issue.
It is killing my fun of working in KDE stuff, and I am sure it is killing the
motivation of others, because it is not nice being around when you see
this ugly enviroment in a team.

Does somebody have a idea of how to handle this? I have been trying to handle 
this on my best way, but every time I give some ground with the goal of trying 
to find some common ground it does not work from the other side.


Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: rev 11376 - in branches/kde4/packages/kdebase-workspace/debian: . patches

[Ana Guerrero]

On Mon, Jul 07, 2008 at 05:38:11PM +0200, Sune Vuorela wrote:
> 
> 
> On Monday 07 July 2008 16:54:26 Ana Beatriz Guerrero López wrote:
> 
> >
> > -* ksysguard now depends on ksysguardd.
> > +  * ksysguard now recommends on ksysguardd.
> >
> 
> > Modified: branches/kde4/packages/kdebase-workspace/debian/control
> > ===
> > --- branches/kde4/packages/kdebase-workspace/debian/control 2008-07-07
> > 14:25:58 UTC (rev 11375) +++
> > branches/kde4/packages/kdebase-workspace/debian/control 2008-07-07 
> > 14:54:26
> > UTC (rev 11376) @@ -132,7 +132,8 @@
> >  Package: ksysguard
> >  Section: admin
> >  Architecture: any
> > -Depends: ${shlibs:Depends}, ksysguardd (= ${binary:Version})
> > +Depends: ${shlibs:Depends}
> > +Recommends: ksysguardd (= ${binary:Version})
> >  Description: System Guard for KDE 4
> >   KDE System Guard allows you to monitor various statistics about your
> > system. .
> 
> This is wrong.
> 
> You are trading less than 300K for a bad user experience - and even 300K that 
> there is a big chance that people already have installed. And kde3 also have 
> the same dependency.

Problem here about "bad user experience" is the not clear error message, we
should ask upstream change it.

> Please revert or come with a *justification* other than "I don't use it". 
> 

ksysguard can do some stuff without ksysguardd, plus you can use it for remote
monitoring, so ksysguardd is *optional*. Most of users have recommends by
default, and users who are cluefull to remove recommends by default know how
to read package descripts as well and install kssysguard if they want it.

> 
>  - and please don't hide the changes in your commit messages.
>

I did not  :?



-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: rev 11376 - in branches/kde4/packages/kdebase-workspace/debian: . patches

[Ana Guerrero]

On Mon, Jul 07, 2008 at 07:24:59PM +0200, Sune Vuorela wrote:
> 
> 

..

I will forward you back to the recent discussion on IRC.


-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: rev 11376 - in branches/kde4/packages/kdebase-workspace/debian: . patches

[Ana Guerrero]

On Tue, Jul 08, 2008 at 01:44:58PM +0200, Xavier Vello wrote:
> I don't mind if ksysguard depends on ksysguardd or just recommends it, but I 
> want that the kdebase-workspace metapackage depends on it, because IMHO
> it's a metapackage's purpose to depend on everything provided by the archive. 
> I commited it and someone reverted without explanation.
> Furthermore, it would fix the issue of users not getting it if they disable 
> recommends, while letting the powerusers remove it.
> 
> So that's what I propose : 
>   ksysguard recommends ksysguardd
>   kdebase-workspace depends on ksysguardd
>

I would agree on this.


-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: klaptopdaemon uses obsolete methods.

[Ana Guerrero]

Hi

On Thu, Jul 10, 2008 at 01:21:32AM +0200, Raúl Sánchez Siles wrote:
>   Hello All:
> 
>   As you may know there have been some bugs that end up to be reported 
> against 
> klaptopdaemon(3.5.9), IMO the main one is this: [1] which derived in [2] that 
> in turns come from [3].
> 
>   In summary, klaptopdaemon rely on some methods to check ac presence and 
> battery status which have been deprecated on 2.6.25+ Debian GNU/Linux 
> Kernels. This problem is specific to GNU/Linux kernels, so kfreebsd should 
> still work (confirmation appreciated). AFAIK, GNU/Hurd is not supported by 
> klaptopdaemon.
> 
>   The problem is exactly that latest Debian GNU/Linux kernels are build 
> without the option: ACPI_PROCFS_POWER which provided the battery and ac 
> interfaces on /proc/acpi/{ac,BAT} on what klaptopdaemon relied on.
> 
>   In order to fix klaptopdaemon, the ACPI_PROCFS_POWER option should be 
> reenable, which is not likely [3] or klaptopdaemon should be intrusively 
> patched. No need to remind that KDE3 development is stalled, so we can't wait 
> upstream commit such an important change. Well, TBH maybe the changes are not 
> that difficult to implement. Most of the code involved is in the portable.cpp 
> source file, but IMHO testing such a case being the release so close is not 
> advisable.
> 
>   Thus I think klaptopdaemon is unfixable for lenny and and alternative path 
> should be evaluated. I think we should go for kpowersave as a klaptopdaemon 
> substitute. Since I'm not myself a kpowersave user I can't tell how stable it 
> is and what inconveniences could it bring for lenny.
> 
>   I'm just build a testing kernel and I'll use kpowersave from now on, 
> testing 
> it as thoroughfully I can.
> 
>   I hope to bring more feedback soon. Needless to say that any 
> comments/experiences are wellcome.
>

Thanks a lot for looking at this. I have updated to kernel 2.6.25 (I was still
using 2.6.22 to avoid iwlwifi...), and stated using kpowersave, and so far it
is good.
Question after reading your mail is: what kernel version will be in Lenny?
2.6.24 or 2.4.25?

Ana
PS: Michael, i have cc'ed you in case you have something interesting to say
wrt kpowerposave.


-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: klaptopdaemon uses obsolete methods.

[Ana Guerrero]

On Thu, Jul 10, 2008 at 09:38:42AM +0200, Sune Vuorela wrote:
> 
> 
> On Thursday 10 July 2008 09:27:03 Ana Guerrero wrote:
> 
> > Question after reading your mail is: what kernel version will be in Lenny?
> > 2.6.24 or 2.4.25?
> 
> .25 is fallback. .26 is the kernel teams planed kernel.  
>

.26? really? it is not even in experimental. we'll see :)



-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

kde 4.1.x backports for Lenny, best approach?

[Ana Guerrero]

Hey,

I have been thinking what is the best way to do the 4.1.x backports to Lenny.
Basically, I see 2 options:

a) Use backports.org, i do not like this too much because:

cons:
  -you need to wait until package is in testing to backport it
  -packages go to NEW until they are hand approved
  -users will fear to push more stuff than just KDE 4.1.x

pros: it has support for most used archs, and it is autobuilt.

b) Search for a mirror space where optionally (but very welcome) reprepo
can be used. The domain kde4.debian.net could be pointed there.

cons:
  -need to get mirroring somewhere.
  Debian machines are sometimes used for this, but i do not think it is a good
  idea given the sizes of the KDE packages.
  -only able to upload packages for amd64/i386, no powerpc.

pros: 
  - dos not have any of the cons of a)


Suggestions?


Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Current status of KDE for Lenny

[Ana Guerrero]

Hi!

As you already know, the next stable release will be shipping with KDE 3.5.9. 
Current packages have been updated addressing serious issues, doing some bug 
cleanup and including latest fixes from KDE's SVN.
There is a KDE 3.5.10 release planned for mid august, but by then Lenny
will be (hopefully) frozen. So it looks like Lenny will have to miss the 
"release number bump" hype but 3.5.10 will not be very different to the 
3.5.9 packages that we currently have in unstable.
 

We want to ship as well KDE 4.1 core libraries and data that are co-installable 
with KDE 3, this is the following packages: kde4libs, kdepimlibs and 
kdebase-runtime.
Together with this, they are meant to be released in Lenny the following KDE 4
apps that we think add huge improvements and will be really useful for our
users:
-okular, the new KDE 4 document viewer. (source split from KDE 4's kdegraphics)
-ktorrent. (KDE 3's ktorrent is being kept as ktorrent 2.2, for users who
prefers integration with KDE 3)
-systemsettings, to allow configure settings in the KDE 4 apps installed.
(source split from kdebase-workspace)

There is python-kde4 as well, but I do not know the status of this package.

All this is already uploaded to unstable and only problem with respect
migration is hppa that has not cmake 2.6 and current packages build system
is made assuming this version. (The problem is derived from hppa's glibc
problems, FWIW)

The packages are in very good shape (no, this is not just maintainers proud
:)) and the update from current RC1 to final release (due to 29th July) for
kde4libs/kdepimlibs/kdebase-runtime should be smooth.

We have delayed uploading this to unstable mostly because it was not finished
stuff and wanted to be comletely sure it was ok for release. Else, to avoid 
people uploading KDE 4 applications to unstable that were not ready yet. 
(This still has happened tho, see rkward). 


Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Current status of KDE for Lenny

[Ana Guerrero]

On Mon, Jul 21, 2008 at 09:03:42PM +0200, Pierre Habouzit wrote:
> On Mon, Jul 21, 2008 at 05:44:23PM +, Moritz Muehlenhoff wrote:
> > On 2008-07-19, Ana Guerrero <[EMAIL PROTECTED]> wrote:
> > > Hi!
> > >
> > > -okular, the new KDE 4 document viewer. (source split from KDE 4's 
> > > kdegraphics)
> > 
> > Is it indended to replace or accompany kpdf for Lenny?
> 
>   I hope not, okular isn't a decent replacement for kpdf for me yet.

seriuosly? first time I have read somebody prefer kpdf over okular.

And no, it is just adding some kde4 stuff, no planning to replace it for kde3
stuff. Some people prefer the integration with the desktop.

Sorry Moritz, kpdf will be waiting for security fixes of xpdf in the next
release too :)


Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Step

[Ana Guerrero]

On Wed, Jul 30, 2008 at 11:13:05AM +0200, Julien RF wrote:
> Hi,
> 
> Why isn't Step [1] still available in your packages ?
> 

Because it does need Gmm++ 3.0 (A generic C++ template library for sparse, dense
and skyline matrices), that is not in the debian archive.

Ana


[1] http://home.gna.org/getfem/



-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Step

[Ana Guerrero]

On Wed, Jul 30, 2008 at 02:25:49PM -0400, Matthew Rosewarne wrote:
> On Wednesday 30 July 2008, Ana Guerrero wrote:
> > Because it does need Gmm++ 3.0 (A generic C++ template library for sparse,
> > dense and skyline matrices), that is not in the debian archive.
> 
> The GETFEM++/GMM++ packaging is mostly complete in krap/, I believe it may 
> only need some minor copyright tweaking.

Could you look at it and finish the package?

Thanks,
Ana


-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: kdelibs 4.1.0-3 targeting Lenny

[Ana Guerrero]

On Sat, Aug 09, 2008 at 08:36:25AM +0200, Fathi Boudra wrote:
> Hi,
> 
> on r11881, I have updated kross to version 11, needed to build latest 
> kdevplatform and kdevelop4 (See also Debian bug #491272).
> 
> IMHO, it could be nice to have this version in Lenny.
> 
> opinions ?
> 
Problem: how are you convince people doing the hand-reviews this is a needed
fix?

Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

unblocks of KDE 4 related packages

[Ana Guerrero]

Hola,

Could you please unblock the following KDE 4 related packages:

kdebase-runtime/4:4.1.0-2 
 Version 4:4.1.0-1 got an automatic unblock when freeze, but -2 was needed to
 apply a patch and get it building in arm/el. There is S-V update that does
 not make me very happy either, but I expect people who bumped it, did check 
 at it.

okular/0.7-2
 Version 0.6.90-1 got an automatic unblock when freeeze. But we did need
 sucesive uploas for add fixes for FTBFS, -dbg and translations package.
 So it was in NEW by freeze time.

Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: DEAD LINK: debian-40r3-i386-kde-CD-1.iso

[Ana Guerrero]

On Thu, Aug 28, 2008 at 03:00:17AM +0100, [EMAIL PROTECTED] wrote:
> DEAD LINK
> 
> http://cdimage.debian.org/debian-cd/4.0_r3/i386/iso-cd/debian-40r3-i386-kde-CD-1.iso

You want:
http://cdimage.debian.org/debian-cd/4.0_r4a/i386/iso-cd/debian-40r4a-i386-kde-CD-1.iso

Fixing website now.

Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: "for KDE" ...

[Ana Guerrero]

On Fri, Sep 05, 2008 at 02:05:39PM +0200, Sune Vuorela wrote:
> On Friday 05 September 2008 13:50:52 Ana Beatriz Guerrero López wrote:
> > Author: ana
> > Date: 2008-09-05 11:50:52 + (Fri, 05 Sep 2008)
> > New Revision: 12095
> 
> (This is just a random commit chosen - but the issue is more generic)
> 
> > -Description: hexeditor for binary files
> > - okteta is a KDE 4 related hexeditor
> > +Description: hexeditor for binary files for KDE 4
> 
> I really dislike the "for KDE" part in descriptions, because that way we are 
> telling users of other window managers and desktop environments that this 
> application is not for them.
> 
> okteta for example is just a hexeditor using kde libraries and built from the 
> kdeutils source package.
> I don't mind at all mentioning kde somewhere in the long description, but I 
> think the short description should mention what the program do and not what 
> libraries it uses nor what programming language it is using.
> 
> (exemptions to this is of course sthings that are for KDE, e.g. widget styles)
> 
> Comments anyone ?

I do not care too much.
If you mention it you lose potential users, if you don't you lose potential 
users too...

Only, if we keep mentioning, then in KDE 3, states it is for kde 3 and in kde
4 that is for kde 4..


-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: rev 12185 - branches/kde4/packages/kdelibs/debian/patches

[Ana Guerrero]

On Tue, Sep 16, 2008 at 03:53:02PM +, Ana Beatriz Guerrero López wrote:
> Author: ana
> Date: 2008-09-16 15:53:02 + (Tue, 16 Sep 2008)
> New Revision: 12185
> 
> Removed:
>
> branches/kde4/packages/kdelibs/debian/patches/01_kross_version_11_r838337.diff
> Modified:
>branches/kde4/packages/kdelibs/debian/patches/series
> Log:
> fuera parches
>

Sorry, wrong repo =)
Further info: I have setup my build machine to autobuild trunk ... :-)

> 
> Deleted: 
> branches/kde4/packages/kdelibs/debian/patches/01_kross_version_11_r838337.diff
> 
> Modified: branches/kde4/packages/kdelibs/debian/patches/series
> ===
> --- branches/kde4/packages/kdelibs/debian/patches/series  2008-09-16 
> 14:05:44 UTC (rev 12184)
> +++ branches/kde4/packages/kdelibs/debian/patches/series  2008-09-16 
> 15:53:02 UTC (rev 12185)
> @@ -1,4 +1,3 @@
> -01_kross_version_11_r838337.diff
>  08_add_debian_build_type.diff
>  09_disable_debug_messages_if_not_explicitly_enabled.diff
>  11_kde4_applications_menu.diff
> 
> 
> -- 
> http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-commits

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: libdecibel issue

[Ana Guerrero]

On Mon, Sep 29, 2008 at 09:54:50AM -0700, Anjum Kaiser wrote:
> Hi,
> 
> I'm trying to build kdenetwork from experimental tree.
> apt-build build-dep kdenetwork keeps complaining about missing libdecibel-dev 
> package.
> Can anyone guide me where can i get libdecibel?
>

>From experimental.

Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: kdemultimedia build issue

[Ana Guerrero]

On Mon, Sep 29, 2008 at 12:29:32PM -0700, Anjum Kaiser wrote:
> Hi,
> 
> I'm getting this error while building kdemultimedia-4.1.1:
> 
> 
> In file included from 
> /build/apt-build/build/kdemultimedia-4.1.1/kioslave/audiocd/audiocd.cpp:30:
> /usr/include/cdda_interface.h:98: error: expected unqualified-id before 
> âprivateâ
> /usr/include/cdda_interface.h:98: error: expected â;â before âprivateâ
> /build/apt-build/build/kdemultimedia-4.1.1/kioslave/audiocd/audiocd.cpp: In 
> member function âcdrom_drive* AudioCD::AudioCDProtocol::initRequest(const 
> KUrl&)â:
> /build/apt-build/build/kdemultimedia-4.1.1/kioslave/audiocd/audiocd.cpp:224: 
> error: âstruct cdrom_driveâ has no member named âdevâ
> /build/apt-build/build/kdemultimedia-4.1.1/kioslave/audiocd/audiocd.cpp:235: 
> error: âstruct cdrom_driveâ has no member named âdevâ
> /build/apt-build/build/kdemultimedia-4.1.1/kioslave/audiocd/audiocd.cpp:237: 
> error: âstruct cdrom_driveâ has no member named âdevâ
> /build/apt-build/build/kdemultimedia-4.1.1/kioslave/audiocd/audiocd.cpp:246: 
> error: âstruct cdrom_driveâ has no member named âdevâ
> /build/apt-build/build/kdemultimedia-4.1.1/kioslave/audiocd/audiocd.cpp:247: 
> error: âstruct cdrom_driveâ has no member named âdevâ
> make[3]: *** [kioslave/audiocd/CMakeFiles/kio_audiocd.dir/audiocd.o] Error 1
> 
> any idea?
>
It is due new cdparanoia 10.2 in unstable, first problem is fixed with this
patch (it is made for 4.1.1 but should work):
http://svn.debian.org/wsvn/pkg-kde/branches/kde4/packages/kdemultimedia/debian/patches/10_r865240_cdparanoia.diff?op=file&rev=12266&sc=1

I still have not fixed the second one.

You can build against cdparanoia in testing and it will work fine.

Ana


-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Bug#500711: kdenetwork package broken dependency OS390

[Ana Guerrero]

On Tue, Sep 30, 2008 at 01:30:58PM -0400, Tom Delany wrote:
> Package: kdenetwork
> Version: 4:3.5.5-5
> Severity: grave
> Justification: renders package unusable
> 
> kdenetwork depends upon kwifimanager 4:3.5.9-4;  however kwifimanager 
> 4:3.5.9-4 is not available for the OS390 architecture.  This makes the 
> package uninstallable.
>
Does somebody have a better idea to this that making the metapackage Arch:any?

Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

About my VAC

[Ana Guerrero]

Hi folks,

I am just uploading kdelibs 3.5.10 and with this I am done with KDE 3 
for Lenny. Now we kind of can say Lenny is being released with 3.5.10,
but it will be only partially true :P

For the next month (actually take it like 4-6 weeks) I am not planning to
do any Debian stuff. The current status of the project got me frustrated, 
and I am going to take a time and doing another stuff I have in my TODO 
but kept postponing because Debian.

This means you will see me around sometimes, but do not expect work from me.
I won't work in KDE 4.1.3 (or 4.1.4) or start working in 4.2.0. (I am currently
using 4.2 in the computer where I use kde4, but it is built with kdesvn-trunk)
I will do the backports for the 4.1.x series, but it will take some time.

After this time, I will be at least resumming my work in koffice, and kde-l10n,
unless somebody uber-motivated wants to jump into taking caring of these 
packages. 
I started looking after koffice due to Isaac's inactivity, but I have  to say 
I have ended using it more (due to my current work mostly), and I enjoy 
maintainting it. About kde-i18n/l10n, it was because it seemed nobody else
was interested in the team. It is a huge package, but really easy to maintain.
It is more like somebody who does not mind in uploading it.

About the rest of KDE stuff, i still have to make my mind about it.
And yes, I am really hoping we would have released by the end of the year.

Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: rev 12549 - branches/kde4/packages/kdebindings/debian

[Ana Guerrero]

As promised, I will do the backports, taking a look to the commits for 4.1.3,
this took my attention...

On Tue, Nov 04, 2008 at 07:43:10PM +, Vincent Fourmond wrote:
> Author: fourmond
> Date: 2008-11-04 19:43:09 + (Tue, 04 Nov 2008)
> New Revision: 12549
> 
> Added:
>branches/kde4/packages/kdebindings/debian/watch
> Modified:
>branches/kde4/packages/kdebindings/debian/changelog
>branches/kde4/packages/kdebindings/debian/control
>branches/kde4/packages/kdebindings/debian/copyright
> Log:
> [kdebindings] Vcs-* fields + watchfile
>

...

> --- branches/kde4/packages/kdebindings/debian/copyright   2008-11-04 
> 07:57:54 UTC (rev 12548)
> +++ branches/kde4/packages/kdebindings/debian/copyright   2008-11-04 
> 19:43:09 UTC (rev 12549)
> @@ -1,6 +1,6 @@
>  This package was debianized by the Debian Qt/KDE maintainers in 2008.
>  
> -This package is fetched from ftp://ktown.kde.org
> +This package is fetched from ftp://ktown.kde.org/pub/kde/unstable/
>  
>  Upstream authors and copyright holders:
>  Copyright (C) 1989, 1991, 1999 Free Software Foundation, Inc.
>

I have seen like 3 commits changing this line, for the sake of consistence,
i would keep it like the rest of the KDE 4 packages:

It was downloaded from ftp://ftp.kde.org

which I think it is the most appropiate information to this field, not ktown,
just use the kde canonical mirror.

OTOH, it is not unstable, kdebindings 4.1.x is released as stable.

> Added: branches/kde4/packages/kdebindings/debian/watch
> ===
> --- branches/kde4/packages/kdebindings/debian/watch   
> (rev 0)
> +++ branches/kde4/packages/kdebindings/debian/watch   2008-11-04 19:43:09 UTC 
> (rev 12549)
> @@ -0,0 +1,2 @@
> +version=3
> +ftp://ktown.kde.org/pub/kde/unstable/([\d\.]+)/src/kdebindings-([\d\.]+)\.tar\.bz2
> 
> 

Again, it is stable, and not sure we need watch files for KDE, but *shrug*.

ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: kipi-plugins 0.2.0 beta3 and KOffice 2.0 beta 3 packages

[Ana Guerrero]

On Fri, Nov 21, 2008 at 09:45:23PM +0100, Matthias wrote:
> Hi!
> 
> Please tell me if you plan to provide debian packages for kipi-plugins 0.2.0 
> beta3 and koffice 2.0 beta3 in experimental.
>

koffice 2.0 beta3 is very unlikely to be uploaded to experimental, you have
the beta2 and using its packaging beta3 should be straightforward to build.
Beta 4 is scheduled for mid-december, and do not worry that one will make
experimental together with translations.

I do not maintain kipi-plugins, so no idea.

Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: kipi-plugins 0.2.0 beta3 and KOffice 2.0 beta 3 packages

[Ana Guerrero]

On Sun, Nov 23, 2008 at 10:17:49PM +, Beojan Stanislaus wrote:
> On Sunday 23 November 2008 21:07:24 Ana Guerrero wrote:
> > On Fri, Nov 21, 2008 at 09:45:23PM +0100, Matthias wrote:
> > > Hi!
> > >
> > > Please tell me if you plan to provide debian packages for kipi-plugins
> > > 0.2.0 beta3 and koffice 2.0 beta3 in experimental.
> >
> > koffice 2.0 beta3 is very unlikely to be uploaded to experimental, you have
> > the beta2 and using its packaging beta3 should be straightforward to build.
> > Beta 4 is scheduled for mid-december, and do not worry that one will make
> > experimental together with translations.
> >
> > I do not maintain kipi-plugins, so no idea.
> >
> > Ana
> 
> Can you tell me whether there is any plan to package the KOffice2 version of 
> Kexi when Koffice2 beta 4 is packaged?
>

There is not plan to package it, since kexi (Kivio and KFormula) is not being 
released as part of KOffice 2.0

Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: kipi-plugins 0.2.0 beta3 and KOffice 2.0 beta 3 packages

[Ana Guerrero]

On Sun, Nov 23, 2008 at 09:28:59PM -0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Sorry Ana, this should have gone to the list
> 
> On Sun, Nov 23, 2008 at 9:27 PM, Lisandro Damián Nicanor Pérez Meyer
> <[EMAIL PROTECTED]> wrote:
> > On Sun, Nov 23, 2008 at 7:07 PM, Ana Guerrero <[EMAIL PROTECTED]> wrote:
> > [snip]
> >> koffice 2.0 beta3 is very unlikely to be uploaded to experimental, you have
> >> the beta2 and using its packaging beta3 should be straightforward to build.
> >
> > Is there anything I can do to reverse this? I mean, perhaps it needs
> > some test or something like that in order to upload it. Or maybe
> > there's another reason not to upload it :-)
> >

IIRC you have commit access, so improve/fix what you think that needs to be
done and commit it.
The problem is on my side, because I am not going to review, test and so on, 
you changes and then upload (nothing against you, just I can not do that
currently). And I am not sure somebody else will volunteer.
But whatever you do will be done for beta4 which i am planning to upload.

BTW, beta4 will be released by the 10th of December, i will upload it to
Debian, but do not expect it in the repos exaclty that day...


Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: rev 12740 - branches/kde4.2/packages/kdelibs/debian

[Ana Guerrero]

I do not remember well about this. So question:

did not we move this for co-installibility reasons?

Ana

On Thu, Nov 27, 2008 at 11:43:02PM +, George Kiagiadakis wrote:
> Author: gkiagia-guest
> Date: 2008-11-27 23:43:02 + (Thu, 27 Nov 2008)
> New Revision: 12740
> 
> Modified:
>branches/kde4.2/packages/kdelibs/debian/kdelibs-bin.install
>branches/kde4.2/packages/kdelibs/debian/kdelibs5-dev.install
> Log:
> Move development binaries from kdelibs-bin back to kdelibs5-dev, as
> they used to be in 4.1.x packages. They were accidentally moved to -bin.
> 
> 
> Modified: branches/kde4.2/packages/kdelibs/debian/kdelibs-bin.install
> ===
> --- branches/kde4.2/packages/kdelibs/debian/kdelibs-bin.install   
> 2008-11-27 21:57:15 UTC (rev 12739)
> +++ branches/kde4.2/packages/kdelibs/debian/kdelibs-bin.install   
> 2008-11-27 23:43:02 UTC (rev 12740)
> @@ -1,6 +1,4 @@
> -usr/bin/checkXML
>  usr/bin/kbuildsycoca4
> -usr/bin/kconfig_compiler
>  usr/bin/kcookiejar4
>  usr/bin/kde4-config
>  usr/bin/kded4
> @@ -11,11 +9,8 @@
>  usr/bin/kjscmd
>  usr/bin/kross
>  usr/bin/kshell4
> -usr/bin/kunittestmodrunner
>  usr/bin/kwrapper4
> -usr/bin/makekdewidgets
>  usr/bin/meinproc4
>  usr/bin/nepomuk-rcgen
> -usr/bin/preparetips
>  usr/lib/libkdeinit4_kbuildsycoca4.so
>  usr/lib/libkdeinit4_kded4.so
> 
> Modified: branches/kde4.2/packages/kdelibs/debian/kdelibs5-dev.install
> ===
> --- branches/kde4.2/packages/kdelibs/debian/kdelibs5-dev.install  
> 2008-11-27 21:57:15 UTC (rev 12739)
> +++ branches/kde4.2/packages/kdelibs/debian/kdelibs5-dev.install  
> 2008-11-27 23:43:02 UTC (rev 12740)
> @@ -1,3 +1,8 @@
> +usr/bin/checkXML
> +usr/bin/kconfig_compiler
> +usr/bin/kunittestmodrunner
> +usr/bin/makekdewidgets
> +usr/bin/preparetips
>  usr/include/KDE/ConversionCheck/QVconvertible
>  usr/include/KDE/ConversionCheck/type_toQString
>  usr/include/KDE/ConversionCheck/type_toQVariant
> 
> 
> -- 
> http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-commits

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: rev 12740 - branches/kde4.2/packages/kdelibs/debian

[Ana Guerrero]

On Thu, Dec 11, 2008 at 06:38:41PM +0100, Sune Vuorela wrote:
> On Thursday 11 December 2008 17:09:10 Ana Guerrero wrote:
> > I do not remember well about this. So question:
> >
> > did not we move this for co-installibility reasons?
> 
> We moved for many reasons. Coinstallability is one, but general "they are not 
> needed by normal user" is also important.
>

Yes, yes. Let me re-ask: we did not break co-installibility with those changes
right?

Ana


> /Sune
> 
> > Ana
> >
> > On Thu, Nov 27, 2008 at 11:43:02PM +, George Kiagiadakis wrote:
> > > Author: gkiagia-guest
> > > Date: 2008-11-27 23:43:02 + (Thu, 27 Nov 2008)
> > > New Revision: 12740
> > >
> > > Modified:
> > >branches/kde4.2/packages/kdelibs/debian/kdelibs-bin.install
> > >branches/kde4.2/packages/kdelibs/debian/kdelibs5-dev.install
> > > Log:
> > > Move development binaries from kdelibs-bin back to kdelibs5-dev, as
> > > they used to be in 4.1.x packages. They were accidentally moved to -bin.
> > >
> > >
> > > Modified: branches/kde4.2/packages/kdelibs/debian/kdelibs-bin.install
> > > 
> ===
> > > ---
> > > branches/kde4.2/packages/kdelibs/debian/kdelibs-bin.install   
> 2008-11-27
> > > 21:57:15 UTC (rev 12739) +++
> > > branches/kde4.2/packages/kdelibs/debian/kdelibs-bin.install   
> 2008-11-27
> > > 23:43:02 UTC (rev 12740) @@ -1,6 +1,4 @@
> > > -usr/bin/checkXML
> > >  usr/bin/kbuildsycoca4
> > > -usr/bin/kconfig_compiler
> > >  usr/bin/kcookiejar4
> > >  usr/bin/kde4-config
> > >  usr/bin/kded4
> > > @@ -11,11 +9,8 @@
> > >  usr/bin/kjscmd
> > >  usr/bin/kross
> > >  usr/bin/kshell4
> > > -usr/bin/kunittestmodrunner
> > >  usr/bin/kwrapper4
> > > -usr/bin/makekdewidgets
> > >  usr/bin/meinproc4
> > >  usr/bin/nepomuk-rcgen
> > > -usr/bin/preparetips
> > >  usr/lib/libkdeinit4_kbuildsycoca4.so
> > >  usr/lib/libkdeinit4_kded4.so
> > >
> > > Modified: branches/kde4.2/packages/kdelibs/debian/kdelibs5-dev.install
> > > 
> ===
> > > ---
> > > branches/kde4.2/packages/kdelibs/debian/kdelibs5-dev.install  
> 2008-11-27
> > > 21:57:15 UTC (rev 12739) +++
> > > branches/kde4.2/packages/kdelibs/debian/kdelibs5-dev.install  
> 2008-11-27
> > > 23:43:02 UTC (rev 12740) @@ -1,3 +1,8 @@
> > > +usr/bin/checkXML
> > > +usr/bin/kconfig_compiler
> > > +usr/bin/kunittestmodrunner
> > > +usr/bin/makekdewidgets
> > > +usr/bin/preparetips
> > >  usr/include/KDE/ConversionCheck/QVconvertible
> > >  usr/include/KDE/ConversionCheck/type_toQString
> > >  usr/include/KDE/ConversionCheck/type_toQVariant
> > >
> > >
> > > --
> > > http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-commits
> 
> 
> -- 
> http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: krypt

[Ana Guerrero]

Hi,

On Wed, Dec 31, 2008 at 09:54:32PM +0200, Stefanos Harhalakis wrote:
> Hello there,
> 
> I've prepared a debian package for krypt [1] (KDE GUI for managing volumes 
> encrypted with LUKS) and while looking for a sponsor, Faidon Liambotis 
> suggested that I should contact you (pkg-kde) too. Is there any special 
> procedure for creating a debian package for a kde program? Krypt only depends 
> on kdelibs4 so it should be able to be used with kde4 too (right?).
> 
> Is it OK to go-on and look for a sponsor?
> 
> [1] http://krypt.berlios.de/
>

I have seen the ITP and marked to answer to the bug number, doing it now (bug
Cc'ed).
As you might know already, after Lenny, we are replacing KDE 3 with KDE 4,
this transition will be quick but replacing all kde 3 apps for kde 4 apps,
will take sime (surely too much time). So in the meantime we'll need to keep 
kdelibs (and part of kdebase), but the ultimate goal is getting ride of that
too (and Qt3 too!) 
Even if you app only needs kdelibs, it is an app that is *integrated* with kde
3.5... I really think it is best wait until it is ported to KDE 4 then package
it.

Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: krypt

[Ana Guerrero]

Hi!

On Wed, Dec 31, 2008 at 11:58:07PM +0200, Stefanos Harhalakis wrote:
> 
> I believe that there are some arguments for including it in debian too:
> 
> a) It is not integrated. It just integrates with the desktop environment. It 
> is a single executable binary that interracts with hal and dbus. After 
> opening a luks device, the device is handled by KDE as a normal mapper 
> device. It should work for gnome and KDE4 too
> 
> b) From what I've seen, up to KDE 4.2, there is no good support for crypted 
> volumes (correct me me if I'm wrong). This little program fills the gap.
> 
> c) It's the only way (?) to have easily accessible encrypted removable 
> devices.
> 
> d) As you said, "sime". Why not have this available for that time?
> 
> e) It is a program that exists today and solves a "today's" problem. Isn't it 
> better to have this available for the next year (or more), until it is ported 
> to KDE4 or KDE4 gets support for encrypted devices?
> 
> f) Are there any drawbaks for including this in debian?
> 
> g) Isn't this what happens with all other packages? AFAIK, the KDE3->KDE4 
> transition of programs is not a debian's issue but the program's developers. 
> Why not distribute this with debian too?
> 
> Anyway, without beeing a DD, as a debian user, I'd like to have this program 
> available as a package. 
> 
> So, to conclude, just take a moment to reply with at least a simple go-on or 
> don't-go-on. I won't argue any more.
>

You are free to package it and ask people to sponsor it. Nobody can forbid you
of uploading a proper package to Debian if you find a sponsor, but think in the 
work that this will carry to the distro for maybe little gain. Your package
will be some time in unstable, yeah, but its final target won't be being in a
debian release given that squeeze (next release after lenny) will have KDE 4.

Even if some of the work is never lost time, specially if you improve your 
packaging skills, introducing a new package in the archive is also work for 
other
people in the distro like ftpmaster accepting/removing it, another developers
coordinating transitions, buildd maintainers taking care of the builds across
all the archs, kde team taking care of the reverse build depends, people who
packages stuff in what your package relies taking care too of reverse build
depends...

If you have more questions ask. I hope all the above stuff helps you to
understand what is the right thing to do here.

ana




-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: krypt

[Ana Guerrero]

On Fri, Jan 02, 2009 at 05:11:16PM +0200, Stefanos Harhalakis wrote:
> On Friday 02 January 2009, Ana Guerrero wrote:
> > > Anyway, without beeing a DD, as a debian user, I'd like to have this
> > > program available as a package.
> > >
> > > So, to conclude, just take a moment to reply with at least a simple go-on
> > > or don't-go-on. I won't argue any more.
> >
> > You are free to package it and ask people to sponsor it. Nobody can forbid
> > you of uploading a proper package to Debian if you find a sponsor, but
> > think in the work that this will carry to the distro for maybe little gain.
> > Your package will be some time in unstable, yeah, but its final target
> > won't be being in a debian release given that squeeze (next release after
> > lenny) will have KDE 4.
> 
> I believe that I cannot take such a decision myself. From my POV (as a debian 
> user) I want this program to be in debian and that's why i packaged it (as 
> expected, I'm also using it). Fotis offered to sponsor it but I don't want to 
> introduce problems to debian, so I'll follow your advice.
>
> As for KDE4, krypt will be usable for squeeze too and when the author ports 
> it 
> to KDE4 it will be ported for debian too. Having this in debian may increase 
> the interrest of other/new users for it and they may offer to do the porting 
> themeselves. As I see it, its main/only problem is that it will be replaced 
> by built-in support in KDE4 sometime in the future (perhaps in KDE 4.3) but 
> until then (1 year from now?) it is an essential tool for all 
> encrypted-USB-stick, encrypted-USB-disk and 
> laptop-with-encrypted-data-partition KDE3/4 users.
>

In case it is not clear, my advise is: if you really want to do things right,
wait for the KDE 4 port, and upload it directly to Debian. If the tool is
really so handy (not saying it is not, i just have not used it), it does not
need to be in Debian to "encourage" its porting.
Hopefully in 2 month, KDE 3.5 will be only in lenny that does not allow new 
packages and unstable will contain KDE 4.2. 


> p.s. Should I stop CCing you?
I am already subscribed to pkg-kde-talk, but i do not mind it.


-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Bug#511287: debian-installer: Should have a task for installing KDE or XFCE instead of Gnome

[Ana Guerrero]

On Fri, Jan 09, 2009 at 11:12:12AM +, Philip Hands wrote:
> 
> KDE Folks,
>   Might I suggest that the front page be modified to have a link somewhere
>   prominent, near the top, linking to the page about how to get KDE
>   installed on debian
> 
>   Also, you should note that in Lenny the default desktop can be set by 
> adding:
> 
> desktop=kde
> 
>   at the boot prompt (which you can get to by hitting  in the boot menu.
> 
>   Also, note that "desktop" in that case is an alias for 
> tasksel:tasksel/desktop
>   so it can also be preseeded by providing a line like:
> 
> tasksel tasksel/desktop string kde
> 
>   in a preseed file, so you could produce custom KDE media either by tweaking 
> the
>   {sys,iso,pxe}linux.cfg files to include "desktop=kde", or by adding a 
> preseed.cfg
>   to the root of your initrd image, containing the above line.
>

I hope the website is a bit clearer now. Still have to update the instructions
for lenny.

Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

logging of #debian-qt-kde

[Ana Guerrero]

Hi Yllar,

We have realized you are logging the URLs at #debian-qt-kde and publishing 
then publically available at http://loru.mine.nu.
We use to paste in this channel URLs with private working repos and some 
semi-private URLs from time to time. This info is not top-secret (or we 
do not publish it in a IRC channel), but we do not want it so publically 
available. Could you stop logging the urls and remove the old logs?

Ana

PS: you are logging too #debian-kde, we are fine with that (some people may
not be aware of your publich logging and publish there private urls, though).

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

kde update for Release Notes

[Ana Guerrero]

Hi,

For updating the release notes for Lenny [0], what about:



There are not huge changes in the KDE Desktop Enviroment from the version
shipped in Etch. Lenny ships an updated translation and service release of KDE
3.5 that is a mixture between 3.5.9 and 3.5.10. Modules labeled as version
3.5.9 are updated and they include mostly the same than the tenth revision.
In overall, Lenny ships 3.5.10 without  the kicker improvements shipped in
kdebase and some bug fixes in kdepim.
Lenny will be the latest stable release including a KDE 3 series environment.


Any comments? 
Proofreading for english natives is totally welcome :D

ana

[0] Current stuff is from etch:
http://www.debian.org/releases/lenny/i386/release-notes/ch-information.en.html#kde-desktop-changes



-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

[DRAFT for discussion] KDE 4.2 upload to unstable

[Ana Guerrero]

Hi folks,

So happily after Lenny is released we will move with KDE 4.2 to unstable. Here
is some drafts plans of how i think we could do it (without breaking too much 
stuff)
for starting to discuss about it.
I do not know if it will be 4.2.0 or 4.2.1 but that is not very important
here.


Important things to decide|do before:

- pkg-kde SVN cleanup and re-order (branches/kde4.2 to trunk, current trunk to
  branches/lenny/ and maybe move some stuff to attic).
- Decide if keep .kde4 or move to .kde. (already in progress)
- Write documentation of how to package KDE 4 applications. It is nice and
  hopefully it will be help to avoid crappy packaging.
- Write pseudo-policy for naming space (plasmoid, artwork, etc). (already in
  progress)
- Write some nice guide of how to report KDE bugs for Debian users, with
  special emphasis about how upstream bugs are better in the KDE bugzilla.
- Ask the release team what are they plans for transitions-queue post-lenny,
  maybe it is a good idea wait to do anything until for example, the glibc
  transition is done ... (Hi Marc)
- Mail to d-d-a with proper links with the important info for another 
  developers/maintainers.
- Something else?


Steps:

- Update b-d (aka krap & friends) in unstable: cmake, eigen, phonon, soprano, 
  strigi, akonadi, automoc, ...

- Update the KDE 4.0 development platform in unstable with the KDE 4.2
  packages (yes, kde4libs, kdepimlibs and kdebase-runtime). Then:
  - Update kde3 apps that have a KDE 4 equivalent ready: amarok, rsibreak,
yakuake, ktorrent, ...[1] Encourage people who are not in any of the KDE
teams to do it it (i.e. kmldonkey, kdiff3, yes [1] and file wish-list 
bugs). 
The stuff that needs more than the development platform will have to 
wait 
a bit.
  - File for removal of all the stuff that does not make sense anymore with
KDE 4 as default KDE (like kompose, kdeaddons, kde-i18n, kalgebra...).
Again [1]
  - Look at the stuff that is depending / recommending / suggests  kde3 parts
that won't be covered by KDE-legacy. There is for example, packages that
build depend on kdepim3 libraries...  Yes [1]
  - Also, in parallel, start some QA-ing for remove qt3 and kde3 stuff from the 
archive that is buggy, dead upstream, better new equivalent in KDE 4...
No list to be made here, it will be done little to little through all the
transition, i think.

- Upload KDE-legacy stuff. I would prefer here as new source packages with the
  suffix -legacy, at least it is needed for kdebase because there is already a
  KDE 4's kdebase. kdelibs3-legacy and kdebase3-legacy ?

- Upload the rest of KDE 4.2.x (no much later that the previous step, or not
  KDE installable in unstable! :D )

- Reintroduce kde 3 apps standalone that we think it is work it (at least pino
  wanted to package kregexpeditor). The less here, the better.

- Fix whatever needs to be fixed after replace KDE 3 with KDE-legacy. We can
  not really detect this previously and we'll have mostly to wait for bug 
reports
  here. 

- Profit.

Ideas? Suggestions? A better way of doing it?

I am sorry it is not so elaborated as I would have liked but I will be
networkless the next days and I wanted to send it already.

Ana

[1] A list of packages should be done at some point.

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

re: Uploads to Squeeze and the $KDEHOME dilemma

[Ana Guerrero]

On Tue, Feb 03, 2009 at 10:53:42PM +0100, Armin Berres wrote:
> As you all know Lenny is near, which also means that our 4.2 packages will 
> enter Unstable in the very near future. Until today, we still have not 
> decided 
> how to handle KDEHOME.
> The current situation is, that KDE 3 applications use ~/.kde and KDE 4 
> applications use ~/.kde4. The problem with this approach is, that no 
> data/settings are automatically converted to be used by KDE 4.
> 
> The question is now: should we
> a) continue to use ~/.kde4 for KDE 4 applications
> b) use ~/.kde for KDE 4 applications.
> 
> The problem with a) is, that as mentioned no data is is moved to KDE 4. The 
> problem with b) is, that we don't know for sure, if all upgrade scripts work 
> and users don't loose critical data. Apart from that users already using KDE 
> 4 
> won't find their settings copied.
> (Add here more pros and cons for either option.)
> 
> To overcome this, we had the following idea in IRC: Provide a little Qt 
> application which starts at the first KDE 4 start and allows the users to 
> copy 
> their KDEHOMEs around.
> In case we would use ~/.kde for KDE 4 the script could offer to create a 
> backup 
> in ~/.kde3 so lost data can be reverted if anything goes wrong.
> If we continue to use ~/.kde4 the application could offer to copy ~/.kde to 
> ~/.kde4.
> Non-KDE users are a bit lost here, we could document what to copy where.
> 
> So, which options do you see? What would you prefer?
> Don't forget that we have to decide/code all this before we upload kde4libs 
> to 
> unstable.
>

I would go for a) continue to use ~/.kde4 for KDE 4 applications. This option
keeps .kde for KDE3 apps data that a lot of people will have to use for some
time and for backuping in case users want to go back to KDE 3. Some people
will say here downgrades are not supported, but we all know the change from
KDE 3 to 4 won't please to everybody and it is easy keep on the safe side and do
not mess with people's data. I do not fully see KDE 4 as major upgrade of KDE
3, it is different in a lot of ways...
What could be done here is when users log first time in KDE 4 get some dialog
telling then "hey welcome to KDE 4, your settings are not migrated because X
and Y, you have this migration guide|program from migrating then"...

The option of start a migrating program instead of this warning dialog, also
works for me, but: i do not volunteer for doing or testing it and i still think 
even in this case, it is better keeping .kde4 and not moving to .kde.


Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Uploads to Squeeze and the $KDEHOME dilemma (was: Uploads to lenny and the $KDEHOME dilemma)

[Ana Guerrero]

On Wed, Feb 04, 2009 at 09:44:52AM +0800, Julian Hernandez Gomez wrote:
> Hi,
> 
> I think we should use whatever the upstream choose as default, so users will
> not get confused by the (possible) difference between upstream documentation
> and the Debian settings.
>

Documentation can be patched (and it already is).

> A debconf preconfigure dialog with an explanation of the change and that
> more information can be found in the Debian.Readme would be a good thing
> IMHO.
> 

That is debconf abuse, and configuration dialog here should be done to every
use... 

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Uploads to Squeeze and the $KDEHOME dilemma

[Ana Guerrero]

On Wed, Feb 04, 2009 at 10:46:31AM +0200, Peter Eisentraut wrote:
> Ana Guerrero wrote:
>> I would go for a) continue to use ~/.kde4 for KDE 4 applications. This option
>> keeps .kde for KDE3 apps data that a lot of people will have to use for some
>> time and for backuping in case users want to go back to KDE 3. Some people
>> will say here downgrades are not supported,
>
> Supporting downgrades even marginally would require keeping the KDE 3  
> packages around.  Is anyone committed to doing that?  Is that even  
> possible under the current package naming scheme?

You do not need to keep any package around, user X installs KDE 4.2 realizes
that does not like it, user can:
- install kde 3.5 from testing (yes, for limited time this one)
- install kde 3.5 from local apt cache or copy made on purpose.
- build his/her own kde 3.5 packages fetching debian/ from our repo
  (branches/lenny(
- go to snapshots.debian.net and fetches a copy from there.

And of course, never ever update kde...


-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: [DRAFT for discussion] KDE 4.2 upload to unstable

[Ana Guerrero]

On Wed, Feb 04, 2009 at 09:08:44AM +0100, Sune Vuorela wrote:
> On Wednesday 04 February 2009 02:38:28 Ana Guerrero wrote:
> >
> > Important things to decide|do before:
> >
...

After reading Sune's reply, I want to mention this was not a list of blockers 
or "problems" to resolve, just a list of actions we need to do. 

Agreed about continue discussion about "kde-policy-draft" in another thread.
At least I have pending to send a email with my comments about that.



About the steps:

> 
> > - Update the KDE 4.0 development platform in unstable with the KDE 4.2
> >   packages (yes, kde4libs, kdepimlibs and kdebase-runtime). Then:
> 
> I would put "upload kde4.2" here and then afterwards sort out third party 
> apps.
>

I think this can be done with some order, making things easier to everybody
who needs to coordinate with us. Specially if that can minimize the number of
transitions we can get caught or we can stall.



> > - Upload KDE-legacy stuff. I would prefer here as new source packages with
> > the suffix -legacy, at least it is needed for kdebase because there is
> > already a KDE 4's kdebase. kdelibs3-legacy and kdebase3-legacy ?
> 
> This can also wait. people can live without kcontrol for some time. and no 
> need to rename kdelibs source package. (or do you want to rename kde4libs 
> source package ?)
> 
> I would definately not make it a blocker for any thing.
> 

It is not a blocker, but I do not see why it needs to wait? Actually it could
be uploaded in any time if the source package name is different (will need
conflcits with current stuff) and people will be able to check their kde3
stuff/packages work with the legacy packages.
For sure, this will depend heavily on when people working on it considers it is
ready.


> > - Upload the rest of KDE 4.2.x (no much later that the previous step, or
> > not KDE installable in unstable! :D )
> 
> 
> > Ideas? Suggestions? A better way of doing it?
> 
> if I was to plan it, I_would just upload krap/support, wait a day or two, and 
> then slowly upload kde4.2 as we would upload any other kde release.
> 
That is more or less what i am suggesting, but just with some more delay
between libraries and rest of the stuff:
- krap/support
- 2-3 days
- kde4libs/kdepimlibs/-runtime
- between 4-6 days
- the rest.

> (no one prevents maintainers of 3rd party apps to also do something here, 
> like 
> fixing their own packages)
> 
yeah, sure.

> Fix the issues that shows and do aggressive package removal from testing to 
> get kde4.2 into testing.
> 

I think here is mostly where we differ, i see you approach is more agressive 
than
mine and getting it just done in the less time possible. I believe it can be
planned, inform people about plans and get people coordinating/doing their
stuff after we provide them the info they need. It might need more time but I
think it will make things more smoothy.
I do not see any advantage of hurrying stuff here, we have time and usually
hurries make you make silly mistakes.


> Let those who want to do kde3base packages do it and sponsor if needed.
> 
sure.

> Go over the packages removed from testing and have the maintainer fix them, 
> NMU 
> them or remove them from the archive.
> 

Again, i think if you inform, give time frames etc, no-MIA maintainers will
respond and do their stuff. 

> We will break some packages no matter what way we do it, and I really don't 
> think.
>
you do not think... what?
I agree we'll break stuff, but it can be minimized.


> If we could get some dates on when we could do it, I expect both to take 
> around a week, I at least would try to clear up big parts of my calendar for 
> that week.
>

What do you mean here with "both" ?
I do not think it will just take a week, but again I am suggesting a much more
"quiet" strategy here.

Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

kde4 policy

[Ana Guerrero]

Hello,

I just looked at the draft of the kde 4 apps policy Sune
committed at people/sune/doc/kde-policy some days ago.

There was some already some commenting in IRC from people usually reading the
commits mailing lists. Anyway, I reproduce the document here since it is
short,for the sake of people not reading it and so I can order my thoughts 
better. 


preface.tex 
--
\chapter{Preface}

This document documents how KDE packages should be named, described and 
packaged. The target audience of 
this document is mostly maintainers of applications that are not part of the 
official KDE releases.

Violations of this document does not allow filing of bugs with severity: 
serious or higher.

None of the sections in this document describes the packaging in the Debian 
releases Etch, Lenny or earlier releases, 
which all was shipped with a KDE Desktop with a major version lesser than 4. 
This document applies to KDE packaging targetted the Debian release Squeeze, 
but is expected to last at least as long as 
debian ships a KDE4 KDE Desktop.

The packages that are part of the official KDE releases does not yet fully 
adhere to this policy document, but is converging towards it.

This document uses shall and must and so on as defined in RFC 2119 
\footnote{http://www.ietf.org/rfc/rfc2119.txt}
--
--

KDE should be KDE 4, even if we make it clearer below.

Describing what a "official KDE release" is sounds like a good idea. For some
people, stuff like amarok or koffice could fall in this category, when it does
not.


I would not link to the RFC and just direclty define what we meant with shall
and must.



apps.tex
--
\chapter{Applications}

\section{Naming}

All applications should be named as close to upstream project name, and if a 
version of a application using KDE3 libraries and a version using KDE4 libraries
is expected to coexist during the release cycle of ``Debian Squeeze'', the 
package name of the application using KDE3 libraries must be versioned.

\section{Description}

All packages should have a clear description that describes what the program 
do. The prases "\ldots for KDE" or "\ldots for KDE 4" should be avoided, unless
it is a package that doesn't make sense outside the KDE Desktop itself.

\section{Sections}

Unless the package is strictly for the KDE Desktop and should not be used 
outside the KDE Desktop, the application should not
be in section: kde, but in the appropriate section for the scope of the 
application.

\section{Dependecies}

Applications using the graphic user interface parts KDE Libraries must depend 
on the \emph{kdebase-runtime} package, as this package contains
data that the KDE Libraries expect to be available as well as some commands 
that KDE Libraries and application using KDE Libraries expects
to be around and uses unconditionally.
The shlibs system of the KDE library packages should make sure that this is in 
place, but if the application for some reason doesn't 
use the shlibs system, this must still be honoured.

--
--

Again KDE3 -> KDE 3 (and KDE4 -> KDE 4).

About naming: add some hints of how to rename the KDE 3 version of the app
consistently?  Specifying also here for source and binary packages.

About description: I do not see what is wrong with "for KDE X", you have a
thousand of apps that does almost the same, it is good to know what is the one
that will integrate better with your environment.
If I search for a notetaking app, I will get at least 10, but I will see that
kjots is "for KDE" so I will know it is better integrated in my KDE.



non-apps.tex
--
\chapter{Namings of non-application}

\section{Documentation of legacy}

In general, there is different types of non-application packages.
In KDE 3 series, there was mostly 
\begin{itemize}
\item Icon themes 
\item Widget styles 
\item Window decorations 
\end{itemize}
And in KDE3 series, these was named \emph{kde-icon-something}, 
\emph{kde-style-something}
and \emph{kwin-style-something}. If a source package built both a
widget style and a window decoration, the package could either build
two binaries, if a dependency on the KDE window manager was to be
avoided, or in one package named \emph{kde-style-something}

\section{Names}

In KDE4 series, there is at least the following types of third party
non-applications:
\begin{itemize}
\item Icon themes
\item Widget styles
\item Window decoration
\item Plasma data engines
\item Plasma script engines
\item Plasma widgets
\item KIO slaves

Re: Uploads to lenny and the $KDEHOME dilemma

[Ana Guerrero]

On Wed, Feb 11, 2009 at 11:13:16PM +0100, Armin Berres wrote:
> On Tue, 03 Feb 09 22:53, Armin Berres wrote:
> > The current situation is, that KDE 3 applications use ~/.kde and KDE 4 
> > applications use ~/.kde4. The problem with this approach is, that no 
> > data/settings are automatically converted to be used by KDE 4.
> > 
> > The question is now: should we
> > a) continue to use ~/.kde4 for KDE 4 applications
> > b) use ~/.kde for KDE 4 applications.
> 
> When looking at the thread it seems as if we will go with b).
> The question is now: Is anyone working on any kind of conversion tool?
> Of yes, wht is the timeframe until it will be usable?
>

Yeah, it looks like b) is prefered. So let's plan with this option.

In case nobody is interested in (or have time for) doing a settings migrating 
tool for the stuff that is not migrated by the apps [1], we always can setup a 
page (and also maybe a README in the packages?) with some hints for migrating 
the stuff and have some pointer when people yells: WHERE IS MY EMAIL?

We have several cases:
- User of KDE 3 going to KDE 4 when it enters in unstable. (base case)
- Current user of KDE 4.2 who have already migrated settings. (nothing to do
  in our side, they have already migrated themselves)
- And the hard one: user of KDE 3 using some KDE 4 stuff. They have .kde and
  .kde4 with data in both.

Ana

[1] For what I have understood in this thread, everything should be migrated,
and when it is not possible, being ignored. And when it is not correclty 
migrated it is a bug to report to upstream.


-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: KDE in the transition queue

[Ana Guerrero]

On Sun, Feb 15, 2009 at 07:50:29PM +0100, Sune Vuorela wrote:
> 
> We are as good as ready to push a new and better KDE into unstable at your 
> command.
> 
> You basically have two choices. Brief and rough or less pain over a longer 
> period of time.

The details about this at:
http://lists.alioth.debian.org/pipermail/pkg-kde-talk/2009-February/001150.html
(about 6 mails thread not very long)


I disagree that the "brief and rough" way is shorter on time (and most of sune's
email) But you have the discussion in the above linked thread, no need to
repeat it here.

Cheers,
Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: KDE4 in Unstable

[Ana Guerrero]

On Sun, Mar 15, 2009 at 04:47:21PM +, Grześ Andruszkiewicz wrote:
> Hi,
> 
> I don't want to hasten you in anyway, but do you have a rough idea
> when kde4 will be available in unstable?
>

http://lists.debian.org/debian-kde/2009/03/msg00072.html


-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: KDE4.2 on Lenny

[Ana Guerrero]

Hi,

On Wed, Mar 18, 2009 at 02:02:35PM +0530, umesh debian wrote:
> Hi,
> 
> I have upgraded KDE to 4.2 on my Lenny system with instructions at:
> http://pkg-kde.alioth.debian.org/experimental.html
> 
> But i am having issues with DCOPserver errors for Old applications,
> for example "GTK Style and Feel" invoking give "DCOPServer not runign"
> error.
> 
> Is there a work around tutorial for this?
>

User lists is:
http://lists.debian.org/debian-kde/

KDE 4.2 in experimental is to be used in unstable.

Ana

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

meta-kde4 and meta-kde

[Ana Guerrero]

Welcome to the annual metapackages discussion.


At this moment, we have both meta-kde and meta-kde4 in unstable.
meta-kde is broken since it installs kde3 packages and meta-kde4 is just 
a quick upload with bump dependencies to 4.2.2.
We should kill meta-kde and update meta-kde4 to some final layout.


* meta-kde provides: kde, kde-devel and kde-core.

My proposal here is keeping kde and be the same than currently kde4.

* meta-kde4 provides: kde4, kde4-minimal and kde4-developent.

My proposal here is:
-keep kde4 and add kde (both do the same)
-keep kde4-minimal and add kde-mininal (or kde-core :? but it is not longer the
same that used to be in kde3...)
-transform kde4-development in real development meta package. In the future 
it will even have kdevelop 4...
- and add some kde-desktop-full package that is kde4 with a recommends in all
the cool apps: amarok, yakuake ktorrent... For users that just want
everything.



Having a lot of metapackages is nice, but it gets confusing. It will be hard
to reach some equilibrium here.

What do you think? What is your proposal here?

Ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

kde-l10n in NEW, process please

[Ana Guerrero]

Hola,

kde 4.2's translations are currently stuck at new only because they 
include a new translation (slovak), could you take a look at it please?

Ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: meta-kde4 and meta-kde

[Ana Guerrero]

On Tue, Apr 07, 2009 at 06:49:33AM +0200, Ana Guerrero wrote:
> 
> Welcome to the annual metapackages discussion.
>


After the emails that followed my first mail, I have realized that certainly 
if the 4 in the meta packages is going to be killed, the sooner, the better.

So, what about:

- kde-minimal (just rename current kde4-mininal) I am not sure kde-core longer
  fits.
- kde-full (renamed from current kde4) I agree it is clearer than kde.
- kde-development. Not only renamed from kde4-development, also address
  #484855 and convert it in what its name says.


In the future, when we have more kde4 apps in the archive we can make the
package with 3rd party apps. Modax suggested kde-standard, i think
kde-3rdparty could fit too.


Ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Bug#523899: Stop providing KDE 3 support

[Ana Guerrero]

On Mon, Apr 13, 2009 at 02:45:04PM +0200, Rene Engelhard wrote:
> Hi,
> 
> Ana Guerrero wrote:
> > With KDE 3 as default kde in unstable, the kde 3 support provided in
>^ 4? ;)
> 
> > openoffice.org (-kde and -kab AFAIR) is not longer useful. Please stop
> > building it.
> 
> Last I loooked it still showed Qt dialogs even when used in KDE4.. So what
> exactly is not useful anymore? The file picker? The KAB integration?
> (The latter can be disabled on its own afair)
>

I am not an openffice.org user in debian, so i might have missed something,
but so far:
the -kab integration is linking against the old kde3 libraries, so it hardly
can work with current kaddressbook et all.
about -kde is supposed to show it integrated with kde4/qt4 and if that is
working (i have not checked), it will be kde3/qt3 and you have to install
kdelibs from kde3 that some users might have ride of already.

For me it is ok to keep -kde if you rename it to -kde3, but not sure it is
worth the bothering (NEW...)

Ana
PS: CC'ed pkg-kde-talk@ in case some heavy OOo users has something to add.


--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: meta-kde4 and meta-kde (final conclusions)

[Ana Guerrero]

On Tue, Apr 07, 2009 at 06:49:33AM +0200, Ana Guerrero wrote:
> 
> We should kill meta-kde and update meta-kde4 to some final layout.
>
...

After leaving this issue "sleep" a couple of weeks, I am all for:

kde-full (current kde4)
kde-minimal
kde-thirdparty

And we can keep using kde-$MEANING for the metapackages.
Since we have to go to NEW i will add already kde-thirdparty with
RECOMMENDS in amarok, ktorrent, yakuake, rsibreak anything else?

I do not know if we need kde-development, and what to put here.
If you think it is worth it, anwser here why :D

Another question: kde-full should provide "kde" ?

We really need to move forward with the metapackages before people get very
used to current ones...


Ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

kde-standard pre-list

[Ana Guerrero]

Hi,


I have made a pre-list to start discussing what should go into kde-standard.
I am going to run a consult poll in debian-kde that won't be binding at all, 
but I am curious to see what people votes.
I would like to cut the current pre-list because it is too long.


** Apps that is already included because it belongs to kde-minimal:

dolphin
kappfinder
kdepasswd
kfind
kde-window-manager
klipper
konqueror
konqueror-nsplugins
konsole
ksysguard
kwrite
plasma-widget-folderview
systemsettings

** Apps in unstable:
This lists 170 apps that are currently in unstable, please do not go into 
details now, just point to the clearly development only apps i may have skipt.
If we skip the games and edu apps, the list is not soo long.

adept
akregator
amor
ark
blinken
bomber
bovo
digikam
dragonplayer
eqonomize
gtk-qt-engine-kde4
gwenview
juk
kaddressbook
kalarm
kalgebra
kalzium
kamera
kanagram
kapman
kate
katomic
kbattleship
kblackbox
kblocks
kbounce
kbreakout
kbruch
kcalc
kcharselect
kcolorchooser
kcron
kde-style-polyester
kde-zeroconf
kdeartwork-style
kdegraphics-strigi-plugins
kdemultimedia-kio-plugins
kdenetwork-filesharing
kdepim-groupware
kdepim-kresources
kdepim-strigi-plugins
kdepim-wizards
kdessh
kdesudo
kdf
kdiamond
kdiff3
kdm
keurocalc
kfilereplace
kfloppy
kfourinline
kgamma
kgeography
kget
kgoldrunner
kgpg
khangman
khelpcenter4
kig
kile
killbots
kimagemapeditor
kinfocenter
kio-ftps
kipi-plugins
kiriki
kiten
kjots
kjumpingcube
kleopatra
klettres
klines
klinkstatus
kmag
kmahjongg
kmail
kmines
kmix
kmldonkey
kmousetool
kmouth
kmplayer
kmplot
kmtrace
knemo
knetwalk
knetworkconf
knode
knotes
kode
kolf
kollision
kolourpaint4
kommander
kompare
konq-plugins
konqueror-plugin-gnash
konquest
konsolekalendar
kontact
kopete
korganizer
kover
kpackage
kpartloader
kpat
kpilot
kppp
krdc
krename
kreversi
krfb
kruler
krusader
ksame
kscd
kscreensaver
kscreensaver-xsavers
kshisen
ksirk
ksnapshot
kspaceduel
ksquares
kstars
ksudoku
ksystemlog
kteatime
ktimer
ktimetracker
ktorrent
ktouch
kttsd
ktuberling
kturtle
ktux
kubrick
kuiviewer
kuser
kwalletmanager
kwave
kweather
kwin-style-crystal
kwin-style-dekorator
kwordquiz
lskat
marble
okteta
okular
okular-extra-backends
palapeli
parley
plasma-runners-addons
plasma-scriptengine-googlegadgets
plasma-scriptengine-javascript
plasma-scriptengine-qedje
plasma-scriptengine-superkaramba
plasma-scriptengine-webkit
plasma-widget-ktorrent
plasma-widget-lancelot
plasma-widget-weather
plasma-widgets-addons
plasma-widgets-workspace
python-kde4
rsibreak
showfoto
smb4k
step
sweeper
yakuake

** FYi, stuff i have already discarded:
cervisia
compiz-kde
compizconfig-backend-kconfig
cvsservice
icecc-monitor
kapptemplate
kbugbuster
kcachegrind
kdesdk-kio-plugins
kdesvn
kdesvn-kio-plugins
kdesdk-strigi-plugins
kxsldbg
lokalize
rkward
umbrello


** Applications in experimental:
What of the following will should add to the list assuming they will be in 
unstable soon.

amarok
koffice suite ( karbon, kchart, kplato, kpresenter, krita, kspread, 
kthesaurus, kword)
konversation
kopete-silc-plugin
kshutdown
ksshaskpass
kwin-style-skulpture
kyzis
plasma-widget-networkmanagement
tagua (made for pre-KDE 4.1)

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

wording of debian-desktop.org

[Ana Guerrero]

[For who does not know what I am talking about, it is about the website:
http://www.debian-desktop.org:80/doku.php/
that points to http://www.debian.org/devel/debian-desktop/  ]

Hi Martin and all,

I do not have any problem at all with you offering KDE packages. You
are totally free to do so, and I am sure your work is highly appreciated for a
lot of users. But I have problems with the whole debian-desktop official
project thing. AFAIK, Debian desktop subproject is to work on the integration of
the various desktop-related packages, bug reports, questions and patches 
*inside* Debian.
You are providing packages named as the "official" ones of the "Official
DebianDesktop project" and those packages should be the packages in the archive
for any desktop.
Debian-Desktop is about making better the desktop experience in Debian not
having official packages outside the archive.

To the list: What is debian-desktop subproject supposed to be currently?

In any case a small request: could you put clearly in debian-desktop.org that 
your KDE packages are unofficial and not necesarily upgrade compatible with 
the archive ones? 

Again, I have not problems with you offering the packages, just with the whole
"official" thing that is confusing...

Thanks,
Ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: kde-standard pre-list

[Ana Guerrero]

On Thu, Apr 23, 2009 at 05:45:14PM +0300, Modestas Vainius wrote:
> Hi,
> 
> On 2009 m. April 23 d., Thursday 16:50:04 Ana Guerrero wrote:
> > ** Apps that is already included because it belongs to kde-minimal:
> >
> > dolphin
> > kappfinder
> > kdepasswd
> > kfind
> > kde-window-manager
> > klipper
> > konqueror
> > konqueror-nsplugins
> > konsole
> > ksysguard
> > kwrite
> > plasma-widget-folderview
> > systemsettings
> I think kde-standard should depend on those apps via kde-minimal rather than 
> directly.
>
Yeah, sure, I was talking in the level of applications here.

> 
> Lets see:
> 
> Depends (limited to official KDE):
>


This is not exaclty the opinion I was seeking now, I wanted to cut down the
list a bit to do a poll =)

ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: wording of debian-desktop.org

[Ana Guerrero]

On Thu, Apr 23, 2009 at 06:42:31PM +0200, Martin Alfke wrote:
> > Hi Martin and all,
> >
> > I do not have any problem at all with you offering KDE packages. You
> > are totally free to do so, and I am sure your work is highly appreciated
> > for a
> > lot of users. But I have problems with the whole debian-desktop official
> > project thing. AFAIK, Debian desktop subproject is to work on the
> > integration of
> > the various desktop-related packages, bug reports, questions and patches
> > *inside* Debian.
> > You are providing packages named as the "official" ones of the "Official
> > DebianDesktop project" and those packages should be the packages in the
> > archive
> > for any desktop.
> 
> 
> I had no intention to mark the site as the official website for the
> DebianDesktop project.
> Maybe my wording was wrong. I changed the wording to make clear that my site
> is not the official website.
>

It is ok now. Thanks a lot Martin!

Ana


--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Bug#528489: tasksel: kde-desktop neeeds adjusting for KDE4

[Ana Guerrero]

tags 528489 +patch
thanks

On Wed, May 13, 2009 at 11:04:38AM +0200, Adeodato Simó wrote:
> Package: tasksel
> Version: 2.78
> Severity: important
> X-Debbugs-CC: pkg-kde-talk@lists.alioth.debian.org
> 
> Hello,
> 
> while trying to get an initial view of migrating KDE4 to testing with
> britney, I noticed that our "taskel-meta-faux" package [1] was rendered
> uninstallable because the kde-core metapackage is no longer provided. It
> seems the KDE meta-packages have been re-organized for KDE4, and now
> kde-full, kde-minimal and kde-standard are provided.
> 
> It'd be nice if you could be looking into updating tasksel to these new
> metapackages, so that there's a version ready to migrate together with
> KDE4.
>

The attached patch updates the task to KDE 4. It relies in the new metapackage
kde-standard that still needs to be updated [0]. The metapackage will need an 
update in a couple of months or so when KDE 4 is more "settled" in Debian and
to review what to do with libqt-perl, debconf kde frontend, and kpackage.

Ana

[0] thread about this if you are curious:
http://lists.alioth.debian.org/pipermail/pkg-kde-talk/2009-April/001254.html
--- kde-desktop.orig	2009-05-13 12:57:01.0 +0200
+++ kde-desktop	2009-05-13 13:06:13.0 +0200
@@ -7,25 +7,17 @@
  This task provides basic "desktop" software using the K Desktop
  Environment.
 Key:
-# This could probably be reduced more.
-  kde-core
-  kdeadmin
-  kdeartwork
-  kdegraphics
-  kdemultimedia
-  kdenetwork
-  kdeutils
-  kdepim
+# This meta package will install a kde default desktop, but we have not decide
+# yet what it should ship.
+  kde-standard
   kdm
 Packages: task-fields
 Packages-list:
-  kde
-  openoffice.org-kde
 # enable debian menus
   menu-xdg
-# package management
-  kpackage
-# debconf kde frontend
+# package management. Need something here, but please, no kpackage.
+#  kpackage 
+# debconf kde frontend. This will go away, see #522580
   libqt-perl
 # cd/dvd burner
   k3b
@@ -35,6 +27,3 @@
 # This is configured by d-i to be used to gain root on systems with no root
 # password. It is not enabled by default.
   kdesudo
-# kdeutils recommends this, and it's needed on laptop, and can also be
-# useful on desktops
-  kpowersave
--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Bug#528489: tasksel: kde-desktop neeeds adjusting for KDE4

[Ana Guerrero]

On Wed, May 13, 2009 at 02:19:17PM +0200, Frans Pop wrote:
> How big would the resulting install be?
> 
> I'm asking because it is *essential* that the packages listed as "Key" 
> don't install too large a system as they (plus all their Depends, not 
> Recommends) must easily fit on a single CD (together with D-I, 
> documentation (installation guide, release notes), base system, kernel, 
> X.org, etc.).
> 
> Will the kde-standard meta package fit that requirement?

Yes, I think it will do. Currently kde-standard is exactly the same than 
kde-minimal. The goal in the very close future is that kde-standard become 
something between kde-minimal and kde-full; this a similar to what the old 
task does, it contains kde-core and some modules. (Actually I think the
current list of key packages is too big, but that does not matter anymore)

The goal of kde-standard is provide what an average user would expect: browser,
file manager (those both are included in kde-standard), but also pdf reader
(okular, kdegraphics), etc... I think it will be a better selection that what
is currently listed "key".


> If not, it might be better to list something "smaller" as Key package, 
> with kde-standard as a "regular" package that's to be installed if 
> available.
>

If kde-standard becomes too big, the task can be changed to kde-minimal 
plus subset of modules. And move the remaining to Packages-list, or even
directly list there kde-full (it does list kde now...)

But for what we (kde team) have in mind for kde-standard, it should fit
perfectly the task.

> And even after that, regular packages included in the task should also not 
> total too much. Preferably the whole task should be installable from CD1, 
> ideally with room to spare for at least some KDE l10n packages.


In any case, from now to one year that we will have to relook at this. KDE
upstream is in constantly doing changes and who knows how things will end up
for the time that we will be getting ready for squeeze (KDE 4.4 or KDE 4.5 or
who knows). 


Ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: rev 14835 - scripts/svn-hooks

[Ana Guerrero]

On Wed, Jun 03, 2009 at 08:17:58PM +, Fathi Boudra wrote:
> Author: fabo
> Date: 2009-06-03 20:17:57 + (Wed, 03 Jun 2009)
> New Revision: 14835
> 
> Modified:
>scripts/svn-hooks/commit-access-control.cfg
> Log:
> use one line per user

arg


> cleanup duplicate
> should we cleanup "never commited" people ?
>

yes, we should do cleanup.


> 
> Modified: scripts/svn-hooks/commit-access-control.cfg
> ===
> --- scripts/svn-hooks/commit-access-control.cfg   2009-06-03 17:32:10 UTC 
> (rev 14834)
> +++ scripts/svn-hooks/commit-access-control.cfg   2009-06-03 20:17:57 UTC 
> (rev 14835)
> @@ -65,29 +65,93 @@
>  
>  [Main comitters]
>  match = .*
> -users = pyro schepler sharky rcardenes isaac adeodato chrsmrtn ana 
> jdmetz-guest
> -users = fabo modax-guest pusling-guest ender quique-guest bedo-guest nacho 
> kaare-guest hobbsee-guest
> -users = jan mario trigger-guest nowhrman-guest angasule-guest 
> imbrandon-guest kebianizao-guest mukidohime-guest
> -users = fourmond shlomme petere pino-guest wdgt-guest dpalacio-guest aurel32 
> jmm gkiagia-guest
> -users = pgquiles-guest the-me-guest jriddell-guest kitterma-guest 
> firerabbit-guest lisandropm-guest
> -users = meebey ncommander-guest fregl-guest pravi-guest mea-guest 
> icwiener-guest odyx-guest
> +users = adeodato
> +users = ana
> +users = angasule-guest
> +users = aurel32
> +users = bedo-guest
> +users = chrsmrtn
> +users = dpalacio-guest
> +users = ender
> +users = fabo
> +users = firerabbit-guest
> +users = fourmond
> +users = fregl-guest
> +users = gkiagia-guest
> +users = hobbsee-guest
> +users = icwiener-guest
> +users = imbrandon-guest
> +users = isaac
> +users = jan
> +users = jdmetz-guest
> +users = jmm
> +users = jriddell-guest
> +users = kaare-guest
> +users = kebianizao-guest
> +users = kitterma-guest
> +users = lisandropm-guest
> +users = mario
> +users = mea-guest
> +users = meebey
> +users = modax-guest
> +users = mukidohime-guest
> +users = nacho
> +users = ncommander-guest
> +users = nowhrman-guest
> +users = odyx-guest
> +users = petere
> +users = pgquiles-guest
> +users = pino-guest
> +users = pravi-guest
> +users = pusling-guest
> +users = pyro
> +users = quique-guest
> +users = rcardenes
> +users = schepler
> +users = sharky
> +users = shlomme
> +users = the-me-guest
> +users = trigger-guest
> +users = wdgt-guest
>  access = read-write
>  
>  [KDE4 commiters]
>  match = branches/kde4
> -users = danf_1979-guest kartikm-guest
> +users = danf_1979-guest
> +users = kartikm-guest
>  access = read-write
>  
>  [kde-extras]
>  match = kde-extras
> -users = ach-guest msp mez tomalbers-guest ptitlouis-guest jriddell-guest 
> zhengpeng-guest tonio-ubuntu-guest 
> -users = wjbeksi-guest jaldhar mrjoel-guest nixternal-guest meskes 
> atomo64-guest jpatrick-guest francois
> -users = adi-guest foka lpereira-guest ryanakca-guest haizaar-gues biebl 
> kelmo-guest trash-guest
> -users = lure-guest pmjdebruijn-guest
> +users = ach-guest
> +users = adi-guest
> +users = atomo64-guest
> +users = biebl
>  users = curan-guest
>  users = dfiloni-guest
> +users = foka
> +users = francois
> +users = haizaar-guest
> +users = jaldhar
> +users = jpatrick-guest
> +users = kelmo-guest
> +users = lpereira-guest
> +users = lure-guest
> +users = meskes
> +users = mez
> +users = mrjoel-guest
> +users = msp
> +users = nixternal-guest
> +users = pmjdebruijn-guest
> +users = ptitlouis-guest
> +users = ryanakca-guest
> +users = santa-guest
> +users = tomalbers-guest
> +users = tonio-ubuntu-guest
>  users = toots
> -users = santa-guest
> +users = trash-guest
> +users = wjbeksi-guest
> +users = zhengpeng-guest
>  access = read-write
>  
>  [Documentation]
> 
> 
> --
> http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-commits

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: KDE 4.3 in trunk

[Ana Guerrero]

On Sat, Jun 06, 2009 at 08:57:19PM +0300, George Kiagiadakis wrote:
> Hi,
> 
> I just branched off kde 4.2 in /branches/kde4.2 and commited kde4libs,
> kdepimlibs, kdebase-runtime and kdebase-workspace 4.2.90+svnXX in
> trunk. I'm just writing this mail to let you know that trunk is now
> 4.3.
>

Cool =)

Ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: KDE 4.3 in trunk

[Ana Guerrero]

On Sat, Jun 06, 2009 at 10:59:52PM +0200, Ana Guerrero wrote:
> On Sat, Jun 06, 2009 at 08:57:19PM +0300, George Kiagiadakis wrote:
> > Hi,
> > 
> > I just branched off kde 4.2 in /branches/kde4.2 and commited kde4libs,
> > kdepimlibs, kdebase-runtime and kdebase-workspace 4.2.90+svnXX in
> > trunk. I'm just writing this mail to let you know that trunk is now
> > 4.3.
> >
>

By the way, I have seen you have added yourself to uploaders (finally).
We should so some cleanup there while we make it automatic again (if we do
:P).  I am going to remove to Muki, his last commit was in September'08 and 
the previous one in July'08. 


Ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

[knut.yr...@nokia.com: Q: Key issues to address with Qt/KDE on Debian]

[Ana Guerrero]

- Forwarded message from Knut Yrvin  -

From: Knut Yrvin 
Organization: Qt Software
Reply-To: Knut Yrvin 
To: Debian Qt/KDE 
Date: Mon, 15 Jun 2009 17:06:29 +0200
Subject: Q: Key issues to address with Qt/KDE on Debian
User-Agent: KMail/1.11.4 (Linux/2.6.28-11-generic; KDE/4.2.4; i686; ; )

Hi all, 

I'm working on a short list of issues which can be improved when packaging 
and running KDE 4 on Debian. What are the two-three most important issues 
to address and maybe fix. 

I've already got suggestions improving KNetworkManager with mobile 
broadband modem integration[1]. Several improvements and fixes was 
suggested from KDE before releasing Qt 4.5[2]. This are example of things 
I'm looking for. 

My question: What's the top two-three things which could be improved on 
Qt/KDE integration on Debian, making it really shine? And how do you think 
we should address those improvements?

1. http://dot.kde.org/2009/06/10/network-manager-sprint-oslo
2. http://labs.trolltech.com/blogs/2008/12/04/how-kde-4-is-blocking-qt-45/

Best regards

Knut Yrvin
-- 
Open Source Community Manager
Qt Software, Nokia
cell: + 47 934 79 561, phone: +47 21 60 27 58
http://qtsoftware.com


-- 
To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

- End forwarded message -

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Salvapantallas que no son distribuidos por orig.tarball de nuevo

[Ana Guerrero]

Hi José Luis,

On Thu, Jul 09, 2009 at 12:30:32AM +1930, Jose Luis Rivas wrote:
> Hola Ana,
> 
> Quería comentarte que hay varios Salvapantallas que no son
> distribuidos más por el tarball original de XScreenSaver. 

.

I am on VAC, sent a translated email to this list or the maintainer list:
debian-qt-...@l.d.o (no moderated)

(It is always better use public archived mailing list for this stuff...)

Thanks for the notice, btw :)
Ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: KDE plans for the squeeze cycle

[Ana Guerrero]

My thoughts... this is just a draft, add your thoughts/extra information or if
you just agree, and we'll try to get a final mail.
I would be nice if we hear from modax before sending anything too (he is in
vac).

On Sun, Aug 16, 2009 at 02:41:27PM +0200, Marc Brockschmidt wrote:
> Heya,
> 
> As announced on dda [RT1], we want to get an impression when releasing
> Squeeze is feasible. We have proposed a (quite ambitious) freeze in December
> 2009, and some developers have noted that their planned changes wouldn't be
> possible in this time frame. So, to find out when releasing would work for
> most people, it would be great if you could answer the following questions:
>

I will answer your including also Qt 4 plans, that as you know is a quite
important part for KDE 4 :)
There is also a bunch of widely used kde apps that do not belong to KDE
core, but they are leaf apps.

> * Which major upstream releases of KDE are expected in the next two
>   years? Which of those are material for Debian stable, which might be a bit
>   flaky?
> 

We currently have KDE 4.3.0 in unstable and we will have at least a couple of 
point
releases before this year ends.

KDE 4.4 is expected about January 2010.
KDE 4.5 is expected about July 2010.

It is not a good idea to do more speculation about dates after this point
because in KDE they are also testing new release management methods...

About flaky releases, usually 0 point releases have some bugs and 1 point
releases are highly preferred to ship in a Debian stable release.


We currently have Qt 4.5.2 in the archive and if it even could get another
point release, the development and expectations are on Qt 4.6.
There is not public release schedule for Qt 4.6, but worse case scenario, I
think there will be at least a pre-release by december. Qt 4.5 was released in
March 2009, I really expect Qt 4.6 being release before Qt 4.5 is one year
old.

Whether KDE 4.4 will need Qt 4.6 or not, is still unknown, it depends a lot of 
Qt 4.6 release date.

> * How much time do you usually need from a new upstream release of KDE
>   to a stable Debian package in unstable?
>

Major releases:
We usually are able to have the packages ready by the day of the release since
we always get the final tarballs between 5-7 days before the release.
In almost all the major releases, we need to put some stuff throught NEW and 
sometimes this is faster, sometimes it is not so fast.


> * How many "big" transitions will the upcoming changes cause? When should 
> those
>   happen? Can we do something to make them easier?
> 

Nothing I can think of now, we already have done most of the complicated stuff
when moving from kde 3 to kde 4.

Something it would be very nice to do for Squeeze is killing more kde 3 apps.
Specially, some of the kde 3 apps that are not ported and have somehow a 
replacement 
in kde 4.  This is being doing slowly [0]. Anyway, with the current dates you
are proposing, I am almost sure kdelibs(4c2a) from kde 3 will have to be kept 
for Squeeze (plus Qt 3, of course) and it will be hard because they are quite 
dead upstream...
What could be removed is arts (and we would love to), but it needs some work on 
it.


In summary:
We would like a Squeeze release with KDE 4.4.0 at least (4.4.1 if possible) and
Qt 4.6. For us december work quite *bad*, if you freeze  in december we'll
have some kde 4.3.x and from january we'll be using 4.4, if the freeze last a
few months (*), by July we will be using 4.6 and it will be quite hard to care
about bugs in KDE 4.3.x, that will be from 2 releases ago

(*) I am sorry but it is not crazy thinking about this happening...

[0] http://wiki.debian.org/kdelibs4c2aRemoval


--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: KDE plans for the squeeze cycle

[Ana Guerrero]

On Mon, Aug 17, 2009 at 09:17:38PM +0200, Mario Fux wrote:
> Am Montag, 17. August 2009 schrieb David Palacio:
> 
> > I want to highlight that Qt 4.6 will deliver an important set of new
> > features (animation API, state machine framework), and important updates
> > (graphics view, webkit, qtscript) [0]. Leaving 4.6 outside of the next
> > stable, would put Squeeze in an unsupported status of new Qt software for
> > it's entire life span.
> >
> > See [1] for an estimate of when we should expect a 4.6 release.
> >
> > [0] http://qt.nokia.com/developer/qt-roadmap
> >
> > [1] http://stackoverflow.com/questions/1190545/qt-4-6-release-
> > date/1190569#1190569
> 
> See this blog on labs.trolltech.com/blogs about the release of Qt 4.6:
> http://labs.trolltech.com/blogs/2009/08/13/its-getting-colder/
>


Cool, so with a bit luck we will have Qt 4.6 sliglty before KDE 4.4.

Ana



--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Upgrade path from KDE 3 to KDE 4

[Ana Guerrero]

On Fri, Aug 21, 2009 at 01:10:52PM +0200, Sune Vuorela wrote:
> On Friday 21 August 2009 12:41:50 Armin Berres wrote:
> > Hi everybody!
> >
> > We invested a lot of time to make the upgrade from KDE 3 to KDE 4 as
> > smooth as possible. Sadly, there are still some more or less rough
> > edges.
> > The most important issue I have on my radar is the installation of
> > kdebase-workspace. When upgrading from KDE 3 without installed
> > meta-packages kdebase is updated, but you loose your desktop, because
> > aptitude does not know, that kdebase-workspace is needed know. I propose
> > to recommend or depend on kdebase-workspace in kdebase. Comments?
> 
> braindump:
> 
> rename kdebase metapackage to kdebase-apps
> introduce a new kdebase metapackage that is more or less equivalent to kde3 
> kdebase metapackage
>

I thought exaclty the same... :)

Ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: KDE plans for the squeeze cycle

[Ana Guerrero]

Hi Marc et all,

I will answer including also Qt 4 plans, that as you know is a quite
important part of KDE 4 :)

> * Which major upstream releases of KDE are expected in the next two
>   years? Which of those are material for Debian stable, which might be a bit
>   flaky?

About KDE
--

We currently have KDE 4.3.0 in unstable.
KDE 4.4 is expected about January 2010.
KDE 4.5 is expected about July 2010.

It is not a good idea to do more speculation about dates after this point
because in KDE they are also testing new release management methods. 

About flaky releases, usually 0 point releases have some bugs and any further 
point releases are highly preferred to ship in a Debian stable release.
In case of freezing with a .0 (or .1) release, we would like to be given the 
possibility of upload the next point releases given that point releases have so 
far contained fewer regressions than actual bug fixes.
Having a .2 or .3 point release would be the ideal.

We would like to mention that neither of us expected to release with KDE 4.3.X 
and we didn't give (nor will give now being late to the party) to it as much 
care as it probably needed to.

About Qt
-
We currently have Qt 4.5.2 in the archive and the development and expectations 
are on Qt 4.6. This release is expected about the end of this year or worse 
case, 
very early 2010.
Qt 4.6 will deliver an important set of new features (animation API, state 
machine 
framework), and important updates (graphics view, webkit, qtscript) [0]. 
Leaving 
4.6 outside of the next stable, would put Squeeze in an unsupported status of 
new 
Qt software for its entire life span.
It is also worth mentioning Qt 4.5.x doesn't support GCC 4.4 (and won't), Qt 
4.6 
will do. 
As with KDE the best is always shipping with a point release and Qt 4.6.1 is 
our 
minimal target.


> * How much time do you usually need from a new upstream release of KDE
>   to a stable Debian package in unstable?

KDE releases the tarballs to packagers one week before release, so packagers
have time to prepare the packaging. We usually get something ready (with the
4.x releases) for release day, sometimes with some bugs, sometimes not. These
bugs are usually weeded out during a week or two after this.

For point releases, which is only bug fix releases, we usually get the
packaging fully right at first upload, which happens around release day.


> * How many "big" transitions will the upcoming changes cause? When should 
> those
>   happen? Can we do something to make them easier?

We already have done most of the complicated stuff when moving from kde 3 to 
kde 4.
We have some stuff we would like to do but nothing too big or "must do" before 
next
release.


If we could plan the Debian release cycle completely after what would be good
for KDE, squeeze will freeze shortly after KDE 4.5.0 is uploaded to Debian
(July 2010) and the 4.5.x point releases would be allowed in.

KDE would have the possibility to take advantage of the new things in Qt4.6, 
and 
we would reach Qt4.6.2 or something like that on the Qt side.



--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Bug#548244: update kde Suggests

[Ana Guerrero]

Package: desktop-base
Version: 5.0.5
Severity: normal

Please update the Suggests on kde to kde-standard. kde metapackage not longer
exists.

Ana



--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Switch to orig.tar.bz2 & dpkg-source format 3.0 (quilt)?

[Ana Guerrero]

On Mon, Nov 02, 2009 at 08:35:11PM +0200, Modestas Vainius wrote:
> Hello,
> 
> since Debian ftpmasters have made it possible to upload source packages 
> packaged in the next generation formats:
> 
> 1) I don't see any blockers to use pristine KDE upstream tarballs anymore 
> (renamed to appropriate orig.tar.bz2 of course).
> 
> 2) What about dpkg-source format 3.0 (quilt) for all official KDE packages? I 
> tested it and I was sort of pleased with results.
> 

Fine on my side.

Ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Switching KDE packaging to git

[Ana Guerrero]

On Sun, Jul 11, 2010 at 03:53:33PM +0300, Modestas Vainius wrote:
> Hello,
> 
> so hereby I propose to switch our KDE packaging from svn to git on 
> git://git.debian.org/git/pkg-kde/kde/$modulename.git. In other words, each 
> official KDE module gets its own $module.git under 
> git://git.debian.org/git/pkg-kde/kde/ with a script to clone/pull/etc. them 
> all.
> 
> 1) We would use the same workflow as for qt4-x11.git, i.e. no upstream 
> branch. 
> It proved to be fine, didn't it? Fathi, you worked most with qt4-x11.git, is 
> there anything you would like to be changed?
> 
> 2) upstream & pristine-tar branches are nice for small packages but from my 
> experience:
>a) they are additional burden to manage even if `git import-orig` makes it 
> kinda easy to import; but kde is 22 source packages so I don't think this 
> will 
> scale;
>b) things get complicated (though manageable with some patience) when 
> there 
> are a few packaging branches based on different upstream versions. It might 
> be 
> tricky to get merging right;
>c) upstream branches increase repository size considerably; given that kde 
> has 22 source packages, clone of all repos will be huge;
>d) last but not least, when we decide we want upstream branches, we can 
> always add them later without any cost.
> 
> 3) Packaging will be imported to git with all history.
> 
> The main motivation for VCS change is upcoming situation. We will probably 
> have to release with 4.4.5, but we will want to package KDE 4.5 as well. 
> Merging in svn is impossible but we want to properly track changes which 
> apply 
> to both 4.4.5 <=> 4.5 packaging (we have lost changes in the past due to svn 
> deficiencies).
> 
> Secondary motivation is that centralized svn is ageing while git is 
> distributed, fast, has some nice features and is the most featureful DVCS at 
> the moment.
> 

Sounds good to me.

Ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

towards KDE 4.5?

[Ana Guerrero]

Hi,

As you might now, KDE 4.5 is being released in 3 days and the Debian
freeze seems not to be close. Last release mail said end of August,
but I would not be surprised if it takes 2-3 weeks more at least.
That would mean we would be about the time 4.5.1 is likely to be out.

So my question is: who is willing to work towards uploading 4.5.0 to 
experimental (or unstable) and then 4.5.1 to unstable?
This needs some general planning of what needs to be done and tell the 
release team about our plans. I am willing to help with this part
and make uploads if needed, but I do not have too much time for the
updating part.

Ana


--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: towards KDE 4.5? (mail to -release, filling the needed info)

[Ana Guerrero]

On Mon, Aug 02, 2010 at 03:00:50PM -0400, Ana Guerrero wrote:
> This needs some general planning of what needs to be done and tell the 
> release team about our plans. I am willing to help with this part
> and make uploads if needed, but I do not have too much time for the
> updating part.

Thanks for all your answers so far!
Now the next step is mailing the release team, I have voluntered with this
part, but as as you know, I have not been around lately and I need some help 
recollecting information.

The plan is: shipping into the next stable release with KDE 4.5.x where
x is hopefully at least >=2 with Qt 4.7.
The 4.5.0 release is in 2 days and we are far from having packages ready,
so as Modestas pointed, we could ship then wherever we have something
ok for general public at qt-kde.d.n and later upload 4.5.1 directly to the 
archive.
4.5.1 is supposed to be released in the 2nd week of September.

Fabo, do you know when is Qt 4.7 being released? :) I have not idea about
approx dates and we need them if we are about to tell our plans to the
release team. Actually, it might be a good idea to handle this separately?


About KDE 4.5, gkiagia, Modestas: what have you found so far? As I have
understood it, we should have not problems with the soname bumps/additions/
removals (if any) out of KDE (SC).
Also, I know we have one new package neeeded, grantlee, but it is already in 
the archive (thanks to bricks!).

Finally, it is kdepim. The "official" planning currently says they will skip
4.5.0 and release with 4.5.1 and well, the changes will be big. Should we keep 
4.4.x anyway?

Ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: KDE-SC 4.6.x?

[Ana Guerrero]

On Fri, Apr 01, 2011 at 03:03:07PM +0200, Sedat Dilek wrote:
> Hi,
> 
> I am just curious where the development and discussion to KDE-SC 4.6.x
> is happening.
>

Look in http://git.debian.org for pkg-kde repositories.
e.g.: http://git.debian.org/?p=pkg-kde/kde-sc/kde4libs.git;a=summary

Ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

kdelibs3 removal and Qt3 orphaning

[Ana Guerrero]

Hi,

Yesterday kdelibs from KDE 3 was removed from the archive (#619728).
Lisandro and I are working now in arts b-d to be also removed in a few 
weeks. There are ~5 packages that need an upload, but we are taking
it more calmly that kdelibs' removal.

The next step is Qt3 orphaning. The removal of Qt3 from the archive
before Wheezy, assuming a release in ~2 years, seems complicated:

- there is a the high number of packages using it (~100, see attached file)
- if we remove it, we do not longer comply the last version of Linux Standard 
Base in Debian, which seems important for some folks.
- there are a lot of scientific software using it, not always packaged into
Debian, and they would have a problem if we remove it from Wheezy.
- personally, I have been convinced leaving Qt3 around is not so
dangerous as leaving kdelibs3. And seems like a good idea as long
as I am not a Qt3 maintainer :D

In any case, some QA work removing/updating some rotten packages using Qt3 
is a very good idea.

So, what we do now? Before doing a final upload orphaning it, I am more
inclined to email debian-devel@ and do a call for new maintainers.
If in 2 weeks after the call nobody steps up, we do a QA upload orphaning
and doing the last changes we want done [1], and if it gets maintainer,
we ask them to do those changes in their adopting upload.

Ana

[1 ]http://whiteboard.debian.net/qt3-removal.wb
Right now only contains:
-lower the qmake alternative
-consider dropping embedded stuff, lot of qt4 is conflicting with it 




Checking reverse dependencies...
# Broken Depends:
albumshaper: albumshaper
  
alsa-tools: qlo10k1 [alpha amd64 armel hppa i386 ia64 mips mipsel powerpc s390 
sparc] 
arts: libarts1-dev  
  
  libarts1c2a   
  
avahi: libavahi-qt3-1   
  
   libavahi-qt3-dev
avida: avida-qt-viewer  
 
avifile: avifile-player 
 
 avifile-utils
beid: beid-tools [alpha amd64 armel i386 ia64 mips mipsel powerpc s390 sparc]
  libbeid2 [alpha amd64 armel i386 ia64 mips mipsel powerpc s390 sparc]
  libbeidlibopensc2 [alpha amd64 armel i386 ia64 mips mipsel powerpc s390 
sparc]
biblememorizer: biblememorizer
bouml: bouml
callgit: callgit
camstream: camstream [alpha amd64 armel hppa i386 ia64 mips mipsel powerpc s390 
sparc]
celestia: celestia-kde [alpha hppa]
cheesetracker: cheesetracker [alpha amd64 armel hppa i386 ia64 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc s390 sparc]
dares: dares-qt
djplay: djplay [alpha amd64 armel hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 
mips mipsel powerpc s390 sparc]
dvbcut: dvbcut [i386]
dvr: dvr [amd64 i386]
earth3d: earth3d
engauge-digitizer: engauge-digitizer
esvn: esvn
extcalc: extcalc
fmit: fmit
freecycle: freecycle [alpha amd64 armel hppa i386 ia64 mips mipsel powerpc s390 
sparc]
fslview: fslview
 fslview-doc
gambas2: gambas2-gb-qt [amd64 armel i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips 
mipsel powerpc s390 sparc]
 gambas2-gb-qt-ext [amd64 armel i386 ia64 kfreebsd-amd64 kfreebsd-i386 
mips mipsel powerpc s390 sparc]
 gambas2-gb-qt-opengl [amd64 armel i386 ia64 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc s390 sparc]
gmod: xgmod [i386]
hamfax: hamfax
hydrogen: hydrogen [hurd-i386]
icomlib: qpcr1k [alpha amd64 armel hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 
mips mipsel powerpc s390 sparc]
ihu: ihu [alpha amd64 armel hppa i386 ia64 mips mipsel powerpc s390 sparc]
ike: ike-qtgui [alpha amd64 armel hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 
mips mipsel powerpc s390 sparc]
k3dsurf: k3dsurf
kbedic/contrib: kbedic
kdevelop: kdevelop [alpha]
kphone: kphone
kseg: kseg
ktorrent: ktorrent [hurd-i386]
libqglviewer: libqglviewer-qt3-2
  libqglviewer-qt3-dev
libqt-perl: libqt-perl [alpha amd64 armel hppa hurd-i386 i386 ia64 mips mipsel 
powerpc s390 sparc]
libqwt: libqwt-dev
libqwt4c2
linamc: linamc [alpha amd64 armel hppa i386 ia64 mips mipsel powerpc s390 sparc]
lipsia: lipsia
lmms: lmms [hurd-i386]
lprof: lprof [alpha amd64 armel hppa hurd-i386 i386 ia64 mips mipsel powerpc 
s390 sparc]
lsb: lsb-desktop
lsb-build-base3: lsb-build-desktop3 [amd64 i386 ia64 powerpc s390]
moto4lin: moto4lin
muse: muse [alpha amd64 armel hppa i386 ia64 mips mipsel

Re: kdelibs3 removal and Qt3 orphaning

[Ana Guerrero]

On Sun, Apr 10, 2011 at 01:59:12PM +0200, Kai Wasserbäch wrote:
> didn't we have an announcement already, where all the science team people
> cropped up and said we can't drop it? Didn't they offer back then to take over
> if the KDE/Qt maintainers dropped it? Can't rememeber this clearly and I'm 
> just
> in the middle of setting up a new notebook so I might not have all e-mails
> around. Anyway, if so, then a normal orphan e-mail to the BTS with the usual
> copy to -devel should be enough IMHO.

There was something like this, but I prefer the approach where you put
the package for sale than the one where you tell them to buy it...
My bet (I hope I will lose it) is we'll have to orphan it.

Ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Qt/KDE team news

[Ana Guerrero]

On Tue, Apr 19, 2011 at 12:49:52PM +0200, Kai Wasserbäch wrote:
> Dear fellow Qt/KDE team members,
> inspired by what Cyril Brulebois' DXN posts about news in the X world, I was
> wondering whether we wouldn't want the same for Qt/KDE? I'd volunteer to write
> these news, but would rely on you to point me to interesting bits and pieces 
> (if
> you have some polished text ready, I won't complain ;) ), just drop me a note 
> at
> [0] and it'll be part of the next news post. As Cyril I'd post this on my blog
> (available at [1]), which is planet.d.o syndicated and should reach a lot of 
> people.
> 
> Let me know whether you find this a good idea or not. If the general opinion 
> is
> in favour I'd start the series with a post about dhmk and getting rid of Qt3 
> in
> a few days, if you have other stuff you'd like to see in that post, write to 
> [0].
> If the majority of you think this is a bad idea, I won't proceed.
>

We are not getting rid of Qt3, we are giving up to adoption. This should be
done via a mail to debian-devel@ although you can of course blog after that!

I am planning to do a blog post about the kdelibs removal once arts is out
with some numbers. But it won't be in the next 2 weeks.


Ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Qt/KDE team news

[Ana Guerrero]

On Tue, Apr 19, 2011 at 03:51:12PM +0200, Kai Wasserbäch wrote:
> 
> judging from Ana's reply to my initial e-mail she is going to continue to do
> this kind of blog posts. Thus I won't proceed with my idea and focus on 
> passing
> bits and pieces for inclusion in such posts on to her.
>

No, no. I will blog about the stuff I have done and removing what is left of
KDE3. I barely have followed the KDE packaging lately and I am not planning to 
blog 
about this.



--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: RFS: eigen3

[Ana Guerrero]

On Mon, May 02, 2011 at 08:53:51PM +0200, Anton Gladky wrote:
> Hi, all
> 
> seems, debian-science team is interested in uploading and maintaining
> this package.
> Is it ok for everybody?
>
> Also after some discussions in debian-science, I propose to pass over
> eigen2 under debian-science, because there can be more interest in it.
> What do you think?
>

About eigen3 please, yes, go ahead and move it to debian-science.

About eigen2, i think it is better we keep it in the kde team until
it is deprecated.

Ana

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: looking for a sponsor for calligra

[Ana Guerrero]

On Wed, Oct 12, 2011 at 06:18:10PM +0200, Adrien wrote:
> As suggested, I re-posted here my message from debian-de...@lists.debian.org 
> to continue the discussion about calligra packaging :
> 
> > Hi,
> > 
> > Calligra, the fork of KOffice, has released its beta 2 version :
> > http://www.calligra-suite.org/news/announcements/calligra-2-4-beta-2/
> > 
> > The debian koffice package has been updated for follow these changes :
> > http://anonscm.debian.org/gitweb/?p=pkg-kde/kde-std/calligra.git;a=summary
> > 
> > 
> > The packaging is now ready and we are looking for a sponsor to include it
> > in the qt-kde repository (http://qt-kde.debian.net/). So experienced users
> > can test it before the official stable release, planned for november or
> > december.
> > 
> > 
> > If you are interested for uploading the package or if you want more
> > information on it, please let me know :-)

Hi!

You do not need a sponsor to upload to that repo, you can upload yourself
directly to kdetrunk (work repo) and then pull it to the another repo.
The best here is you join us in IRC and we guide you, we do not have any
write up instructions about this.

> Ana Guerrero wrote:
> 
> > On Wed, Oct 12, 2011 at 11:06:35AM +0800, Paul Wise wrote:
> 
> >> I think experimental would be a better place for that, please use it
> >> instead of the qt-kde repository.
> > 
> > Probably calligra needs newer version of packages that are not still in
> > Debian, but they are in the qt-kde repository, so no :)
> 
> All the packages needed for calligra are available in Debian testing.
> 
> So experimental could indeed be a good choice for testers.

I thought you were building against the packages in kdetrunk that are already
4.7.2.
Also, based in my experience, I advise you it is not a good idea to upload
packages to the debian archive until there is at least a RC. (this advise
only goes with Calligra, not in general)

Ana

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: kubuntu-low-fat-settings into debian

[Ana Guerrero]

On Fri, Feb 01, 2013 at 08:52:40AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On Fri 01 Feb 2013 05:29:10 l...@telefonica.net escribió:
> > Hi,
> > 
> > first of all, sorry about manners and english. English is not my mother
> > tongue and I'm a newbie in this kind of topics. Recently I've been given a
> > task in an opensource project and I've been required to ask for your
> > guidance. I need to know if it is possible for you to accept the package
> > "kubuntu-low-fat-settings" into debian and how should I port the package
> > to debian. In addition to that I was supposesd to talk to the guys who
> > developed the package, but it has been impossible to contact them.
> > 
> > Thanks,
> > 
> > Elisabeth R.
> 
> Hi Elisabeth!
> 
> I really don't know much about that package nor if we are really interested 
> in 
> it. We will need to review it. If you are really interested in this package, 
> you should be prepared to maintain it yourself.
> 
> With respect to the packaging, take a look at:
> 
> Please check  and 
> 
>

What's more, do you have any long term interest in this package or you just
want to get done some assignment you have been assigned :?



-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: DM application of Adrien Grellier

[Ana Guerrero Lopez]

On Sat, Jul 20, 2013 at 09:18:18PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On Saturday 20 July 2013 22:31:31 Adrien Grellier wrote:
> > This is my declaration of intent to become a Debian Maintainer
> > http://wiki.debian.org/DebianMaintainer>.
> > I have read the Social Contract, Debian Free Software Guidelines and
> > Debian Machine Usage Policy and agree with all of them.
> > Currently, I co‐maintain the packages Calligra and kwebkitpart. I am also
> > participating to the bug triage for the KDE team and to the french
> > translation of the package descriptions.
> > 
> > My GnuPG key AA9F A571 18A2 2E2F 2AAF 2FA2 577C 3237 5327 FCD7
> > is signed by the Debian Developer Damien Raude-Morvan and Mathieu Parent.
> > 
> > I look forward to becoming a Debian Maintainer. Thanks for your attention.
> > 
> > 
> > Adrien Grellier
> > 
> > pe...@adrieng.fr
> > adrien.grell...@laposte.net
> 
> Adrien has been helping in the Qt/KDE team for quite some time, and he has 
> showed skills enough to maintain some of the packages we keep under our 
> umbrella.
> 
> He has also done lots of bug triaging, showing interest and being nice with 
> our users.
> 
> I'm hereby advocating Adrien to become a DM.

I couldn't agree more :)

Ana


signature.asc
Description: Digital signature
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk