Re: Moving to salsa: IRC meeting coordination?

[Sandro Knauß]

Hey,

> So what about this saturday 10, 17 UTC? I'm just reusing Dmitry's proposal,
> I should be able to take other date/time too.

from Friday on I'll be in vacation for one week. But no need to reschedule the 
event because of me.

hefee





signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Further processing kdepim bugs

[Sandro Knauß]

Hey,

> Because they are still valid bugs in Debian. As long as those buggy
> versions are present in the archive they are valid bugs.
> 
> Or at least that's what I understand from the text. If the bugs are not
> really in the archive then it's really ok to close them.

Well the versions for that they are reported are at least oldstable or even 
older. If they are still valid bugs for stable or newer we don't know, if we 
do not check them bug by bug. On the other side, the code of the kdepim 
changed a lot, so many of them may be fixed. This is the reason why upstream 
closed them. Can you please tell me how important this issue is for you? Do 
you think, I should reopen the bugs? 

We also have a bug bunch of bugs, that were not forwarded and are marked for 
versions < 15.08. The question raises, how we handle those. As they were not 
forwarded and not touched for years, but closing those feels wrong. So you 
think sending a slightly different text and making them as wontfix+needsinfo  
would be a good idea?

Any ideas, if and how we can bulk process some of those bugs, to have a 
shorter list of open bugs, we can than look in more detail... Is there a 
better tool than the browser to view/process bugs?

sandro

signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Fwd: Bug#529431: marked as done (akregator: Sometimes "unread" is more then "total")

[Sandro Knauß]

Hey,

> This should be marked as wontfix, not being closed.
> 
> Yes, I sadly saw the thread about this too late, my bad on that side.

Why you think it is better to keep those bugs open? I can understand the 
wontfix tag, but still I think that closing those bugs make it easier to get 
an overview about the current state in kdepim.

sandro


signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Adding salsa to our food^w workflow

[Sandro Knauß]

Hey,

On Mittwoch, 27. Dezember 2017 14:14:32 CET Lisandro Damián Nicanor Pérez 
Meyer wrote:
> El martes, 26 de diciembre de 2017 12:54:22 -03 Boris Pek escribió:
> > >> This is not mutually exclusive, see [1] as example.
> > >> 
> > >> [1] https://salsa.debian.org/salsa/support/issues/1
> > > 
> > > As I understand here is either qa or qa-team, but not both (and this is
> > > what I had in mind when I wrote the previous mail)
> > 
> > I mean: we could create "qt-kde-team" group ourself and then ask for
> > its rename (if necessary) instead of asking of creating group "pkg-qt-kde"
> > and waiting then it is done.
> 
> Ah! Well, I would like to have some input on the other members of the team
> first, we are not in hurry. I guess.

i would prefer qt-kde-team. 

We also need to figure out a way to migrate our git hooks, as they won't be 
available on salsa: https://salsa.debian.org/salsa/support/issues/5

hefee

signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: kdepim 17.08.3 and kde-l10n

[Sandro Knauß]

Hey,

> I'd kindly ask you to hold that until:
> a) KDEPIM 17.08.3 migrates to testing
> b) I sort out the coinstallation issues with kdepim4

my thought was to use experimental to prepare 17.12 and also use a debian/
experimental branch in git to not interfere or do you need experimental to 
prepare something too?

> a) answer users' questions/issues on the users ML
this I try already.

> b) handle bugs for the new versions
this I try already.

> c) possibly triage old bugs

I'm quite bad in triage bugs and keep the overview as we already have multiple 
hundreads of bugs inside kdepim. Does someone has any thoughts, how we may 
manage to triage those? Maybe we have to be realistitic and say everything 
older than 4 years we will close and tell the authos, that we have too less 
manpower to handle the bugs?

> > (17.12 should be much easier, because we only have one new source
> > package: ksmtp [1])
> Sort-of ready in git, but "needs" (thanks Laurent Montel for the
> unneeded requirement bumps) newer Frameworks than what is in unstable.

as I said - prepare in experimental :D

hefee



signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: kdepim 17.08.3 and kde-l10n

[Sandro Knauß]

Hey,

I added the release team list, cause they may help explaining interpret the 
britney output.
And help to find the right buttons to push, to get kdepim migrating to testing.

> > I tried to understand, why kdepim hasn't moved to testing, but I don't
> > understand the britney output completely.
> 
> I don't either, but let's see.

well I looked at the documentation to understand the output better: 
https://release.debian.org/doc/britney/short-intro-to-migrations.html

But still I'm not completely sure how to interpret the output :D
If I'm not wrong, than the first try to install complete kdepim as one set is 
the one we should care about:

trying: kleopatra libkf5libkleo kmail-account-wizard libkf5pimcommon 
akonadi-contacts kf5-kdepim-apps-libs kaddressbook akonadi-search akonadi-mime 
libkf5mailcommon pim-data-exporter libkf5libkdepim libkf5eventviews libkf5calend
arsupport kholidays kalarmcal kcalcore kdepim-runtime kmbox kmime 
kf5-messagelib kmailtransport akonadi-import-wizard kdepim-addons kimap 
kpimtextedit kidentitymanagement mbox-importer korganizer kcontacts ktnef 
kcalutils libkol
ab akonadi kalarm kmail libkf5ksieve libkf5gravatar -kdepim kldap syndication 
kblog akregator libkf5grantleetheme kontact pim-sieve-editor 
libkf5incidenceeditor akonadi-calendar blogilo knotes akonadi-calendar-tools 
libkf5mailim
porter akonadi-notes akonadiconsole libkgapi


skipped: kleopatra libkf5libkleo kmail-account-wizard libkf5pimcommon 
akonadi-contacts kf5-kdepim-apps-libs kaddressbook akonadi-search akonadi-mime 
libkf5mailcommon pim-data-exporter libkf5libkdepim libkf5eventviews libkf5calen
darsupport kholidays kalarmcal kcalcore kdepim-runtime kmbox kmime 
kf5-messagelib kmailtransport akonadi-import-wizard kdepim-addons kimap 
kpimtextedit kidentitymanagement mbox-importer korganizer kcontacts ktnef 
kcalutils libko
lab akonadi kalarm kmail libkf5ksieve libkf5gravatar -kdepim kldap syndication 
kblog akregator libkf5grantleetheme kontact pim-sieve-editor 
libkf5incidenceeditor akonadi-calendar blogilo knotes akonadi-calendar-tools 
libkf5maili
mporter akonadi-notes akonadiconsole libkgapi (6, 1706, 170)


got: 39+0: a-2:i-24:a-0:a-0:a-0:m-0:m-3:m-0:p-0:s-10


* s390x: education-desktop-kde, kde-full, kde-standard, kdepim, 
kf5-kdepimlibs-kio-plugins, knotes, konsolekalendar, korganizer, 
task-pkgs-are-installable-faux  
   
- splitting the component into single items and retrying them

If I compare the trying line with all packages inside kdepim i see, that 
grantlee-editor, kdav, kgpg and kontactinterface are missing in that list.
kdav is already migrated. From kgpg and grantlee-editor nothing depends on, so 
we can skip them.
The only missing package we care at this migration is kontactinterface, that 
explains, why korganizer, knotes will be uninstallable in testing.
Maybe it is easier to see these dependencies in graphs:
https://pkg-kde.alioth.debian.org/applications-17.08-build-deps.html
Because both depend on kontactinterface.
And because korganzier >= 17.08 won't be in testing konsolecalender can't 
migrate, because it breaks against korganzier <= 17.08.
education-desktop-kde, kde-full, kde-standard look fine for me, possible, 
because of korganzier and knotes not migrating having issues.
kdepim, kf5-kdepimlibs-kio-plugins both getting unstallable is fine, cause they 
should be removed form testing.

Keep in mind I only added here some of the britney output for kdepim, the two 
other samples are part of the
"splitting the component into single items and retrying them", maybe those are 
not fine to look at...

> > For me it looks that we missed the removals for armhf. Only armhf have
> > conflicting packages like:
> > 
> > trying: kdepim-addons
> > skipped: kdepim-addons (0, 2784, 136)
> > 
> > got: 31+0: a-2:i-24:a-0:a-0:a-1:m-0:m-3:m-0:p-0:s-1
> > * armhf: kdepim-addons
> 
> This does not tell me anything.
> 
> > trying: libkolab
> > skipped: libkolab (0, 2762, 158)
> > 
> > got: 47+0: a-2:i-24:a-0:a-0:a-17:m-0:m-3:m-0:p-0:s-1
> > * armhf: education-desktop-kde, kde-full, kde-standard, kdepim,
> > kdepim-runtime, kmail, knotes, konsolekalendar, kontact, korganizer,
> > libkolab-dev, libkolab1, python-kde4, python-kolab, python3-kolab,
> > python3-pykde4, task-pkgs-are-installable-faux
> Ditto, although this gives me two hints:
> - pykde4 will migrate tomorrow
> - 

Re: kdepim 17.08.3 and kde-l10n

[Sandro Knauß]

Hey,

> Yes, so far there are no blocking issues on our side, so I'd wait for
> the stack to migrate, and then we can do eventually more uploads.
> Of course, feel free to add your changes to git in the meanwhile
> (pushing them, heh).

That's why I didn't want to dig into it, because I wanted to ask before I 
break something :D

> 
> > #885111 kdepim-runtime: kdepim-runtime depends on libkolab-dev
> Just an annoyance, it can wait IMHO.
fixed in git :D


> > #885148 kleopatra depends on deprecated packages
> Already fixed in git.
> > #869647 kleopatra: Missing dependency to libkf5libkleo-data
> This is already fixed in unstable.
cool

(maybe we should think about adding a git hook for marking bugs as pending?)

Yeah I knew, that more stuff was needed according to the transition. Thanks 
for all your work and sharing what is "done behind the scene". If there is 
more I should take care of?

hefee

-- 
Ich habe meinen Schlüssel gewechselt / I've switched my GnuPG key:
http://sandroknauss.de/files/transition2015.asc

Mein (neuer) öffentlicher Schlüssel / My (new) public key: E68031D299A6527C 
Fingerabdruck / Fingerprint:
D256 4951 1272 8840 BB5E  99F2 E680 31D2 99A6 527C 
Runterladen z.B. bei/ Get it e.g. here:
pool.sks-keyservers.net, ...

signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: kdepim 17.08.3 and kde-l10n

[Sandro Knauß]

Hey,

now we got some issues for the new kdepim 17.08 stack. What is the best way to 
go on? fix them "as fast as possible" or better wait till it migrates to 
testing? I'm thinking, if it may break the tessting migration, if we upload 
here a new kdepim-runtime here a new whatsoever...

#885111 kdepim-runtime: kdepim-runtime depends on libkolab-dev
#885148 kleopatra depends on deprecated packages
#869647 kleopatra: Missing dependency to libkf5libkleo-data

hefee

-- 
Ich habe meinen Schlüssel gewechselt / I've switched my GnuPG key:
http://sandroknauss.de/files/transition2015.asc

Mein (neuer) öffentlicher Schlüssel / My (new) public key: E68031D299A6527C 
Fingerabdruck / Fingerprint:
D256 4951 1272 8840 BB5E  99F2 E680 31D2 99A6 527C 
Runterladen z.B. bei/ Get it e.g. here:
pool.sks-keyservers.net, ...

signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Fwd: KGlobalAccel regression in latest frameworks release

[Sandro Knauß]

Hey,

a new release was released and the problem was fixed :)

--  Forwarded Message  --

Subject: kglobalaccel 5.38.1
Date: Donnerstag, 14. September 2017, 10:07:16 CEST
From: Jonathan Riddell <j...@jriddell.org>
To: KDE release coordination <release-t...@kde.org>, kde-distro-
packag...@kde.org

kglobalaccel had a regression which stopped some keyboard shortcuts
from working.

I've updated the tar to revert the problem change.

https://download.kde.org/stable/frameworks/5.38/kglobalaccel-5.38.1.tar.xz

sha1
fbadac6c9b7a934ef114df948425ab537a58a555  kglobalaccel-5.38.1.tar.xz

signed by my key
2D1D 5B05 8835 7787 DE9E  E225 EC94 D18F 7F05 997E
Jonathan Riddell <j...@jriddell.org>

This will be needed if you plan to package the Plasma 5.11 beta due
out momentarily.

Jonathan

--
On Donnerstag, 14. September 2017 09:21:59 CEST Maximiliano Curia wrote:
> On September 13, 2017 10:47:18 PM GMT+02:00, "Sandro Knauß" 
<he...@debian.org> wrote:
> >Hey,
> >
> >i think we also should look at this issue.
> >
> >sandro
> >
> >--  Forwarded Message  --
> >
> >Subject: KGlobalAccel regression in latest frameworks release
> >Date: Mittwoch, 13. September 2017, 18:23:48 CEST
> >From: Martin Flöser <mgraess...@kde.org>
> >To: plasma-de...@kde.org, kde-frameworks-de...@kde.org,
> >release-t...@kde.org
> >CC: j...@jriddell.org
> >
> >Hi all,
> >
> >unfortunately I have to inform you that KGlobalAccel has a severe
> >regression [1] in the latest framework release resulting in many
> >shortcuts no longer functioning.
> >
> >As the current frameworks release is the one the next Plasma release is
> >
> >going to depend on, we need to act quickly. In the current state I
> >would
> >say a release of Plasma requiring this frameworks version is an
> >absolute
> >no-no, this is release blocking. I'm saying this as the maintainer of
> >kglobalaccel and of the most affected application KWin.
> >
> >Following recommendations from my side:
> >* distributions who have not yet shipped out the latest frameworks
> >release should hold back kglobalaccel and maybe kwindowsystem
> >* in KGlobalAccel we need to get a fix for it, I'm not able to provide
> >it, though.
> >* Otherwise I would suggest that the change in KGlobalAccel gets
> >reverted
> >
> >Due to the fact that Plasma depends on this release we must act quickly
> >
> >and do a bug fix release for frameworks even if this is uncommon and
> >against the practice.
> >
> >Sorry for any inconveniences.
> >
> >Martin Flöser
> >KGlobalAccel maintainer
> >
> >[1] https://bugs.kde.org/show_bug.cgi?id=384597
> >
> >-
> 
> This is for kf 5.38, we can wait till 5.39.



signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

pkgkde-vcs issues

[Sandro Knauß]

Hey,

i actually uploading the fixes for jessie and stretch for CVE-2017-9604.
#869573
#869574
#869577

and therefor I have in the distribution field stretch/jessie and this is not 
handled 
$pkgkde-vcs tag -s
pkgkde-vcs: fatal: invalid Debian distribution for tagging - stretch

this issue is reported under #873243.

And than also the upload of the tag is not allowed for messagelib but for 
kdepim it worked...

here kdepim:

git push origin debian/16.04.3-4-deb9u1
Counting objects: 1, done.
Writing objects: 100% (1/1), 860 bytes | 860.00 KiB/s, done.
 
Total 1 (delta 0), reused 0 (delta 0)   
remote: *** hooks.recipients is not set so no email will be sent
remote: *** for refs/tags/debian/16.04.3-4-deb9u1 update 
-
>530b457b9d0df6f6ab3d11fff7e4ffdbd059779b
remote: Requesting Neon Repository Update
remote: Notifying CI systems
To ssh://git.debian.org/git/pkg-kde/applications/kdepim 
 * [new tag] debian/16.04.3-4-deb9u1 -> debian/16.04.3-4-deb9u1 
 


an messagelib:

git push origin debian/16.04.3-3-deb9u1 
Counting objects: 1, done.  
Writing objects: 100% (1/1), 865 bytes | 865.00 KiB/s, done.
 
Total 1 (delta 0), reused 0 (delta 0)   
remote: [ REJECTED ] refs/tags/debian/16.04.3-3-deb9u1: expected tag name to 
match (^debian/(4\%16\.04\.3\-3_deb9u1|16\.04\.3\-3_deb9u1)$) does not match 
reality (debian/16.04.3-3-deb9u1)
remote: error: hook declined to update refs/tags/debian/16.04.3-3-deb9u1
To ssh://git.debian.org/git/pkg-kde/applications/messagelib 
 
 ! [remote rejected] debian/16.04.3-3-deb9u1 -> debian/16.04.3-3-deb9u1 (hook 
declined)  
error: failed to push some refs to 'ssh://he...@git.debian.org/git/pkg-kde/
applications/messagelib'

it sounds that the hooks are not the same for both repos...

Best regards,

sandro

signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Bug#864803: CVE-2017-9604: Send Later with Delay bypasses OpenPGP

[Sandro Knauß]

Hey,

I'm AFK from tomorrow one for at least one week, so I can't upload the 
packages in that time. I will not be the reason, why a security issue is 
longer than needed open. So use my debdiff as a "good" start to get this 
security issue fixed in stretch and jessie :) I think it will only changes of 
the concrete version number. I don't care in the end you is uploading the fixes 
:)

Best Regards,

sandro

--
On Samstag, 17. Juni 2017 09:12:29 CEST Sandro Knauß wrote:
> Hey,
> 
> I have now have a fixed version for stretch and sid (see debdiff). Because
> Debian is currently in the release process, I'm not sure, how to
> upload/handle the fix for stretch.
> 
> Best Regards,
> 
> sandro



signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Update of Maintainers line in changelog in QtWebEngine

[Sandro Knauß]

Hey,

Many many thanks for starting to updating QtWebEngine Qt 5.9! 

please do not update the maintainers line in d/changelog, if the package is 
not released. You did this both in QtWebEngine - see
62d8cc8c6cb76218485fc4c6155cc44a1b869b4a 
eb04798274417ab265cbc2a468352820021c2539

First updating the whole line do not need at all will we are in UNRELEASED 
mode and the changes of the maintainers line makes it harder to review /
cherry-pick and is unnecessary clutter in diffs.

Please see https://pkg-kde.alioth.debian.org/changelogstandard.html and update 
your /etc/devscripts.conf

@Simon: Can you say what happens to replace_gyp_files.py? Is there a new way to 
make the same? Have you done some research about this?

Everything else looks like nice work :) Okay nobody has updated the copyright 
file * sigh*, so I think nobody has cared about this so far :(

Best Regards,

sandro

signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Packaging PythonQt for Qt 5

[Sandro Knauß]

Hey,

the SVN link actually pointed me to look at who is actually the maintainer of 
pythonqt and saw, that is not Debian KDE Maintainers. It is the QA Team
. So that are the people that you need to talk to, 
because only those can add your work. Additonally they may have other rules 
how work should be done.

> Actually uploading to mentors.debian.net might be better. A pointer to the
> SVN is also not bad.

+1

> Python is definitely not my area, so I'm afraid I can't help here.

mine yes :)

Some general things:
compat level update to 10 ( that should be used nowadays):
 * see man 7 debhelper
with that you can rid of  --parallel ( it is default with v10)
but bumping the compat level is some thing the maintainers of package needs to 
do, it may be circumstances not to bump that. But try it if it builds with v10 
is a good thing to do.
-> would also need you to update to debhelper (>= 10) in control
* also checking the Standards-Version and bumping this is also a task to do 
before uploading a new version.
*are there tests to run / need to build seperatly?
* are the patches will  go upstream? Please use dep3 styple for patches:
http://dep.debian.net/deps/dep3/
I use "quilt header -e --dep3" to create such headers.
* did you checked if there are packagages using the dev packages? If yes, 
there needs to be a transition requested, because all packages needs to 
rebuilt...

But still I'm not maintainer of this package, so I can't tell you if they also 
what these changes.

Best Regards,

sandro

signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Packaging PythonQt for Qt 5

[Sandro Knauß]

Hey,

> How can I submit my packaging changes for review? Are you using pull
> requests somewhere?

there is no "formal way" nor pull request. The normal workflow is to use 
mentors and personal repos and send the link around.

* mentors.debian.org
* https://wiki.debian.org/Alioth/Git#Forking_Git_repositories_onto_Alioth

( You can use every other git hosting platform, if you wish)

After some time we will grant you permission to push to git directly. 

Hopefully this works for you.

Best Regards,

sandro


signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: QtWebEngine build fails

[Sandro Knauß]

Hi,

Thanks for all your input till now.

I now managed it to get it build on i386 successfully on buildds 
(5.7.1+dfsg-2) [0] so it uses less RAM but still it needs around 15GB disk 
space to build. It actually also used to much RAM for an successfull amd64 
build on buildds. The fix I did was to disable all debug symbols for all archs 
(including amd64), because all buildds do not have more than 4GB of RAM :( So 
QtWebEngine can't be rebuild at porterboxes with this limit and debug symbols 
activated. Can this be improved somehow, so I still can push source only 
uploads?

mipsel and armhf builds still look like they are not happy with the amount of 
build space.  It looks like their buildd disk space limit is 8GB. Are there 
buildds with bigger disks?

Never the less QtWebEngine is a NEW package and only amd64 is RC for now, so 
you may have more important tasks to do...

Best Regards,

sandro

[0] 
https://buildd.debian.org/status/logs.php?pkg=qtwebengine-opensource-src=i386



signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: post-receive hook

[Sandro Knauß]

Hey,

> Sorry but I don't get you. Are you talking about adding a hook in alioth's
> repos?

yes exactly I'm talking about pkg-kde repos on alioth - sorry I was not that 
precise in my first mail: here is the diff (git.debian.org):

--- /git/pkg-kde/pkgkde-post-receive-hook~  2016-01-05 12:54:43.989698779 
+
+++ /git/pkg-kde/pkgkde-post-receive-hook   2016-12-25 14:32:25.007579406 
+
@@ -1,4 +1,6 @@
 #!/bin/sh
 read line
 /git/pkg-kde/git-commit-notice $line
 /git/pkg-kde/debian-to-neon-post-receive $line
+# https://wiki.debian.org/Alioth/Git#Setting_up_hooks
+/usr/local/bin/git-post-receive-tag-pending $line

Best regards,

sandro

signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: QtWebEngine build fails

[Sandro Knauß]

Hey,

it looks like QtWebEngine[0] fails on armhf because there is too less ram/
space for building [1]:
/usr/bin/ld.gold: fatal error: libQt5WebEngineCore.so.5.7.1: Cannot allocate 
memory

Best Regards,

sandro

[0] https://tracker.debian.org/pkg/qtwebengine-opensource-src
[1] 
https://buildd.debian.org/status/fetch.php?pkg=qtwebengine-opensource-src=armhf=5.7.1%2Bdfsg-1=1482632568

--
Am Sonntag, 25. Dezember 2016, 02:14:12 CET schrieb Sandro Knauß:
> Hey,
> 
> qtwebengine [0] entered sid today and unfortunately it failed for some
> archs. well it is one of those packages, that needs more than 4GB RAM/space
> for building. IMO I think the i386 build failed just because the buildd has
> not enough ram/space for the build. [1]
> For armel[2] i'm not sure what package I should add to build-deps:
> libc6-dev-armel-cross, libc6-dev-armhf-cross or libc6-dev, can you give me a
> suggestion what to select?
> 
> Best Regards,
> 
> sandro
> 
> --
> [0] https://tracker.debian.org/pkg/qtwebengine-opensource-src
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=qtwebengine-opensource-src
> rch=i386=5.7.1%2Bdfsg-1=1482612327 [2]
> https://buildd.debian.org/status/fetch.php?pkg=qtwebengine-opensource-src
> rch=armel=5.7.1%2Bdfsg-1=1482604118



signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

QtWebEngine build fails

[Sandro Knauß]

Hey,

qtwebengine [0] entered sid today and unfortunately it failed for some archs.
well it is one of those packages, that needs more than 4GB RAM/space for 
building. IMO I think the i386 build failed just because the buildd has not 
enough ram/space for the build. [1]
For armel[2] i'm not sure what package I should add to build-deps:
libc6-dev-armel-cross, libc6-dev-armhf-cross or libc6-dev, can you give me a 
suggestion what to select?

Best Regards,

sandro

--
[0] https://tracker.debian.org/pkg/qtwebengine-opensource-src
[1] 
https://buildd.debian.org/status/fetch.php?pkg=qtwebengine-opensource-src=i386=5.7.1%2Bdfsg-1=1482612327
[2] 
https://buildd.debian.org/status/fetch.php?pkg=qtwebengine-opensource-src=armel=5.7.1%2Bdfsg-1=1482604118

signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Bug#844247: akonadi-googledata: RM akonadi-googledata - Upstream is dead and kdepim is using libkgapi

[Sandro Knauß]

Source: akonadi-googledata
Severity: important

Hey,

I would request to delete akonadi-googledata for stretch, because:
 * upstream is dead for around four year
 * not needed anymore, because libkgapi
 * an akonadi-resource for google data is created directly in
   kdepim-runtime package depending on libkgapi
 * is used by kdepim based on KDE 4 on unstable we have kdepim depended
   on KF 5
 * akonadi4 do not ship anymore a akonadi binary, so there is nothing
   that could consume that akonadi resource (akonadi resources build
   against Qt4/KDE4 are not compatible with Qt5/KF5)
 * it is a leaf package - no reverse dependencies.

For users, using kdepim they need kdepim-runtime to be installed to have the new
google resources available, but kdepim-runtime is already a hard
dependency for kdepim (kontact, kmail, korganizer) packages, so we do not need
to provide a special upgrade path.

The only problem that can occur for users, is that the new akonadi don't
do a default upgrade to the new resource. But the upgrade process from
akonadi4 -> akonadi5 must be done anyways and this old package isn't
helping in this upgrade process.

Best Regards,

Sandro Knauß

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

Re: Request for help / review / sponsors: kpmcore

[Sandro Knauß]

Hi,

warm welcome in packaging world !

so I started to review the version on mentors. My comments may be too short to 
you to understand, feel free to ask if you don't understand a point or have 
different opinion in some points, some of the points are recommendations. 

d/control:
* why you use only i386 and amd64 in your control file? It should be "any" to 
be built on any arch
* Replaces: libkpmcore2 / Replaces: libkpmcore2-dev should be removed, because 
we have not these pacakges in Debian. Btw. you combile Replace with Conflicts 
or Breaks. But normally these are not needed.
* should i be part of the Qt/KDE Debian/Ubuntu umbrella?
*update the VSC links to debian ons

* rename dev package to kpmcore-dev ( or is the API that version dependend?) 
* bump to debhelper 10 

d/watch
* bump to uscan version 4 that has nice features @PACKAGE@, @ANY_VERSION@, etc 
that makes watch list easier to copy around. [1]

d/copyright:
cmake/modules/FindLIBPARTED.cmake is BSD-3-clause

d/rules:
* for c++ ABIs you really want to use symbols-helper, because it helps you 
marking internal symbols as those. [2] Please follow the reference how to use 
the pkgkde-symbolshelper and update the symbolsfile accordingly. [3]
Than you don't need no  override_dh_makeshlibs. Btw. the upstream version you 
can get by use "include /usr/share/dpkg/default.mk" after that you have 
DEB_VERSION_UPSTREAM.

d/libkmpcore3.install
* split everything that is not the lib itself to another package (kpmcore-
plugins)
  -> do you know who consumes the qt5 plugins?

Best Regards,

sandro


[1] https://anonscm.debian.org/git/pkg-kde/qt/qtwebchannel.git/tree/debian/
watch
[2] https://anonscm.debian.org/git/pkg-kde/qt/qtwebchannel.git/tree/debian/
rules#n15
[3] http://pkg-kde.alioth.debian.org/symbolfiles.html

Am Donnerstag, 10. November 2016, 19:52:24 CET schrieb Jonathan Carter:
> Hi Debian Qt/KDE Maintainers!
> 
> I need some assistance with packaging a library called kpmcore.
> 
> Upstream git: https://github.com/KDE/kpmcore
> ITP: https://bugs.debian.org/810063
> RFS: https://bugs.debian.org/837748
> My package on mentors: https://mentors.debian.net/package/kpmcore
> 
> It works and lintian doesn't complain, but I'm new to C++ and KDE
> packages so any feedback would be appreciated.
> 
> thanks!
> 
> -Jonathan



signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: QtWebEngine ready for upload

[Sandro Knauß]

Hey,
 
> Please rename the binary packages for consistency with other Qt modules:
> 
> * libqt5webengine-dev → qtwebengine5-dev  (cf. qtbase5-dev)
> * qt5webengine-examples → qtwebengine5-examples  (cf. qtbase5-examples)
> * qt5webengine-doc{,-html} → qtwebengine5-doc{,-html}  (cf. qtbase5-doc)

Done.
 
> Which script did you use for generating debian/copyright?
> It would be nice to get that documented in debian/README.Debian
> (with instructions on how to update that file for newer releases).

I used the script created by maxy (don't find the url again). But sofar the 
tool is not suitible to update a existing copyright file and still needs a lot 
of love afterwards. But maybe maxy has some workflow, how he used the tool for 
update.

I did the update from 5.6.1 -> 5.7.1 by creating a script that using a patch 
of the update and than split by what changed:
file deleted -> remove the entry from copyright
file added/modified check license by mxay script vs. the license that is in 
copyright file.

but stil this was a lot of handmade work.

Maybe i should make this script ready for use for others.

> There are also some weird entries there, like:

made another round in copyright file do delete those entries.

Regards,

sandro


signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: gpgme 1.7.0~ alpha or beta to debian experimental?

[Sandro Knauß]

Hey,

> >> -PIC implies -fPIE. Replacing -fPIE with -fPIC is the right thing to do,
> >> and is needed to get the code working with Qt 5.4.2+.
> > 
> > And also: yes, -fPIE needs overriding if using hardening flags.
> 
> can you explain that in more detail?  what specifically should be
> overridden and where?

Yes, this is exactly also my questions, because I'm puzzeld with all these 
buildflags...

regards,

sandro

-- 
Ich habe meinen Schlüssel gewechselt / I've switched my GnuPG key:
http://sandroknauss.de/files/transition2015.asc

Mein (neuer) öffentlicher Schlüssel / My (new) public key: E68031D299A6527C 
Fingerabdruck / Fingerprint:
D256 4951 1272 8840 BB5E  99F2 E680 31D2 99A6 527C 
Runterladen z.B. bei/ Get it e.g. here:
pool.sks-keyservers.net, ...

signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: kmail CVEs and patches

[Sandro Knauß]

Hey,
 
> I tried to backport the CVE-2016-7966 fix commit to kf 5.26 and it didn't
> apply cleanly, it would be nice if the advisory includes the list of the
> commits to backport, or maybe a new 5.26.1 kcoreaddons bugfix release.

Yes another patch is missing there - I already informed them and hopefully 
they will update the infos. I also asked if they will ship a updated 5.26 
version.

> About: https://www.kde.org/info/security/advisory-20161006-3.txt
> 
> Via irc you mentioned that non qtwebengine versions are affected by this as
> well, that contradict the versions listed in the advisory message. As you
> know, we are currently using qt 5.6 and messagelib from 16.04, which set of
> patches should we include?

No I misread the CVE. There is nothing to do here.

Regards,

sandro


signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: [d...@fifthhorseman.net: Re: gpgme 1.7.0~ alpha or beta to debian experimental?]

[Sandro Knauß]

Hey,

> I'm not entirely sure what to do about the name of the library during
> this handoff -- it might drop the "kf5" prefix.  If we don't drop the
> "kf5" prefix, i suppose we'll need an epoch number in the package
> version to make sure that upgrades happen.  It's also possible that
> we'll need to do a similar thing with qgpgme, i guess.

the libs gpgme installs are without the kf5 prefix, so we have should also name 
the package like the libs without kf5 prefix. So we don't end up in having the 
same package names, what makes the life easier for the transition :)

I'll hope I will finish the build of c++/qt bindings the next days and will 
publish them at a private clone of the debian repo, so dkg can check my 
changes before pulling them in. Just to make sure, I don't break your workflow.

Regards,

sandro

signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: gpgme 1.7.0~ alpha or beta to debian experimental?

[Sandro Knauß]

Hey,

I now started to build cpp and qt bindings for gpgme but ran into a issue with 
the hardening flags. The problem is the -fPIE. With this enabled configure 
stops with:
configure:19628: checking whether a simple qt program can be built
configure:19639: g++ -o conftest -g -O2 -fdebug-prefix-map=/<>=. 
-fPIE -fstack-protector-strong -Wformat -Werror=format-security 
-I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/include/x86_6
4-linux-gnu/qt5 -fpic -fPIE -pie -Wl,-z,relro -Wl,-z,now conftest.cpp -lQt5Core 
>&5
In file included from 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qcoreapplication.h:37:0,
 from 
/usr/include/x86_64-linux-gnu/qt5/QtCore/QCoreApplication:1,
 from conftest.cpp:33:
/usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1087:4: error: #error "You 
must build your code with position independent code if Qt was built with 
-reduce-relocations. " "Compile your code with -fPIC (
-fPIE is not enough)."
 #  error "You must build your code with position independent code if Qt was 
built with -reduce-relocations. "\
^

full log: 
http://sandroknauss.de/files/gpgme1.0_1.7.0-2_amd64_with_hardening.build
with hardening disabled it builds successfully and also via replacing -fPIE 
with -fPIC, but than lintian is unhappy about the missing -fPIE for gpgme-tool.
http://sandroknauss.de/files/gpgme1.0_1.7.0-2_amd64_without_hardening.build

How do I need to change the CPP/C++/CFLAGS, so we get what we want? Or is this 
a bug from Qt side?

Regards,

sandro

Am Donnerstag, 22. September 2016, 17:44:38 CEST schrieb Daniel Kahn Gillmor:
> On Sat 2016-09-10 13:00:26 -0400, Daniel Kahn Gillmor wrote:
> > As i understand it from a talk given by Andre Heinecke (GPGME upstream,
> > cc'ed here) at OpenPGP.conf, GPGME 1.7.0 is likely to take over as
> > upstream from pyme, gpgmepp, and qgpgme.  (it will also add a
> > common-lisp binding, but that's not in debian at all, so i'll ignore it
> > for now).  1.7.0 isn't yet released, but it sounds like the release is
> > due fairly soon.
> 
> 1.7.0 was released a couple days ago, and i just uploaded it to debian
> unstable, along with a fair bit of debian packaging cleanup.
> 
> The source package i uploaded currently only builds the C library.  It
> does not build or attempt to ship the python, common-lisp, c++, or qt
> bindings yet.
> 
> > I don't think it'd be unreasonable for the debian GnuPG packaging team
> > take on these additional binary packages within the gpgme1.0 source
> > package, which would mean that the source packages for python-pyme, and
> > gpgmepp would probably go away, and the kdepimlibs library would stop
> > building libqgpgme1 and libgpgme++2v5.
> 
> I plan to work in experimental for a version that will produce the
> python3 bindings -- binary package python3-pyme in particular.  I'm not
> yet aiming to "hijack" the 2.x bindings with this source package, since
> i haven't heard from Arnaud.
> 
> Arnaud, at some point we should let the gpgme1.0 source package take
> over the python-pyme binary package, though, since i understand that it
> is now python2-compatible upstream.  I haven't heard back from you here,
> but given that the transition has happened upstream, i hope it will be
> OK.  Would you like to help out with this?  I'd be happy to have your
> input and experience on the python bits (and elsewhere if you're
> willing).
> 
> If someone wants to collaborate on doing the same kind of work for qt
> and c++, i'm happy to coordinate via the pkg-gnupg-maint git repo,
> and/or on IRC #debian-gnupg on oftc.
> 
>--dkg



signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Qt install binary path

[Sandro Knauß]

Hey,
 
Thanks a lot for uploading!

> Well, yesterday I took your branch and build it without issues (tests ran
> just fine). But somehow buildds seems to disagree with me, as it seems a
> test is failing there.
> 
> Is there anything I might be missing?

I don't know. From the tests it is the qmlplugindumper, this actually should 
list all plugins. So it maybe a problem for him to find the correct path for 
the plugins? Maybe some envrionment variable got from our systems ( with a 
KDE5 running) into sbuild and makes the test passing? Or any writepermission 
on the buildds stops one try to write a file?

The passing powerpcspe build looks like that it fails to start xvfb or dbus, 
so it goes on with installation right away.

Regards,

sandro


signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Qt install binary path

[Sandro Knauß]

Hey,

I try currently to enable tests for qtdeclarative. So far it all works fine, 
but the tests using:
QLibraryInfo::location(QLibraryInfo::BinariesPath) + QLatin1String("/
qmlscene")

to run qmlscene. The problem with that is that qmlscene is also part of the 
package and is not installed obviously.
The binary is already build in $(CURDIR)/bin.
But the Qt Documentation tells that QLibraryInfo always returns a hardcoded 
path, that can't be changed.
Is there a way to treat the tests to use the new builded qmlscene?
Or should I change the tests to not use QLibraryInfo?

See my repo about the way I run the tests:
https://anonscm.debian.org/cgit/users/hefee-guest/qtdeclarative.git/tree/
debian/rules
(sidenote: As a workaround I install qmlscene and qtdeclarative5-dev-tools to 
pass the tests,
just if you are wondering about the debian/control in my repo).

Best Regards,

sandro


signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: QtWebChannel ready for upload

[Sandro Knauß]

Moin,

> Uploaded with some packaging tweaks and improvements, thanks!
> 
> Please tag the upload when it is accepted.

done.

Regards,

sandro

signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

QtWebChannel ready for upload

[Sandro Knauß]

Hey Lisandro,

I uploaded QtWebChannel to mentors. I think it is ready for upload now:
https://mentors.debian.net/debian/pool/main/q/qtwebchannel-opensource-src/qtwebchannel-opensource-src_5.6.1-1.dsc

Can you sponsor it?

Regards,

sandro


signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Getting QtWebChannel ready for upload

[Sandro Knauß]

Hey Dmitry,

> On Debian this should be nodejs rather that node (see #614907).

Oh thanks for this notice. But changing the node -> nodejs results now in 
another lintian warning:
W: qtwebchannel-examples: script-not-executable usr/lib/x86_64-linux-gnu/qt5/
examples/webchannel/qwclient/qwclient.js

the env line is:
#/usr/bin/env nodejs


regards,

sandro


signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Getting QtWebChannel ready for upload

[Sandro Knauß]

Hey,

Maybe we should use gobby for our uptodate TODO list (install the package 
named gobby). I used now gobby.debian.org/Teams/KDE/qtwebengine.

I think than we will follow the normal qt package rules and create a example, 
doc and doc-html packages to be consistant. My answers about merging things 
together was based without looking to other qt packages ( sorry for that)

>>* I would remove the patch examples_full_path.diff, because it only touches
>> examples and there the privacy breach to not hold in my eyes - What do you
>> think?
>I think it's a privacy breach non the less which is quite easy to fix. Extra  
points if a proper patch for doing this at build time is upstreamed.

Well the patch with linking to a Debian copy of jQuery can break the example, 
if the version is not exactly the same they depend on. And the example wants 
1.4.2 and debian has 1.2.0. I know from packaging webapps based on jQuery, 
that jQuery change their API often and thats why many packages in Debian store 
a internal copy of the version of jQuery they need. (I know this is not the 
way to go). That's why I recommend to don't link to the internal jQuery, 
because broken example are really bad and more a problem than the privacy 
beach. And it is a matter of fact, that the examples are used not very often, 
so we will see the error much later :(

But lisandro is right, never the less all the errors are valid privacy 
beaches, so we should not override them in lintian and keep the warnings as 
reminders, that we should fix them in future.

> examples_full_path.diff

if we keep the patch, than we should also add dep3 headers, yes.

> - debian/rules: 
 > * qmake will not take those flags. And if it did that would be a problem, as 
 >  
hardening enables -fPIE but we require -fPIC (which already implies -fPIE, but 
you can't use both at the same time).
already removed again

>  * qmake QT_BUILD_PARTS+=" src" ← why that?
will try if it is necessary

>* make install INSTALL_ROOT=$(CURDIR)/debian/tmp ← why not using 
dh_auto_install? check for example qtsensors.
fixed already

> * Missing -v in first and last rm call.
will add this.

> > > - debian/.directory really?
> Good question :) A Plasma/dolphin file that should have never been there :)

should be deleted. I overseen the file, because it is hidden :D
 
> [snip]
> 
> > In the future, when I refer to my branch/repo, it's hosted here:
> > https://git.launchpad.net/~tsimonq2/+git/qtwebchannel . Please always
> > pull from that.
> 
> Keep up the good work and it won't be long before any of us gives you commit
> access :)

+1

> >> P: libqt5webchannel-dev: example-unusual-interpreter usr/share/doc/
> >> libqt5webchannel-dev/examples/webchannel/qwclient/qwclient.js #!node
> So Sandro, this means it's fixed? If not, I have no clue either.

no I just looked what interpreter is set in the source file and this one is a 
correct one, so it is a debian tool changing the interpreter. So someone needs 
to investigate this.

Regards,

sandroy

signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: GpgME C++ / Qt language providers ready for merge?

[Sandro Knauß]

Hey,

> looks reasonable to me.  I'm assuming that in debian, we'd have the
> gpgme1.0 package (maintained by pkg-gnupg-maint) take over the binary
> packages from the gpgmepp souce package (maintained by the Debian Qt/KDE
> maintainers).  I've cc'ed both groups on this e-mail so that people are
> aware of the situation.

Ah, this information is already spreading around :D That is good. Yes,  Debian 
Qt/KDE maintainers would have to remove KF5GpgMEpp. But if I see it correcly 
we won't need to react directly and can wait till all application are switched 
over to gpgmepp. We should make sure, that both can be install in paralell. 
But this should be possible, because we have different namespaces.

Regareds,

sandro

PS: debian-qt-kde - is mostly a list, that is spammed by the bugs
   pkg-kde-talk - is more the talk list about general topics like this one


signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Qt4's Webkit in Stretch

[Sandro Knauß]

Hey,

> And now that the facts are on the table I will give you my personal opinion:
> even if lots of important apps depend on it I would remove it at least from
> testing.
I can understand your option and also think this is okay, but I would like to 
get a exception for kdepim/kdepim-runtime.

Mails are very important for users, so removing it from testing would make it 
impossible for testing users to read their mails.

Additionally we have already a solution in experimental kdepim based kf5 + 
akonadi5. A first version is already uploaded to experimental and me is 
currently updating it to 15.12. Hopefully after that we can think about 
pushing it to unstable. But we have also have to handle the applications 
depend on kdepim, that also needs to be updated (zanshin, kopete,...).

Regards,

sandro

--

Am Friday 22 January 2016, 17:43:59 schrieb Lisandro Damián Nicanor Pérez 
Meyer:
> And now that the facts are on the table I will give you my personal opinion:
> even if lots of important apps depend on it I would remove it at least from
> testing.
> 
> Why? Well, I have been the only one uploading qt4's webkit since 02 Sep
> 2014, and suffering it's hardware build requirements and it's codebase. I
> really don't want to continue suffering it (I will already have too much
> with Qt5's one), so if keeping it is the selected option someone will have
> to step in for maintaining it.
> 
> So (keep) proponents, be aware that you might be offering to do the job
> yourself ;)


signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Qt 5.4 and QtWebEngine

[Sandro Knauß]

Hey,

kdepim in now on the track to release a Qt5 version in August. kdepim has a 
dependency on QtWebEngine. 

 Of course I won't stop anyone in trying to ship it. But if no one steps up
 to maintain it I will not hesitate in simply ignoring it as much as
 possible, even at the point of not shipping stuff that depends on it.

I'll stand up to ship it :)

Regards,

sandro

--
Am Freitag, 10. Oktober 2014, 00:19:51 schrieb Lisandro Damián Nicanor Pérez 
Meyer:
 As you might know, Digia plans to ship QtWebEngine as a kind of replacement
 for QtWebkit on 5.4.
 
 I have just had a chat with one of Fedora's maintainers and discussed some
 of the key points on QtWebEngine. Note that I only checked some of the
 following, feel free to pin point whatever you fell/like.
 
 - It uses V8 (the same we got rid some months ago from qtdeclarative) which
 doesn't builds on all archs.
 
 - It bundles ffmpeg and it seems not easy to use an external (system) one.
 In case we still have it in the archive for Jessie+1.
 
 - Bundles even more stuff that webkit
 
 - It's not a drop-in replacement for QtWebkit
 
 - It will mean another copy of the code in the archive, apart from Chromium
 itself
 
 - QNetworkAccess support is gone (no KIO nor Qt's http code)
 
 So my *personal* plan for Jessie+1 is this: not loose a single second on
 QtWebEngine.
 
 Of course I won't stop anyone in trying to ship it. But if no one steps up
 to maintain it I will not hesitate in simply ignoring it as much as
 possible, even at the point of not shipping stuff that depends on it.
 
 Cheers, Lisandro.


signature.asc
Description: This is a digitally signed message part.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk