Re: tasksel's task-kde-desktop seems to be outdated

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 9 de abril de 2018 13:46:39 -03 Maximiliano Curia escribió:
> Hi,
[snip]
> Other packages:
>  - kdeaccessibility depends upon jovie (KDE4 based), kaccessible (KDE4
> based), kmouth (KDE4 based), I'm not even sure if these are usable right
> now. :/ 

I think some of these will become KF5 with Qt 5.10, as QtSpeech is needed. 
Actually I think Pino did kmouth recently.

Tosky might also have some insight in this.

>  - should we recommend/suggest krita?

This was was missaligned for me and I almost oversee it. I would add it for 
sure in kde-full, don't know if in standard.


Cheers!

-- 
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself.  Therefore all
progress depends on the unreasonable man.
  George Bernard Shaw

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Bug#893523: transition: qtbase-opensource-src

[Lisandro Damián Nicanor Pérez Meyer]

If I remember correctly the buildds check for installability of build 
dependencies before trying to build a package. If that's ture then, due to the 
way Qt packages are tied together, all the rdeps can be binNMUed right now.

Yes, there is no need to hurry, but I thought it would be good to notice it.


-- 
Confucius say: He who play in root, eventually kill tree.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Bug#893523: transition: qtbase-opensource-src

[Lisandro Damián Nicanor Pérez Meyer]

On 6 April 2018 at 14:08, Lisandro Damián Nicanor Pérez Meyer
<perezme...@gmail.com> wrote:
> I'm afraid that I won't be able to start the transition until monday.

Time cleared up during weekend, so I have time for this in my hands. I
think I'm still free to go, but just in case pinging here and on IRC
before proceeding.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

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

Re: Bug#893523: transition: qtbase-opensource-src

[Lisandro Damián Nicanor Pérez Meyer]

I'm afraid that I won't be able to start the transition until monday.
I *think* Dmitry is more or less in the same position. If that means
giving the go to another transition and deACK this one please go
ahead.

Sorry for the inconvenience.

P.S.: sorry for the double posts, I forgot to CC the bug.

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

Re: Bug#893523: transition: qtbase-opensource-src

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 27 de marzo de 2018 19:09:52 -03 Emilio Pozuelo Monfort escribió:
> On 19/03/18 20:22, Lisandro Damián Nicanor Pérez Meyer wrote:
> > In order to know what we are facing:
> > 
> > - #893535 deepin-qt5dxcb-plugin: FTBFS with Qt 5.10.1 in experimental
> > - #876934 openorienteering-mapper FTBFS: test failures ← not really
> > our bug, compiles with qt 5.10.1 but tests keep failing
> > - #893540 telegram-desktop maybe a bug in my chroot?

I've rebuilt the rdeps successfully. The above bugs seems to have been solved, 
so from our side we are ready to go.

I understand that the akonadi transition is currently going on, so we will 
need to wait for it to complete.

Cheers, Lisandro.


-- 
Gabardinas "Windows 95". Se cuelgan solas.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

On qt5ct

[Lisandro Damián Nicanor Pérez Meyer]

Scarlett: I have been reviewing qt5ct and came to some conclusions,
most of it already poured on IRC:

- /etc/X11/Xsession.d/99qt5ct sets the rights variables at the right
time. Basically it sets QT_QPA_PLATFORMTHEME=qt5ct except it was
already defined or if KDE is being used.

- The app /usr/bin/qt5ct serves the purpose of configuring qt5ct,
storing whatever setting in ~/.config/qt5ct/. But it has a behavior
which I consider a bug: it does not opens if
QT_QPA_PLATFORMTHEME=qt5ct is not set (actually it complains and
exits). This should work non the less but warn the user about this.

- /usr/share/doc/qt5ct/README.Debian is misleading due to the above
bug. It should more or less describe the above behavior and ask users
to set the variable by hand in case they are trying to run qt5ct from
within KDE.

So basically we need to avoid shipping AUTHORS and fix the reported bugs.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

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

Re: 20180210 IRC meeting wrap-up

[Lisandro Damián Nicanor Pérez Meyer]

Hi Steve!

El miércoles, 14 de marzo de 2018 01:33:47 -03 Steve Robbins escribió:
[snip] 
> I have two more projects to place under kde-extras.
> 
> I have a git repo (libmedialwiki) to migrate.  It is presently on alioth
> under kde-extras so I would move it to the same on salsa.  I guess I need
> to be a member of qt-kde-team first?  (just requested access)

Repo created, you have master permissions on it. I've imported it from alioth 
so everything should be there already.

> Also: I am converting digikam from SVN -- also on alioth under kde-extras.

At this step we want to be cautious because we want the SVN history to be kept 
as much as possible. Which tools did you use to convert the SVN repo to git?

Without implying you did something wrong, I think Dmitry did very successful 
conversions from SVN to git.

It would be real cool if we could check the import before pushing to the git 
repo.

-- 
Antiguo proverbio del Viejo Machi: "Prefiero que mi cerebro esté en la
cresta de la ola, y mi PC un paso atrás sirviéndolo y no tener mi PC en
el 'estado del arte' y mi cerebro un paso atrás asistiéndola."
  http://www.grulic.org.ar/lurker/message/20090507.020516.ffda0441.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Fwd: libepoxy 1.5 breaks KWin on NVIDIA

[Lisandro Damián Nicanor Pérez Meyer]

Hi Jérémy! I am forwarding you a mail from Kwin's main developer. It
seems that libepoxy 1.5 makes the nvidia driver crash. This would make
all KDE unusuable in setups using Nvidia video cards.
Ideally we should try to avoid libepoxy 1.5 until this gets fixed.

Thanks for your work!


-- Forwarded message --
From: Martin Flöser <mgraess...@kde.org>
Date: 8 March 2018 at 17:21
Subject: libepoxy 1.5 breaks KWin on NVIDIA
To: distributi...@kde.org


Hi distros,

this is just a short information that the latest libepoxy release
(1.5) causes KWin to crash on NVIDIA driver. See [1] for more
information.

I suggest to not update this package until the issue is resolved. For
distributions who already rolled out the update (I am aware of at
least Arch) I suggest to consider going back to the previous version.
If the KDE team in your distribution is not responsible for libepoxy I
kindly ask to forward this mail to the relevant developers.

I cannot tell you yet whether the problem is in libepoxy, KWin or NVIDIA driver.

Cheers
Martin

[1] https://github.com/anholt/libepoxy/issues/160


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

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

Re: latte-dock review

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 6 de marzo de 2018 10:38:06 -03 Lisandro Damián Nicanor Pérez Meyer 
escribió:
[snip]
> I have not checked copyright, will do with the next upload.

And this is what I'm currently doing now. The file is just fine, all 
copyrights seems to be OK.

You can improve this file for the next upload. According to https://
www.debian.org/doc/packaging-manuals/copyright-format/1.0/ you can group files 
and copyright holders with the same license.

For example the stanzas:

Files: *
Copyright: 2014, David Edmundson <davidedmudn...@kde.org>
  2016, 2017, Smith AR <audo...@openmailbox.org>
  Michail Vourlakos <mvourla...@gmail.com>
License: GPL-2+

Files: app/*
Copyright: 2016, 2017, Smith AR <audo...@openmailbox.org>
License: GPL-2+

Files: app/Messages.sh
  app/visibilitymanager_p.h
Copyright: 2014, David Edmundson <davidedmudn...@kde.org>
License: GPL-2+

Can become:

Files: *
Copyright: 2014 David Edmundson <davidedmudn...@kde.org>
2016-2017 Smith AR <audo...@openmailbox.org>
Michail Vourlakos <mvourla...@gmail.com>
Smith AR <audo...@openmailbox.org>
License: GPL-2+

There is an extra gotcha here: I removed some commas in the years definitions. 
Check the copyright format url above and see why I did this.

That + the fact that the package was uploaded unreleased makes me ask you to 
fix that and upload the package already released to unstable. I'll happily 
upload it after that.

= Repo

Do you have a repo for latte-dock packaging that I can clone to add it to 
salsa? Or should I just create a new one?

-- 
"So long, and thanks for all the fish!"
  The Hitchhickers guide to the Galaxy

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: RFS: verdigris/1.0-1

[Lisandro Damián Nicanor Pérez Meyer]

On 7 March 2018 at 21:52, Olzhas Rakhimov <ol.rakhi...@gmail.com> wrote:
[snip]
>> Also add 2013-2018 Woboq GmbH to the root license, it's Olivier's company.
>
> Done. Reuploaded.

And uploaded!

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

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

Re: RFS: verdigris/1.0-1

[Lisandro Damián Nicanor Pérez Meyer]

Hi Olzhas! Are you subscribded to pkg-kde-talk? In the meantime I'll keep you 
CCed.

El viernes, 2 de marzo de 2018 03:10:36 -03 Olzhas Rakhimov escribió:
> On Tue, Feb 27, 2018 at 01:49:18PM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > El domingo, 25 de febrero de 2018 20:32:30 -03 Olzhas Rakhimov escribió:
> > > I've added the missing copyright info for tests and benchmarks.
> > 
> > Yes, but it does not applies
> > https://mentors.debian.net/debian/pool/main/v/
> > verdigris/verdigris_1.0-1.dsc as stated. For example the test/qt/* stanzas
> > should have been:
> > 
> > Files: tests/qt/*
> > Copyright: 2016 The Qt Company Ltd.
> > 
> >  2014-2015 Olivier Goffart 
> > 
> > License: GPL-3+
> > 
> > Check the format specification above.
> > 
> > Also not all tests are GPL-3+ licensed. Check again.
> 
> I am a bit confused with the Qt copyright statement in the files.
> My initial assumption of GPLv3+ was wrong.
> It is a mix of commercial license statement
> and GPLv3 (only) w/ some exceptions.
> I just looked around other Qt/KDE packages
> and found GPLv3 w/ Qt-1.0 exceptions licence info,
> so hope it is the correct one to put into the copyright file.

No, it is not :-) Yes, licensing is problematic.

In this case is GPL-3 alone. The commercial license does not applies to the 
Debian case. So please adjust this and re upload.

Also add 2013-2018 Woboq GmbH to the root license, it's Olivier's company.

> As for some files that are missing license boilerplate,
> I assume it is authored
> by Olivier Goffart under the root (package) license.

This is right.

Just fix the above, re upload and I'll sponsor it.

> I re-uploaded with debhelper 11 (having fun w/ Ubuntu 18.04 :-).

I really hope you are not using Ubuntu for building Debian packages...


-- 
LINUX KERNEL LIBERADO
DOS SECUESTRADORES MICROSOFTIANOS CAPTURADOS
OTRO SIGUE PROFUGO
*musiquita de cronica TV*

Ok, ok, ya me voy a hacer algo util, no me peguen :D

  Matias "Angasule" D'Ambrosio,
  sobre la liberación del kernel 2.6.23
  http://linux.org.ar/pipermail/bblug/2007-October/005405.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

latte-dock review

[Lisandro Damián Nicanor Pérez Meyer]

Scarlett: here is a a review of the package.

First as I wrote on IRC:

 sgclark: I have just forwarded you a mail from ScottK when he 
reviewed qt5ct
 qt5ct depends on environment variables, so we should really do what 
policy says there
 sgclark: regarding latte-dock: if you check http://
mentors.debian.net/package/latte-dock you will see lintian warnings
 out of them out-of-date-standards-version and debian-watch-uses-
insecure-uri can surely be fixed

= debian/changelog

The package has never been part of Debian so there must be only one changelog 
entry. With that I also mean that we do not want Neon entries there.

= debian/compat

We might want to use 11 now, which is the current version.

= debian/control

- As debian/compat is 10 you must depend on debhelper >= 10
- Vcs-[Browser Git] should point to salsa.debian.org

I have not checked copyright, will do with the next upload.

-- 
Ponga su mano en una estufa caliente por un minuto, y le parecerá como una
hora. Siéntese con una muchacha bonita por una hora, y le parecerá un minuto.
¡Eso es relatividad!.
 Albert Einstein (1879-1955)

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Static webpages in salsa

[Lisandro Damián Nicanor Pérez Meyer]

El viernes, 23 de febrero de 2018 21:21:35 -03 Lisandro Damián Nicanor Pérez 
Meyer escribió:
[snip] 
> So before going ahead, does someone has any issues wrt this? Any better
> ideas?

No one?


-- 
No subestimes el ancho de banda de un camión
cargado de cintas.
  Andrew S. Tanenbaum

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: RFS: verdigris/1.0-1

[Lisandro Damián Nicanor Pérez Meyer]

El domingo, 25 de febrero de 2018 20:32:30 -03 Olzhas Rakhimov escribió:
> On Sun, Feb 25, 2018 at 10:50:52AM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > I'll take a look, but please start by fixing the lintian warnings present
> > in mentors.d.n.
> 
> Thanks, Lisandro.

My pleasure.
 
> I've added the missing copyright info for tests and benchmarks.

Yes, but it does not applies https://mentors.debian.net/debian/pool/main/v/
verdigris/verdigris_1.0-1.dsc as stated. For example the test/qt/* stanzas 
should have been:

Files: tests/qt/*
Copyright: 2016 The Qt Company Ltd.
 2014-2015 Olivier Goffart 
License: GPL-3+

Check the format specification above.

Also not all tests are GPL-3+ licensed. Check again.

> As for the lintian warnings,
> I could only fix the missing upstream changelog.
> Currently cannot update debhelper compat to 11
> because I don't have it on my system.

If you are building a package for unstable you need to work in unstable. You 
can of course do this in a chroot or in a virtual machine or alike.

I think that would be all.

-- 
You know it's love when you memorize her IP number to skip DNS overhead.
  Anonymous

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: RFS: verdigris/1.0-1

[Lisandro Damián Nicanor Pérez Meyer]

El sábado, 17 de febrero de 2018 00:52:48 -03 Olzhas Rakhimov escribió:
> Hello,
> 
> I am looking for review and sponsorship
> of initial 'verdigris' upload.
> This is the first time me following your team's guidelines,
> so take it easy :)
> 
> repo: https://salsa.debian.org/qt-kde-team/qt-extras/verdigris
> mentors: https://mentors.debian.net/package/verdigris

I'll take a look, but please start by fixing the lintian warnings present in 
mentors.d.n.

Chheers, Lisandro.


-- 
UNIX is basically a simple operating system, but you have to be a
genius to understand the simplicity.
  Dennis Ritchie

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Action requested: migration of alioth list pkg-kde-extras

[Lisandro Damián Nicanor Pérez Meyer]

El sábado, 24 de febrero de 2018 06:46:12 -03 Dominic Hargreaves escribió:
> On Tue, Feb 13, 2018 at 12:56:11PM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > I'm hereby asking for pkg-kde-extras@l.a.d.o to be migrated.
> > 
> > As the current admin is not available and I don't seem able to add mmyself
> > as an admin from the alioth web interface I'm CCing this mail to pkg-kde-
> > ext...@lists.alioth.debian.org to ensure transparency.
> 
> The list has now been marked to be migrated, and the new owner recorded
> in the absence of any objections.

**Thanks**


-- 
El futuro es WIN95 A no ser que hagamos algo a tiempo.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Static webpages in salsa

[Lisandro Damián Nicanor Pérez Meyer]

In our IRC meeting we decided to keep our www repo as-is for now, and whenever 
someone has time for creating something new we would change to some static 
page generator.

I've already imported www.git to salsa, s.d.o/qt-kde-team/www

From what I understood from https://wiki.debian.org/Salsa/Doc#Quick_start we 
currently *only* can push already-processed webpages:

   Note: Even though we plan to support simple page generators like Jekyll or
   Hugo in the future, in most cases, you should content yourself with the
   HTML template, and generate the pages locally to push them afterward, in
   order to save the resources on the runner. Some templates might require
   commands not available on the server anyway. 

The HTML template reads:

  # This file is a template...
  # Full project: https://gitlab.com/pages/plain-html
  pages:
stage: deploy
script:
- mkdir .public
- cp -r * .public
- mv .public public
artifacts:
  paths:
  - public
only:
- master

So if I understand correctly we could go ahead with what we currenlty have by 
running genweb.sh and committing *also* the generated pages in the output 
directory to git, then just modifying the cp line above to get the contents 
from output.

So before going ahead, does someone has any issues wrt this? Any better ideas?

Cheers!

-- 
Lo que me sorprende de las mujeres es que se arrancan los pelos desde
la raíz con cera caliente y aún así le temen a las arañas.
  Jerry Seinfeld

lis: comentario sobre tu frase
yo soy mujer, yo me arranco los pelos y VOS le tenes miedo a las arañas
  María Luján Pérez Meyer (mi hermana)

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Request for importing repositories to Salsa group

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 20 de febrero de 2018 12:19:55 -03 Boris Pek escribió:
> >>> Could anyone with enough access permissions import git repo [1] to
> >>> subgroup
> >>> KDE extras [2] and git repo [3] to subgroup Qt extras [4] and give me
> >>> Master level of access to these new repos?
> >>> 
> >>> [1] https://anonscm.debian.org/git/pkg-kde/kde-extras/qtcurve.git
> >>> [2] https://salsa.debian.org/qt-kde-team/kde-extras
> >>> [3] https://github.com/tehnick/qconf-debian.git
> >>> [4] https://salsa.debian.org/qt-kde-team/qt-extras
> > 
> > qtcurve should be ready. With respect to qconf-debian ¿should it be called
> > just qconf or qconf-debian is better?
> 
> "qconf" please.
> 
> (Other part of URL is enough to inform that this is a debian packaging
> rules.)
> 
> Thanks!

Done, and my pleasure.


-- 
Geek Inside!

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Request for importing repositories to Salsa group

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 20 de febrero de 2018 12:01:32 -03 Lisandro Damián Nicanor Pérez 
Meyer escribió:
> El martes, 20 de febrero de 2018 10:30:57 -03 Lisandro Damián Nicanor Pérez
> 
> Meyer escribió:
> > El 20 feb. 2018 8:11 a.m., "Boris Pek" <tehn...@debian.org> escribió:
> > 
> > Hi team,
> > 
> > Could anyone with enough access permissions import git repo [1] to
> > subgroup
> > KDE extras [2] and git repo [3] to subgroup Qt extras [4] and give me
> > Master level of access to these new repos?
> > 
> > [1] https://anonscm.debian.org/git/pkg-kde/kde-extras/qtcurve.git
> > [2] https://salsa.debian.org/qt-kde-team/kde-extras
> > [3] https://github.com/tehnick/qconf-debian.git
> > [4] https://salsa.debian.org/qt-kde-team/qt-extras

qtcurve should be ready. With respect to qconf-debian ¿should it be called 
just qconf or qconf-debian is better?


-- 
127.0.0.1 sweet 127.0.0.1

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Access level for members of Debian Qt and KDE Team group at Salsa

[Lisandro Damián Nicanor Pérez Meyer]

El viernes, 16 de febrero de 2018 05:45:33 -03 Boris Pek escribió:
> Hi,
> 
> >>  Ok. In this case I may suggest you to use workflow similar to one in
> >>  Debian
> >>  Perl Group [1]. They do not add extra members to the main group [2], but
> >>  allow members joining to specific sub-groups (for example, [3]). Though
> >>  it is only in plans; they have not done the migration from Alioth and it
> >>  is not even documented yet.
> > 
> > Well, as far as we do understand if someone wants to provide a branch for
> > reviewing then [s]he should be at least Developer, which means commit
> > access. Not ideal, but a trade off. Of course, feel really free to
> > correct me if I'm wrong.
> 
> This is only for a case when member should have push access to the main git
> repo. But now this is not necessary if we use GitLab feature Merge Requests.

[snip excelent explanation, thanks for it!]

Right, we where expecting to be able to do that but did not know for sure.

Well, we need to revisit how we should handle ACLs then. I understand that 
depending on how a package in extras is maintained the ACL should vary too.

> If you have another workflow in mind, please share your thoughts in more
> details.

Not for now.
 
[snip]
> >> 3) As for packages for KDE-extras and Qt-extras: apart from
> >> described not "core" projects there are a number of projects which are
> >> developed outside of KDE (or Qt) infrastructure [8], but closely related
> >> with KDE (or Qt). And they also could (or should) be maintained in Qt/KDE
> >> Extras Team.
> > 
> > Mostly "could". As long as it does not interferes with the main reasons of
> > being (qt and KDE stuff), it's could.
> 
> Some of them really "should". Few examples from my personal experience:
> 
> 1) Package xembed-sni-proxy [1]. Project initially have been developed on
>GitHub [2], but later it was moved in KDE and has become the part of
>plasma-workspace.
> 
> 2) Package qtcurve [3]. Project initially have been developed without VCS,
> then its development was moved to GitHub [4] and now it is a part of KDE
> [5].

Right, problem is when you are in the github stage and don't even think of a 
project becoming part of KDE.

But yes, it's not perfect.

-- 
¿Qué vamos a hacer esta noche Cerebro?
-Lo mismo que todas las noches Pinky...
¡¡¡tratar de conquistar el mundo!!!
  Pinky y Cerebro. Narf.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Removing qt4's webkit: missing stuff

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 15 de febrero de 2018 16:19:52 -03 Andrey Rahmatullin escribió:
> On Thu, Feb 15, 2018 at 04:02:01PM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > - Is anyone willing to take kchmviewer?
> 
> Yes, I still intend to update it.

Great! I must admit it's in my ToDo list too, but I have been unable to tackle 
it so far.

-- 
She got her good looks from her father. He's a plastic surgeon.
 -- Groucho Marx

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Removing qt4's webkit: missing stuff

[Lisandro Damián Nicanor Pérez Meyer]

Hi! I'm trying to coordinate the remaining steps in order to get us rid of 
qt4's webkit. The idea is to share what I currently know of the situation and 
see if we can go forward.

Today Adrian Bunk wrote:

   preconditions for qtwebkit removal from testing are kmix 17.12 and an
  upload of the #784477 patch, followed by fixing #784479

<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784477> aka "remove the 
webkit and plasma parts from kde-runtime"

<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784479> remove kdewebkit 
from kdelibs.

Once those are done we can go ahead asking for the removal of the remaining 
packages listed in [wiki]

[wiki] <https://wiki.debian.org/Qt4WebKitRemoval>

From that list kmix might be the more relevant one, although there is plasma-
pa-around (not exactly the same, I know).

We also have amarok (we should really remove it now) and maybe kchmviewer. 
This last one needs packaging time.

So:

- Is anyone willing to take kmix?
- Is anyone willing to take kchmviewer?
- Is there anything I am missing?

Cheers, Lisandro.

-- 
La mejor prueba de que la navegación en el tiempo no es posible, es el hecho
de no haber sido invadidos por masas de turistas provenientes del futuro.
  Stephen Hawking

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Verdigris - header only Qt moc replacement

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 13 de febrero de 2018 21:25:59 -03 Olzhas Rakhimov escribió:
> Hello All,
> 
> I was wondering if Verdigris would be suitable for this team.
> Here's RFP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886514
> 
> It has just reached 1.0,
> and I am thinking about Debian packaging.
> Your team and sponsorship would be very helpful.

What would we gain from using it?


-- 
Wiki participants are, by nature, a pedantic, ornery, and unreasonable bunch.
So there's a camaraderie here we seldom see outside of our professional
contacts.
  http://www.c2.com/cgi/wiki?WhyWikiWorks

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Access level for members of Debian Qt and KDE Team group at Salsa

[Lisandro Damián Nicanor Pérez Meyer]

pose.

Right, Luigi Toscano has been telling me this recently. Again we need to 
settle this down yet. We might need another IRC meeting.

> [6] https://anonscm.debian.org/git/pkg-kde/kde-extras/
> [7] https://salsa.debian.org/qt-kde-team/kde-extras
> [8] Yes, quite often such projects sooner or later are moved to KDE, and
> sometime even become a part of "core" projects.  But this is completely
> another question...
> 
> >> As a side note: could you add small description for the main Debian Qt
> >> and KDE Team group at Salsa? (There are descriptions only for subgroups
> >> for now.) At least a hyperlink [3] would be useful. (Until it will be
> >> moved to Salsa pages.)
> > 
> > We noted this today. I wrote down some ideas in gobby/Teams/KDE/salsa, but
> > we might need to reconsider the use of kde-extras or at least define
> > exactly what each subgroup is for.
> > 
> > Yes, we missed that point yesterday I'm afraid.
> > 
> > Thanks for chiming in!
> 
> Thanks for fixing this.
> 
> And few more side notes/questions:
> 
> Last night I have updated Debian Science Policy Manual [9] to reflect the
> changes after moving git repositories from Alioth to Salsa. It might be
> interesting to you.

Thanks. To say the truth I have read the science's policies some years ago and 
I really did not like them. I don't know the current content, but I do like 
the work in the way it's being showed.

> The question is: do we have a similar policy manuals for Debian Qt/KDE
> Maintainers and Debian KDE Extras teams? I failed to find them. Could you
> give me a link?

Sure, not the best but:

<http://pkg-kde.alioth.debian.org/changelogstandard.html>
<http://pkg-kde.alioth.debian.org/qmlmodulesnaming.html>
<http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html>
<http://pkg-kde.alioth.debian.org/descriptions.html>
<http://pkg-kde.alioth.debian.org/gitguidelines.html>

And more pages there.

-- 
Los comentarios o respuestas sobre SL en tono absolutista solo hacen aparecer
a la comunidad SL como una sarta de fanáticos que viven dentro de un
tupperware.
 Pablo Di Noto - GrULiC

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Action requested: migration of alioth list pkg-kde-extras

[Lisandro Damián Nicanor Pérez Meyer]

I'm hereby asking for pkg-kde-extras@l.a.d.o to be migrated.

As the current admin is not available and I don't seem able to add mmyself as 
an admin from the alioth web interface I'm CCing this mail to pkg-kde-
ext...@lists.alioth.debian.org to ensure transparency.

Thanks in advance, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Access level for members of Debian Qt and KDE Team group at Salsa

[Lisandro Damián Nicanor Pérez Meyer]

Hi Boris!

El domingo, 11 de febrero de 2018 13:08:17 -03 Boris Pek escribió:
> Hi,
> 
> I think that package maintainers should have a Master level of access
> to be able to create or to import git repos in the group [1].
> Al least DDs. See Debian Science Team group [2] at Salsa as example.

Yesterday we decided that, at least for now, only admins will be able to 
create repositories. We will grant Master access to the whole group to people 
who require it and we admins do trust him/her. Again this is for the time 
being, we can always review this decitions later.

I think it is possible to give Master access to specific repos, that should be 
the case for people maintaining specific packages in *-extras.

I did not yet got to publish our results from yesterday, so info might be 
missing. I hope to do it soon.

> As a side note: could you add small description for the main Debian Qt
> and KDE Team group at Salsa? (There are descriptions only for subgroups
> for now.) At least a hyperlink [3] would be useful. (Until it will be
> moved to Salsa pages.)

We noted this today. I wrote down some ideas in gobby/Teams/KDE/salsa, but we 
might need to reconsider the use of kde-extras or at least define exactly what 
each subgroup is for.

Yes, we missed that point yesterday I'm afraid.

Thanks for chiming in!

-- 
4: Que es un icono
* Un caballono
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Action requested: migration of alioth list pkg-kde-commits

[Lisandro Damián Nicanor Pérez Meyer]

On 28 January 2018 at 15:26, alioth lists migration team
 wrote:
> Dear list owner,
>
> As per the announcement on debian-devel-announce[1] the migration of
> lists.alioth.debian.org mailing lists is now underway. If you would
> like pkg-kde-comm...@lists.alioth.debian.org
> to be included in this process, to ensure that the list still works
> after the migration in late March/April, please let us know by replying
> to this email. Otherwise, the list will stop working at migration time
> and the archives will no longer be accessible.
>
> Feel free to also let us know if the list is no longer needed, so we can
> note that down too. Replies must be received by 15th March 2018.

As a  follow-up from my mail from yesterday:

We would like to keep: pkg-kde-extras and pkg-kde-talk

We would like to not keep: pkg-kde-commits and pkg-kde-trunk

Thanks in advance!

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

Re: Action requested: migration of alioth list pkg-kde-talk

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El domingo, 28 de enero de 2018 15:26:20 -03 alioth lists migration team 
escribió:
> Dear list owner,
> 
> As per the announcement on debian-devel-announce[1] the migration of
> lists.alioth.debian.org mailing lists is now underway. If you would
> like pkg-kde-talk@lists.alioth.debian.org
> to be included in this process, to ensure that the list still works
> after the migration in late March/April, please let us know by replying
> to this email. Otherwise, the list will stop working at migration time
> and the archives will no longer be accessible.

Letting you know that we want this mailing list included in the migration.

We also would like to migrate Debian KDE Extras Team . I'm currently not an admin for that one, but 
I can become one if you need to.

Thanks in advance!

-- 
On the side of the software box, in the "System Requirements" section,
it said "Requires Windows 95 or better". So I installed Linux.
  Anonymous.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Moving to salsa: IRC meeting coordination?

[Lisandro Damián Nicanor Pérez Meyer]

On 8 February 2018 at 18:15, Boris Pek <tehn...@debian.org> wrote:
>> We had no replies, so let's keep saturday 13 UTC except someone chimes in.
>
> Do you have a list of questions to discuss?


<https://gobby.debian.org/export/Teams/KDE/salsa>

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

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

Re: Moving to salsa: IRC meeting coordination?

[Lisandro Damián Nicanor Pérez Meyer]

El miércoles, 7 de febrero de 2018 14:35:25 -03 Dmitry Shachnev escribió:
> On Tue, Feb 06, 2018 at 07:22:24PM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > On Thursday I'm free starting from 20 utc
> 
> 20 or 21 UTC should be fine for me.
> 
> What do the others think?
> 
> --
> Dmitry Shachnev

We had no replies, so let's keep saturday 13 UTC except someone chimes in.


-- 
Dadme voto electrónico y con una terminal os haré presidente.
  el.machi

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Moving to salsa: IRC meeting coordination?

[Lisandro Damián Nicanor Pérez Meyer]

El 6 feb. 2018 7:18 p.m., "Dmitry Shachnev" <mity...@debian.org> escribió:

Hi all,

On Tue, Feb 06, 2018 at 03:14:37PM -0300, Lisandro Damián Nicanor Pérez
Meyer wrote:
> 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.

A few hours earlier (13 or at least 14 UTC) would be more convenient to me.

On Tue, Feb 06, 2018 at 07:50:54PM +0100, Sandro Knauß wrote:
> from Friday on I'll be in vacation for one week. But no need to
reschedule the
> event because of me.

Or maybe on a workday, like Thursday?


On Thursday I'm free starting from 20 utc
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Moving to salsa: IRC meeting coordination?

[Lisandro Damián Nicanor Pérez Meyer]

El viernes, 2 de febrero de 2018 21:23:52 -03 Lisandro Damián Nicanor Pérez 
Meyer escribió:
> El 2 feb. 2018 7:17 p.m., "Pino Toscano" <p...@debian.org> escribió:
> 
> In data venerdì 2 febbraio 2018 18:24:19 CET, Lisandro Damián Nicanor Pérez
> 
> Meyer ha scritto:
> > Hi everyone! I think it would be a good idea to coordinate an IRC meeting
> 
> in
> 
> > order to prepare our move to salsa.
> > 
> > At least from my side this weekend and the following would be ideal (+/-
> 
> some
> 
> > commitments I have already arranged), but if necessary I can coordinate
> 
> during
> 
> > the following weekdays (nut not after the 13th).
> 
> Since I'd like to take part, and currently I'm at FOSDEM, my preference
> would be not earlier than the next Tuesday (6th).
> 
> 
> Fair enough, I did not take FOSDEM in account when proposing the dates,
> I've realized it later (I should go to FOSDEM someday).
> 
> 
> It wouldn't be strange if other team members are there too, so let's try to
> find a date starting from next Tuesday.

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.


-- 
Cuando alguna persona va al ataque contra Wikipedia argumentando
que no es confiable "porque encontró ya varios errores", hago la
siguiente pregunta: "¿Corregiste esos errores cuando los
encontraste?" Invariablemente, la respuesta es "no".
  Ariel Torres, "Probablemente, la Wikipedia esté bien"
  La Nación Tecnología, Sábado 25 de agosto de 2007
  http://www.lanacion.com.ar/tecnologia/nota.asp?nota_id=937889

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Moving to salsa: IRC meeting coordination?

[Lisandro Damián Nicanor Pérez Meyer]

Hi everyone! I think it would be a good idea to coordinate an IRC meeting in 
order to prepare our move to salsa.

At least from my side this weekend and the following would be ideal (+/- some 
commitments I have already arranged), but if necessary I can coordinate during 
the following weekdays (nut not after the 13th).

What do you think?


-- 
Vió, buteó y andó

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Further processing kdepim bugs

[Lisandro Damián Nicanor Pérez Meyer]

On 19 January 2018 at 07:32, Sandro Knauß <he...@debian.org> wrote:
> 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.

Then it must be kept at least marked as valid on those releases as log
as they are part of the archive.

> If they are still valid bugs for stable or newer we don't know, if we
> do not check them bug by bug.

If they are closed upstream then close them with the following
upstream release version.

Example: if the bug has been present in (let's say) 3.4.5 and closed
by upstream because 4.0.0 is a new source base then close it with
version 4.0.0. Then The bug will still be valid for that version.

If the bug is still there then it can be either reopened or a new bug filed.

> 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?

It is important to our users. If you are using a very old version
still present in the archive then you want the bug to be opened as
long as that version exists.

And no, do not reopen them unless someone complains, and in that case
do it in a per-bug basis.

> 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?

Exactly as I said above: close them with version 15.08. The BTS will
handle that perfectly.


> 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?

I think the above is enough.

Of course feel free to ask for more info if needed, and sorry for
replying too late, I'm quite complicated with accesing a machine
nowadays.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

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

Re: Mailing List Continuation

[Lisandro Damián Nicanor Pérez Meyer]

On 21 January 2018 at 14:19, Boris Pek <tehn...@debian.org> wrote:
> Hi team,
>
> Some news about the future of mailing lists on Alioth:
> https://wiki.debian.org/Alioth/MailingListContinuation#Announcement

Which lists do we really need?

The commits lists should probably go away.

For starters I would say this one (pkg-kde-talk), the others are
@lists.debian.org which should just stay. I don't know what to do with
pkg-kde-extras.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

-- 
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")

[Lisandro Damián Nicanor Pérez Meyer]

(now replying to the mailing list)

El 18 ene. 2018 2:22 p.m., "Sandro Knauß"  escribió:

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


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.
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Adding salsa to our food^w workflow

[Lisandro Damián Nicanor Pérez Meyer]

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.

-- 
10: El procesador de textos es:
* Un programa que le da vida a una computadora haciendo que
intente dominar el mundo (ver pregunta 1)
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 26 de diciembre de 2017 07:00:05 -03 Dmitry Shachnev escribió:
> Hi Lisandro,
[snip] 
> I don’t think there is any migration from Alioth, so we will need to add
> members to the team manually.

http://www.df7cb.de/blog/2017/Salsa_batch_import.html

This can be adapted for us.

-- 
She got her good looks from her father. He's a plastic surgeon.
 -- Groucho Marx

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 26 de diciembre de 2017 10:17:06 -03 Lisandro Damián Nicanor Pérez 
Meyer escribió:
> El martes, 26 de diciembre de 2017 07:00:05 -03 Dmitry Shachnev escribió:
> > Hi Lisandro,
> > 
> > On Mon, Dec 25, 2017 at 09:55:46PM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > > salsa.d.o (alioth's replacement for git at least) is up in beta state.
> > > 
> > > I think we should ask for the pkg-kde team group. I think ACLs will be
> > > back
> > > with this.
> > > 
> > > What do you think?
> > 
> > s/ask for/create ourselves/, otherwise +1.
> 
> That depends on the name. If we are ok with a -team suffix then we can do it
> ourselves, else we need to ask for a special name (pkg-kde).
> 
> If we go with the renaming I would suggest using qtkde-team.

Err, I meant pkg-qtkde-team.

-- 
Wiki is not WysiWyg. It's an intelligence test of sorts to be able to edit a
wiki page. It's not rocket science, but it doesn't appeal to the VideoAddicts.
If it doesn't appeal, they don't participate, which leaves those of us who
read and write to get on with rational discourse.
  http://www.c2.com/cgi/wiki?WhyWikiWorks

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

[Lisandro Damián Nicanor Pérez Meyer]

I forgot to mention: my server is down and so my IRC bouncer. It will take me 
some time to put it back on, so please mail me if you want me to see something 
important.

If you see me on IRC is because I'm in from of my PC.

Cheers!

-- 
http://mx.grulic.org.ar/lurker/message/20081108.174208.4f42e55c.es.html
Así se corrobora el software legal en Argentina

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Removing amarok

[Lisandro Damián Nicanor Pérez Meyer]

On 11 September 2017 at 20:03, Diederik de Haas <didi.deb...@cknow.org> wrote:
> On Monday, September 11, 2017 10:35:54 AM CEST Lisandro Damián Nicanor Pérez
> Meyer wrote:
>> With a package in this state I would normally just go ahead and ask
>> the removal, but I know lots of people love amarok...
>
> There's a good chance that only developers watch this list. If you (also) want
> to reach 'normal' users, consider posting it to debian-kde as well

Just developers, at this point there is no use in asking users. A
different story would have been if all we needed is manpower.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

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

Removing amarok

[Lisandro Damián Nicanor Pérez Meyer]

Hi everybody! I'm considering asking for the RoM removal of amarok
from the archive. It has plenty of bugs, no active upstream (aka dead
upstream) and no finished port to Qt5.

With a package in this state I would normally just go ahead and ask
the removal, but I know lots of people love amarok...

My suggestion for them would be to get it from stable until they find
a suitable replacement. But the truth is that it currently does not
belongs in Buster and there is no signal of having a chance to avoid
it.

Does anyone has anything against this?

Kinds regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

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

Re: kde4libs and libssl-dev

[Lisandro Damián Nicanor Pérez Meyer]

(Replying from crappy web mail editor)

On 7 September 2017 at 13:25, Pino Toscano <p...@debian.org> wrote:
> Hi,
>
> (re-sending to the right ML)
>
> In data giovedì 7 settembre 2017 15:45:21 CEST, Maximiliano Curia ha scritto:
>> With the upload of qt4-x11 4:4.8.7+dfsg-12 (experimental) qt4 now builds 
>> against
>> libssl-dev, instead of libssl1.0-dev. Lisandro pinged me by irc to upload a
>> newer kde4libs built against libssl-dev (and the newer qt4 version) in order 
>> to
>> test this, but looking at the latests commits, it's clear that you have been
>> working in this package lately, and reading kdelibs4support thread you also 
>> are
>> more aware of the issues that openssl 1.1 could produce. So it might be 
>> better
>> if you could test this.
>>
>> Please let me know if you prefer that I take care of this.
>
> I'm afraid neither kdelibs (4.x) nor kdelibs4support (5.x) nor
> khtml (5.x) were ported to OpenSSL >= 1.1, so not sure how switching
> build dependency would work.

I forgot to explicitly ping Maxy about this. The patch we had for Qt4
probed not to be enough. At this point whenever OpenSSL 1.0 gets
removed the only way forward we have is to remove SSL support from
qt4-x11. And yes, mayhem, because some packages will FTBFS, some other
will complain at run time and some other will probably even not
complain at all.

I asked Q about the removal timeframe and he said "sometime during the
Buster release cycle".

It is worth to note that Qt4-x11 is not tracked in the RT's tracker,
possibly because it's being DLLopened.

Cheers!

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

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

Re: QtAV

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 28 de agosto de 2017 01:03:00 -03 Steve Robbins wrote:
> Hello folks,
> 
> I have finally found the time to create a first package of qtav.  If anyone
> has time for a review, it would be very much appreciated.  I have to
> confess that despite the length of time I've been using it, I'm still a
> newbie with git.

Just so that you get at least a reply: I really doubt I'll make time to review 
it I'm afraid :-(

> On Wednesday, January 18, 2017 9:37:43 AM CDT you wrote:
> > > > Is qtav as repo name OK for you?
> > 
> > The repo should appear under
> > https://anonscm.debian.org/cgit/pkg-kde/qt-extras in a few minutes.
> 
> I've pushed the master branch to Alioth.  I'm quite confused as to what
> branches are expected in the Alioth repository.   The page
> https://pkg-kde.alioth.debian.org/pkgkdegit.html describes the following
> commands
> 
>   git checkout --track origin/pristine-tar
>   git checkout --track origin/upstream
> 
> which suggests that upstream and pristine-tar branches are present.  But I
> checked a couple of repositories and did not find either.

Right, you can keep those locally, in our repos we tend to just have the 
debian stuff.

But this would be qt-extras, so I guess it's really up to you to decide.


-- 
 1: Una computadora sirve:
* Para tratar de dominar el mundo, un caso conocido de esto fue el de
  Skinet
Damian Nadales
    http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#872279: RM: plasma-widget-adjustableclock -- RoQA; RC buggy for more than a year, no fix

[Lisandro Damián Nicanor Pérez Meyer]

Package: ftp.debian.org
Severity: normal

Disclaimer: I'm not part of the QA team, but I don't know for sure if there is 
any
other way to do this.

plasma-widget-adjustableclock has been RC buggy for more than a year. It does 
not just
only FTBFS but even if it did it requires Plasma 4 which is not available 
anymore.

Moreover it will not have a Plasma 5 version: 
https://store.kde.org/content/show.php/Adjustable+Clock?content=92825

So ideally this package should be removed from the archive.

Kinds regards, Lisandro.

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

Re: Packaging PythonQt for Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On miércoles, 14 de junio de 2017 01:01:13 -03 Erik Lundin wrote:
> Hi,

Hi Erik!
 
> I'm now done with all changes I would like to see, so if someone would
> like to review them I'm grateful. Please see attached the diff against
> pythonqt 3.0-3. Since the Debian code for this package is hosted in SVN
> [1], I guess this is the easiest way.

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

> Here is a summary of the changes:
> 
>* New upstream version
>* Change to Qt5, since Qt4 has been deprecated upstream
>* Adapt building to pure qmake (CMake has been deprecated upstream)
>* Build packages for both Python 2 and Python 3
>* Place QtAll extension in separate package
>* Implement multiarch support
> 
> Since this is my first contribution to Debian, I'm also thankful for
> advices on best practices etc. if applicable.

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

-- 
7: Hay diferencia entre "cortar" un archivo y "borrarlo" o "eliminarlo"
* Depende cuando se "cuelgue" Windows
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

[Lisandro Damián Nicanor Pérez Meyer]

On sábado, 27 de mayo de 2017 22:35:50 -03 Erik Lundin wrote:
> Hi Lisandro,
> 
> Den 2017-05-27 kl. 22:26, skrev Lisandro Damián Nicanor Pérez Meyer:
> > On jueves, 25 de mayo de 2017 14:44:14 -03 Erik Lundin wrote:
> >> Den 2017-05-24 kl. 16:02, skrev Lisandro Damián Nicanor Pérez Meyer:
> >>> Yes, if those libs are tied to public headers package them as separate
> >>> binary packages. Your mental health at maintaining time will thank you
> >>> ;)
> >> 
> >> There is a header for PythonQt_QtAll (PythonQt_QtAll.h), so if I
> >> understand it correctly, you would recommend to place
> >> libPythonQt_QtAll.so.* in a separate package? In that case, should I
> >> also create a corresponding dev package for the header and the
> >> libPythonQt_QtAll.so symlink?
> > 
> > Yes and yes.
> 
> I made those changes today and agree it feels like a good solution.

It wll definitely help ypu at symbol-handling time.

-- 
Hacer algo siempre te llevará más tiempo del que esperabas, incluso si
tienes en cuenta la ley de Hofstadter.
  Douglas Hofstadter
  http://mundogeek.net/archivos/2009/09/05/la-ley-de-hofstadter/

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

[Lisandro Damián Nicanor Pérez Meyer]

On jueves, 25 de mayo de 2017 14:44:14 -03 Erik Lundin wrote:
> Den 2017-05-24 kl. 16:02, skrev Lisandro Damián Nicanor Pérez Meyer:
> > Yes, if those libs are tied to public headers package them as separate
> > binary packages. Your mental health at maintaining time will thank you ;)
> There is a header for PythonQt_QtAll (PythonQt_QtAll.h), so if I
> understand it correctly, you would recommend to place
> libPythonQt_QtAll.so.* in a separate package? In that case, should I
> also create a corresponding dev package for the header and the
> libPythonQt_QtAll.so symlink?

Yes and yes.


-- 
Hiroshima '45,
Chernobyl '86,
Windows   '95.
 Grafitti en Niceto Vega 5940, Buenos Aires. De una foto de Mario Gallo.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

[Lisandro Damián Nicanor Pérez Meyer]

On martes, 23 de mayo de 2017 10:13:13 -03 Erik Lundin wrote:
[snip] 
> *PythonQt_QtAll*
> Previous packages built using CMake were configured to wrap the
> extension PythonQt_QtAll and only create one set of library files.
> However, the possibility to do that seems to have disappeared, and now a
> new set of library files are created (libPythonQt_QtAll.so.3.1.0 with
> corresponding symlinks). The packaging guide, section 8.1, suggests that
> it is OK to put several libraries into the same package if their SONAMES
> will always change together, and I assume that this is the case here, so
> I'm prepared to do that. Any opinions on that?

Yes, if those libs are tied to public headers package them as separate binary 
packages. Your mental health at maintaining time will thank you ;)


-- 
Q. How did the programmer die in the shower?
A. He read the shampoo bottle instructions: Lather. Rinse. Repeat.
  http://www.devtopics.com/best-programming-jokes/

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

[Lisandro Damián Nicanor Pérez Meyer]

Dmitry, you know better than me on this :-/

On martes, 23 de mayo de 2017 10:13:13 -03 Erik Lundin wrote:
> Hello,
> 
> I sent this email to the debian-mentors list, and got directed to the
> Debian Qt/KDE team, so here follows the same content:
> 
> We're using PythonQt built for Qt 5 at work, and I have been looking at
> the possibility to package it for Debian. Here is what I have found so far:
> 
> * Qt 4 support for PythonQt seems to have been abandoned upstream. There
> is a branch with the last working version for Qt 4, and version 3.1
> (latest release) assumes Qt 5.
> * Support for CMake has been removed upstream.
> * The current Debian packages are Qt 4 only, and made for QMake.
> * pythonqt is orphaned in Debian
> * Debian tracker: https://tracker.debian.org/pkg/pythonqt
> 
> I have made necessary changes for building the package using QMake, and
> now would like to contribute them back to the community. However, I'm
> new when it comes to Debian packaging, so please help me with the following:
> 
> *Qt 4 vs Qt 5 versions of installed files*
> Compatibility between the packages for Qt 4 and Qt 5 has to be handled,
> i.e. the new package should not just install files with the same names
> as the previous packages. Since Qt 4 is abandoned upstream, I changed
> the packaging scripts to only build for Qt 5 and changed the names to
> "libpythonqt-qt5-3.1" and "libpythonqt-qt5-dev". However, the installed
> files still have the same names as the files of the previous packages
> (at least the dev package, which has files installed in
> /usr/include/PythonQt). Possible solutions to the dev package problem:
> 
> * Install header files to /usr/include/PythonQt5 or some other Qt 5
> specific folder.
> * Install header files to /usr/include/PythonQt and let
> libpythonqt-qt5-dev conflict libpythonqt-dev so only one of them can be
> installed at a time.
> * Install header files to /usr/include/PythonQt and only use the name
> libpythonqt-dev (no Qt 5 in the name). The policy manual, section 8.4,
> suggests that this is a possibility if you only want to support one
> development version at a time.
> 
> *Library files*
> The library files have different names, because of the new version
> (libPythonQt.so.3.1.0 vs libPythonQt.so.3.0.0), but would it be wise to
> rename the Qt 5 library to libPythonQt5.so.3.1.0 or something similarly,
> just to clearly indicate the difference? Since Qt 4 is abandoned
> upstream, I don't expect any Qt 4 packages with version 3.1.0 of the so
> files. The policy manual, section 8.1, says that "the package should
> install the shared libraries under their normal names".
> 
> The previous package libpythonqt3.0 creates the symlink
> libPythonQt.so.3.0 -> libPythonQt.so.3.0.0 but not libPythonQt.so.3 ->
> libPythonQt.so.3.0.0. Should this file be skipped also in the Qt 5 case?
> The symlink libPythonQt.so is created by the dev package, which is fine
> if the second or third solution to the dev package problem above is
> selected.
> 
> *PythonQt_QtAll*
> Previous packages built using CMake were configured to wrap the
> extension PythonQt_QtAll and only create one set of library files.
> However, the possibility to do that seems to have disappeared, and now a
> new set of library files are created (libPythonQt_QtAll.so.3.1.0 with
> corresponding symlinks). The packaging guide, section 8.1, suggests that
> it is OK to put several libraries into the same package if their SONAMES
> will always change together, and I assume that this is the case here, so
> I'm prepared to do that. Any opinions on that?
> 
> Regards,
> Erik


-- 
Una sola bomba nuclear puede arruinar el resto de tu día.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: New Package: plasma-phone (from Plasma Mobile)

[Lisandro Damián Nicanor Pérez Meyer]

Hi JBBgameich!

On martes, 17 de enero de 2017 18:35:42 ART JBBgameich wrote:
> I hope that's the right place to ask, I'm coming from the debian-mobile
> mailing list. I would wish to have the Plasma Mobile UI (plasma-phone) in
> debian, so I just wanted to ask how to
> to achieve that. I guess you don't want to do this on your own because you
> probably more important things to do, but I'm also not really experienced
> with debian packaging yet. Plasma Phone is a is "plasma-desktop for
> phones", so I thought about naming it simply plasma-phone instead of
> plasma-phone-components which is the original name.
> There are already packages for ubuntu, but they would have to be cleaned up
> and the dependencies would have to be adappted to debian. The packages for
> ubuntu are available here:
> http://neon.plasma-mobile.org:8080/pool/main/p/plasma-phone-components/.
> The Vcs-Git information is outdated, because the project migrated to
> git.kde.org for example.
> 
> Here is the basic information:
> git: https://cgit.kde.org/plasma-phone-components.git/
> Homepage: http://plasma-mobile.org
> 
> I would be grateful if you could help me with that.
>   JBBgameich

I have not cheked what's needed, but if there are libraries to be packaged 
then having packaging experience is almost a must.

I'm maintaining Qt more than KDE, so let's see if some KDE maintainer wants to 
follow this.

Also CCing the proper list.



-- 
Sobre Argentina: "sé que es uno de los países mas hospitalarios del mundo"
 Albert Einstein

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Introducing Qt-extras

[Lisandro Damián Nicanor Pérez Meyer]

Dmitry and I have been thinking for a long time in adding a kde-extras like 
subteam for Qt stuff, and with Qtav this is happening.

The subteam will have it's repos under pkg-kde/qt-extras on git.

The idea is more or less the same as KDE-extras: keep stuff not really comming 
from Qt upstream but really Qt related under a team.

For the moment I suggested Steve to use:

DEBFULLNAME="Debian Qt extras Maintainers"
DEBEMAIL=debian-qt-...@lists.debian.org

Ie, much like we do for Krap. Of course if we need to change this (comments 
welcomed!) we will just go ahead.

Standard rules follow: use our scripts to create the repos, put the 
maintainer's name in Maintainer if you want strict control or the team's name 
if you want a more collaborative maintainance, etc.

Anything I am missing?

WRT the format of the git repos I'm all for keeping it under the maintainer's 
will as with kde-extras.

Cheers!

-- 
¿De qué vive un superamigo? De las regalías de su merchandising, que sólo
puede ser adquirido por burgueses. Como a los burgueses no les agradan las
clases bajas, los superamigos sólo salvan burgueses.
  José Hipólito Moyano - http://bit.ly/fYgbLJ

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Bug#834131: Video support still not working

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 2 de enero de 2017 14:28:02 ART Steve Robbins wrote:
[snip] 
> I've never heard of Qt-extras.  If that's a better fit: fine with me.  Where
> is the repo?

Sorry for the delay! If you are still interested please join the Qt/KDE team 
on alioth. Is qtav as repo name OK for you?

Thanks, Lisandro.

-- 
20:16 < Gerardo_Cabero> che me tengo que ir volando .. sino me matan..
esto de tener novia es tan complicacdo como instalar paketes sin internet

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Bug#834131: Video support still not working

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 2 de enero de 2017 14:28:02 ART Steve Robbins wrote:
> On Monday, January 2, 2017 4:17:14 PM CST you wrote:
> > On miércoles, 28 de diciembre de 2016 14:14:51 ART Steve M. Robbins wrote:
> > > Having heard nothing, I will go ahead with packaging QtAV.
> > > 
> > > I'd really rather do this as a team-maintained package.  Is this
> > > something
> > > that would be suitable for KDE Extras?
> > 
> > Sure thing. Dmitry and I have also been thinking in Qt-extras, but
> > kde-extras is just fine.
> 
> I've never heard of Qt-extras.  If that's a better fit: fine with me.  Where
> is the repo?

We never created it, but we can easily do it.

Dmitry/anyone else: any thoughts before I go ahead? 

-- 
¿De qué vive un superamigo? De las regalías de su merchandising, que sólo
puede ser adquirido por burgueses. Como a los burgueses no les agradan las
clases bajas, los superamigos sólo salvan burgueses.
  José Hipólito Moyano - http://bit.ly/fYgbLJ

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Do we know the last binutils version it used to work?

[Lisandro Damián Nicanor Pérez Meyer]

Matthias: this bug is stopping a lot of packages from migrating and in doing 
so near the freeze is hurting many teams (and their users!) like the Qt/KDE 
one, so I'm planning to NMU it to the last working version.

Do we know which was the last version to properly work on mips*? Is there any 
drawback in going back to that version?

Of course if you have a better course of action suitable for a fast fix, I'll 
be glad to read it.

Kinds regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Bug#834131: Video support still not working

[Lisandro Damián Nicanor Pérez Meyer]

On miércoles, 28 de diciembre de 2016 14:14:51 ART Steve M. Robbins wrote:
> On Wednesday, December 21, 2016 1:30:39 PM CST Lisandro Damián Nicanor Pérez
> Meyer wrote:
> > Well, the FRP was not done by a team member nor, as far as I know, anyone
> > one the team is thinking in packaging it.
> > 
> > I'm CCing the RFP bug to see if he's still interested in packaging it. El
> > se I would suggest you to consider packaging it yourself.
> 
> Having heard nothing, I will go ahead with packaging QtAV.
> 
> I'd really rather do this as a team-maintained package.  Is this something
> that would be suitable for KDE Extras?

Sure thing. Dmitry and I have also been thinking in Qt-extras, but kde-extras 
is just fine.

Feel free to ask here for reviews if you want.

Cheers!

-- 
"Hola, soy su amigo Chespirito. Cuando estaba yo en el vientre de mi madre,
ella sufrió un accidente que la puso al borde de la muerte. El médico le
dijo: -Tendrás que abortar. Y ella respondió: -¿Abortar yo? Jamás.
Es decir, defendió la vida, mi vida. Y gracias a ello estoy aquí."
  Roberto "Chespirito" Gómez Bolaños
  http://es.wikipedia.org/wiki/Chespirito

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

[Lisandro Damián Nicanor Pérez Meyer]

On domingo, 25 de diciembre de 2016 15:48:58 ART Sandro Knauß wrote:
> Hey,
> 
> i want to enable the pending tag adding when i'll update kde git repos. So
> far I looked into https://wiki.debian.org/Alioth/Git#Setting_up_hooks
> and added /usr/local/bin/git-post-receive-tag-pending to post-receive hook.
> 
> Hopefully this change is in interest of everyone.

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

-- 
So that's it - insecure, indiscriminate, user-hostile, slow, and full
of difficult, nit-picking people. Any other online community would
count each of these strengths as a terrible flaw. Perhaps wiki works
because the other online communities don't.
  PeterMerel about wikis

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Bug#847782: ITP: kdiagram -- library for creating business charts

[Lisandro Damián Nicanor Pérez Meyer]

On domingo, 11 de diciembre de 2016 17:54:09 ART Sebastian Ramacher wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Sebastian Ramacher <sramac...@debian.org>
> 
> * Package name: kdiagram
>   Version : 2.6.0
>   Upstream Author : Klaralvdalens Datakonsult AB
> * URL : https://cgit.kde.org/kdiagram.git
> * License : GPL-2+
>   Programming Lang: C++
>   Description : library for creating business charts
> 
> KD Chart and KD Gantt provide an implementation of the ODF Chart
> specification. They utilize the Qt's model-view programming model for easy
> integration in Qt based applications.
> 
> If anyone from the Qt/KDE team wants to maintain this package instead,
> please feel free to take it.

Not that I know of, but you can use kde-extras's repositories if you want.


-- 
Without us [Free Software developers], people would study computer science
and programming without ever having seen a real program in its entirety.
That's like becoming writers without ever having read a complete book.
  Matthias Ettrich, founder of the KDE project.
  http://www.efytimes.com/efytimes/25412/news.htm

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Use of CMAKE_BUILD_TYPE=Debian

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 12 de diciembre de 2016 14:41:21 ART Jonathan Riddell wrote:
> I'm wondering if there's still a need for CMAKE_BUILD_TYPE=Debian which gets
> set on builds which use /usr/share/pkg-kde-tools/lib/kf5_flags
> 
> It's used by
> /usr/share/pkg-kde-tools/cmake/DebianABIManager.cmake
> 
> and kdelibs(4) debian/patches/add_debian_build_type.diff
> 
> The downside is it just adds some confusion, what does the build type
> mean in every other case?

I only remember there where good reasons to do that. But never digged into 
that myself.

Maybe Pino and/or Sune remember them.

> Calligra compiles different projects if you
> build with Debug or Release set

That sounds like a bug :-/

-- 
Sólo porque un mensaje pueda no ser recibido no implica que no
valga la pena enviarlo.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: kwallet-kf5 on mips

[Lisandro Damián Nicanor Pérez Meyer]

On domingo, 4 de diciembre de 2016 15:40:21 ART Sandro Knauß wrote:
> Hey,
> 
> with current kwallet 5.28.0, kwallet fails to build on mips archs
> (mips, mips64el and mipsel) [0].
> It complains about a missing symbol, that is defined in [1] and used in [2]:
> [...]/kwalletd.cpp:1805: undefined reference to
> `KWallet::Backend::entryDoesNotExist(QString const&, QString const&) const'
> [...]/kwalletd.cpp:1810: undefined reference to
> `KWallet::Backend::entryDoesNotExist(QString const&, QString const&) const'

There was a binutils bug wrt linking stuff. I *think* it should not be present 
anymore, but maybe a package needs a binNMU to fix it?

Yes, a wild guess here.


-- 
~/ sweet ~/

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Bug#842574: transition: qtbase-opensource-src

[Lisandro Damián Nicanor Pérez Meyer]

On domingo, 30 de octubre de 2016 11:15:54 P. M. ART Emilio Pozuelo Monfort 
wrote:
[snip] 
> Tracker added (should appear in 15min). Let us know if there are other
> issues. I'm all for doing this if things look fine, but please wait as I
> want to check if there are conflicts with other ongoing transitions.

ACK and thanks, we will not start until you green light us.

FWIW until this point:

- Akonadi FTBFS but patch is available #842502
- I could successfuflly rebuild everything up to libqtxdg (with exceptions, 
see below).
- I could not rebuild kwin, qtcurve and skrooge because I should have kept 
kdeclarative's rebuild around, will do that later.  
- musescore is the same false positive as usual (embeds Qt sources).
- I don't know if Dmitry would like to update pyqt5 or not, but he will handle 
that for sure (we are working on this together after all :-) )

Interesting note: I'm not seeing fcitx-qt5 this time, so maybe they should 
stop B-Ding on qtbase5-private-dev, will file a bug for that.

Thanks *a lot* for setting up the tracker!


-- 
perezmeyer: Gus no tiene inet :-(
PabloOdorico: oh
perezmeyer: te mando una copia de lo que hagamos esta noche
PabloOdorico: de ultima mandame un loro del parque con una flash en la pata ;)

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#842574: transition: qtbase-opensource-src

[Lisandro Damián Nicanor Pérez Meyer]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi! I am asking for the last Qt transition for Stretch (of course ;) )

Qt packages should be ready, but I'm still building some rdeps to
check for possible FTBFS. Somehow my ben-foo doesn't works as
it should and I couldn't create a full list of the necessary binNMUs,
so if you can set up the tracker I can double check them before
continuing.

We now for sure that akonadi will need a sourcefull upload, as it
needs a patch to avoid a FTBFS (which we have already found upstream).
Bug filed for that one.

Ben file:

title = "qtbase-opensource-src";
is_affected = .depends ~ "qtbase-abi-5-6-1" | .depends ~ "qtbase-abi-5-7-1";
is_good = .depends ~ "qtbase-abi-5-7-1";
is_bad = .depends ~ "qtbase-abi-5-6-1";


-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

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

Re: Introduction

[Lisandro Damián Nicanor Pérez Meyer]

On viernes, 21 de octubre de 2016 6:02:46 P. M. ART Raymond Wooninck wrote:
> Hi,,

Hi Raymond! And sorry for my late reply. CCing you in case you are not 
subscribed to this list (you should if you have commit acces, it's a very low 
traffic one).
 
> Based on my request to join the team, I would like to shortly introduce
> myself
> :)

\o/

> Since August this year, I got involved in helping out with KDE Neon and have
> been creating already a number of packages. An interesting experience as
> this was the first time to do some debian packaging. I am not new to
> packaging as that I have been part of the openSUSE community since 2009 and
> have been leading the openSUSE community packaging team for the KDE/Qt
> packages for the last few years. However since this summer I decided to
> join a project where there is still Fun :)  And this became KDE Neon.
>
> As that Neon is closely following the debian packaging, Jonathan Riddell
> suggested that it would be good for me to have an degian git account as
> well, so I have just placed the request :)

Glad to hear that :)

It's my duty to tell/refresh people at the fact that Neon is not Debian and 
Debian is not Neon, we have different expectations and workflows, specially on 
the Qt side of things. Of course everything that can help improve both of them 
is welcomed.

Feel free to ask whatever you need/are in doubt, specially on IRC (at least 
from my side ;) ) We will be happy to help as much as we can and time allows 
us.

By the way (and as you might have guessed) we live in different timezones so 
sometimes we have some lag ;-) An IRC bouncer uses to help with that.

Cheers!

-- 
Antiguo proverbio de El Machi: "Dado el apropiado grado de profundidad, la
ineptitud es indistinguible del sabotaje"

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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?

[Lisandro Damián Nicanor Pérez Meyer]

On viernes, 7 de octubre de 2016 4:56:03 P. M. ART Daniel Kahn Gillmor wrote:
[snip] 
> > And also: yes, -fPIE needs overriding if using hardening flags.
> 
> can you explain that in more detail?  what specifically should be
> overridden and where?

Sure. Hardening adds -fPIE to CFLAGS/CXXFLAGS, so you either need to remove it 
from there with

  CXXFLAGS -= -fPIE # Untested, but should work

or simply not enabling all hardening features:

<https://wiki.debian.org/
Hardening#Enable_or_disable_certain_hardening_features_separately>

Just use -pie there.

I wonder what +all,-pie would do there.

-- 
porque no respeta el orden natural en el que se leen las cosas
>¿por qué top-posting es tan molesto?
>>top-posting
>>>¿cuál es la peor molestia en los emails de respuesta?

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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?

[Lisandro Damián Nicanor Pérez Meyer]

On viernes, 7 de octubre de 2016 6:35:00 P. M. ART Dmitry Shachnev wrote:
> On Fri, 07 Oct 2016 08:54:53 -0400, Daniel Kahn Gillmor wrote:
> > I've been reading about -fPIC and -fpic and -fPIE and -fpie and -pie for
> > years and i confess i've never completely understood the differences or
> > whether one is "stronger" than another.
> > 
> > gcc says of -fPIE and -fpic "generated position independent code can be
> > only linked into executables." which makes it seem odd that these
> > parameters would be passed through to building libraries in the first
> > place.
> 
> -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.

-- 
Sobre Argentina: "sé que es uno de los países mas hospitalarios del mundo"
 Albert Einstein

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

[Lisandro Damián Nicanor Pérez Meyer]

On jueves, 29 de septiembre de 2016 4:45:10 P. M. ART Dmitry Shachnev wrote:
[snip] 
> For the record: it was succeeding for builds where Build-Depends-Indep were
> installed, because qttools5-dev-tools pulls in libqt5quick5 (via webkit).

Ah, that explains it quite well. Thanks *a lot* Dmitry for digging into this!


-- 
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself.  Therefore all
progress depends on the unreasonable man.
  George Bernard Shaw

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

[Lisandro Damián Nicanor Pérez Meyer]

On miércoles, 28 de septiembre de 2016 12:10:10 A. M. ART Sandro Knauß wrote:
> Hey,
> 
> thanks for your great tipps. Finally I got the tests running with xvfb and
> the patched locations:
> 
> https://anonscm.debian.org/cgit/users/hefee-guest/qtdeclarative.git/commit/?
> id=281e19175a701a1906377373eda92d9914e82094
> 
> Still I need to disable some tests, but I'm too tired for now to test again
> if the list is the minimal one...

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?



-- 
...man had always assumed that he was more intelligent than dolphins because
he had achieved so much -- the wheel, New York, wars and so on -- whilst all
the dolphins had ever done was muck about in the water having a good time.
But conversely, the dolphins had always believed that they were far more
intelligent than man -- for precisely the same reasons.
  Douglas Adams, "The hitchhikers' guide to the galaxy"

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: SDDM in tty1 by default

[Lisandro Damián Nicanor Pérez Meyer]

Thanks *a lot* for the info Maxy!


-- 
5: Para que sirve el comando "deshacer"
* Para olvidarse de una noche de alcohol
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Packaging QtSpeech

[Lisandro Damián Nicanor Pérez Meyer]

On martes, 16 de agosto de 2016 2:51:17 P. M. ART Simon Quigley wrote:
> Hello everyone,
> 
> So it seems QtSpeech packaging hasn't started yet:
> https://anonscm.debian.org/cgit/pkg-kde/qt/qtspeech.git/
> 
> It also seems like there's no tag yet:
> http://code.qt.io/cgit/qt/qtspeech.git/
> 
> I would like to start initial packaging using a daily tarball. I've
> pushed my work here, https://git.launchpad.net/~tsimonq2/+git/qtspeech
> 
> Let me know what you think.

Here goes my review:

= debian/changelog

If you intend this package to be under the Qt/KDE team umbrella you need to 
follow the [changelog guidelines]. In this specific case the changelog should 
be "signed" by the team's e-mail until the package is released (section 1 of 
the link).

[changelog guidelines] <http://pkg-kde.alioth.debian.org/
changelogstandard.html>

= debian/control

- Do you really need chrpath? If you do then you have probably found a bug 
upstream.

- What do you need kbd for? It's not a development package per-se. Maybe 
tests?

- Vcs-[Browser Git]: you probably used your launchpad one for the initial 
setup, but if you point to push it to our repos feel free to use the team's 
ones.

- Homepage: I still think that pointing to the docs it's not the right 
homepage, but it might be a matter of taste.

- And the package needs a better description, but that's clearly a WIP.

= debian/copyright: clearly WIP.

= debian/rules: it seems to come from a webkit-related package. Do you really 
need to set which archs get -gstabs? This needs a mjor overhaul. Moreover for 
simple submodules like I think this will be it's easier to start with a plain 
debian/rules or a templated one.

= git

Use one commit per related changes. As you are starting the packaging you 
might want to use one commit per file. Except the commit it's related to two 
or more files, of course. Example: if you add a package in debian/control and 
that package provides a .install file, then they should happen in the same 
commit. Of course we are not perfect and we make mistakes: if you accidentally 
pushed something that oversees this and if it's not too much of a hazzle, just 
keep it like this.

Cheers!
-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

[Lisandro Damián Nicanor Pérez Meyer]

[snip]
> Use of the machine readable copyright format is entirely optional.  It's
> encouraged, thus the lintian check, but it's not a problem if it's not
> machine readable.

I must admit I tend to forget this because I prefer structured things, but 
this is of course totally right.


-- 
Una vez que hemos eliminado lo imposible, lo que queda, por improbable que
parezca, es la verdad.
  Sherlock Holmes

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

[Lisandro Damián Nicanor Pérez Meyer]

On martes, 26 de julio de 2016 7:33:54 P. M. ART Simon Quigley wrote:
[snip]
> > - Linking them, as long as they are in the same package, should be ok.
> > It's
> > simply to do too.
> 
> I'm unfamiliar with how this would be done, and I'm curious how.
> 
> debian/patches ?

rm all except one, use debian/.links

[snip] 
> How does being in Uploaders work? Does that mean we've touched the
> package? Does that mean we have upload rights to this package? I've
> never used this before.

Normally it's up to the original packager/team, but in this case you are the 
three ones working on this and none of us regular Qt maintainers, so...

[snip]
> About copyright.
> 
> In my branch, I added myself to the copyright file for the debian/
> directory, and I propose that the people in that entry should be me,
> Scarlett, and Sandro. Thoughts?

You did exactly the right thing.

> > - debian/.directory really?
> 
> What is this?

Good question :) A Plasma/dolphin file that should have never been there :)

[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 :)

-- 
"No es el crecimiento de la tecnología lo que excluye, sino la
protección sistemática de los derechos de uso de la misma,
lo cual se puede aplicar al arte."
  David Cuartielles

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#827939: Please consider marking mesa-utils as Multi-Arch: allowed

[Lisandro Damián Nicanor Pérez Meyer]

Package: mesa-utils
Version: 8.3.0-1
Severity: wishlist

tl;dr: make mesa-utils M-A: allowed in order to be able to depend on it as
mesa-utils:any

Hi! libqt5gui5 now ships a script in order to detect wether users have an
OpenGL2 compatible video card. It case they don't it sets up an environment
variable to let Qt now that it should use rasterization instead.

The script uses mesa-utils' glxinfo package for this.

Problem arises that libqt5gui5 is M-A: same, but ends up depending on
mesa-utils:.

If mesa-utils gets marked as M-A: allowed then we can make libqt5gui5
depend upon mesa-utils:any, ie, any arch' version of mesa-utils will satisfy
the dependency.

I would highly appreciate if you can at least reply if you are OK or not with
the idea, as we currently have a broken M-A libqt5gui5 and would like to
take the necessary steps to solve this.

Thanks a lot in advance, Lisandro. 

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 
'buildd-unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages mesa-utils depends on:
ii  libc6 2.22-12
ii  libgl1-mesa-glx [libgl1]  11.2.2-1
ii  libglew1.13   1.13.0-2
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1

mesa-utils recommends no packages.

mesa-utils suggests no packages.

-- no debconf information

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

Bug#827470: RM: qt3d-opensource-src -- ROM; Moving to experimental only until it's API/ABI becomes stable

[Lisandro Damián Nicanor Pérez Meyer]

Package: ftp.debian.org
Severity: normal

Hi! With my Qt maintainer hat on I would like to ask you to remove
qt3d-opensource-src from unstable *only*.

We will keep it in experimental until it gets a stable API/ABI.

Thanks in advance!

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

Bug#827194: RM: qtquick1-opensource-src -- ROM; Deprecated, will not build anymore with current Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Package: ftp.debian.org
Severity: normal

Hi FTP masters! I would like to ask you to remove qtquick1-opensource-src from
both unstable and experimental.

It will not longer build with the current version of Qt in unstable (actually
the one being built right now).

Affected packages are kadu, kadu-mime-tex and musescore:



Thanks in advance, Lisandro.

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

Bug#827177: transition: qtbase-opensource-src

[Lisandro Damián Nicanor Pérez Meyer]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi RT! After a long wait we pushing Qt 5 to unstable again.

It is worth to note that with this transition qtquick1-opensource-src
will no longer build and so we will ask for it's removal.

Affected packages are kadu, kadu-mime-tex and musescore:



Thanks in advance!

Ben file:

title = "qtbase-opensource-src";
is_affected = .depends ~ "qtbase-abi-5-5-1" | .depends ~ "qtbase-abi-5-6-1";
is_good = .depends ~ "qtbase-abi-5-6-1";
is_bad = .depends ~ "qtbase-abi-5-5-1";

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 
'buildd-unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

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

Bug#826577: transition: qtquick1-opensource-src

[Lisandro Damián Nicanor Pérez Meyer]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi RT! With the arrival of Qt 5.6.1 we will be removing
src:qtquick1-opensource-src. We have already been filing bugs against the
affected packages, which should be really a few now.

I would like to set up a tracker to have a proper view of the removal.
I'll ask for a Qt 5.6.1 transition later.

Note: I have not tried the ben file below.

Thanks!

Ben file:

title = "qtquick1-opensource-src removal";
is_affected = (.build-depends ~ qtquick1-5-dev | .depends ~ libqt5declarative5 
| .depends ~ qtquick1-5-dev-tools | .depends ~ qtquick1-5-examples | .depends ~ 
qtquick1-qml-plugins | .depends ~ qtquick1-qmltooling-plugins | .build-depends 
~ qtdeclarative5-dev);
is_good = .build-depends ~ qtdeclarative5-dev;
is_bad = (.build-depends ~ qtquick1-5-dev | .depends ~ libqt5declarative5 | 
.depends ~ qtquick1-5-dev-tools | .depends ~ qtquick1-5-examples | .depends ~ 
qtquick1-qml-plugins | .depends ~ qtquick1-qmltooling-plugins);


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'buildd-unstable'), (500, 'testing'), 
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.5.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

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

Re: Letting Qt5 build on ppcspe

[Lisandro Damián Nicanor Pérez Meyer]

On Tuesday 31 May 2016 14:42:45 John Paul Adrian Glaubitz wrote:
> Hi Dmitry!
[snip]
> Do you have any idea why this happens? Could there be possibly a build
> dependency be missing? This particular package definitely built
> successfully on powerpcspe in the past (I did a testbuild with
> 4:4.8.5+git209-g718fae5+dfsg-1 which previously built fine), so unless
> there is something broken in the toolchain (which I also don't think since
> powerpcspe basically uses the powerpc backend of gcc), I think that qt4-x11
> depends on these precompiled headers being present from an external package
> which might not be there unless Qt5 is fully bootstrapped.
> 
> Thanks for your help!
> 
> Adrian

The last upload of qt4-x11, 4:4.8.7+dfsg-8, disables pch on powerpcspe. I 
uploaded it a few days ago, although the patch has been there for moths (I'm 
the one to be blamed there, I promised to push it sooner and then it just 
slipped).

Can you try that one?

Thanks, Lisandro.


-- 
 They are plenty, a whole hurd of gnus.
* pinotree turns OdyX upside down
 ˙snuƃ ɟo pɹnɥ ǝloɥʍ ɐ 'ʎʇuǝld ǝɹɐ ʎǝɥʇ
 gh
 (-: ˙ǝsɐǝןd 'dn ʞɔɐq ǝɯ uɹnʇ ǝsɐǝןd ʍou
* pinotree turns OdyX upside down again
 Thank you.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Letting Qt5 build on ppcspe

[Lisandro Damián Nicanor Pérez Meyer]

Hi Roland! Just for the record, for what I see in [build] you just need to 
build qtchooser without tests (and so dropping qtbase5-dev from build 
dependencies) in order to bootstrap it (or build it with nocheck in 
DEB_BUILD_OPTIONS).

[build] http://deb.li/qt5builds

Happy hacking!


-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Neon enablement in qt for raspbian.

[Lisandro Damián Nicanor Pérez Meyer]

Switching to pkg-kde-talk@l.d.o, as it's a better place for this.

Hi Peter!

On Thursday 21 April 2016 15:09:53 Peter Green wrote:
[snip]
> There are two qt source packages in raspbian jessie where we currently
> have neon disabled. qt4-x11 and qtbase-opensource-src . I have a couple
> of questions.
> 
> 1: are these packages supposed to have runtime neon detection (either in
> the packages own code or through ld.so hwcaps).

First of all Qt4 is dead upstream, so the best thing to do in this case is 
keep it as it is. If someone complains hint them to port their apps to Qt5. 
Sounds harsh, I know, but...

With respect to qtbase it seems to be a build time configuration, possibly 
based on config.tests/arch/arch.cpp. And if I remember correctly the Ubuntu 
folks used to have a neon-enabled build, but don't take my word on it.

It *might* be possible to use ld hwcaps as we do for i386 and SSE2, provided 
ld has the necessary code.

> 2: For each of the packages can anyone suggest a simple benchmark/test
> that will hit the neon codepaths which I can use to check that neon
> detection is doing it's job (i.e. that the package still works on the
> pi1 and there is a performance improvement over the package without neon
> on the pi2)

Get a Qt graphical-intensive app not using OpenGL, the difference should be 
noticeable. Maybe the QGraphics's [demos] would be enough.

[demos] Provided by qtbase5-examples and installed into
  /usr/lib//qt5/examples/widgets/graphicsview/

I want to point out that I have never had the chance to check it on Neon-
enabled hardware *but* I did test iwmmxt-enabled devices with Qt4. The basic 
idea behind them is the same: SIMD instructions, which can be really cool when 
dealing with, for example, graphics without hardware-based OpenGL, so my guess 
is that it will show there for sure.

Now with my maintainer hat on: I don't think we would like to support this on 
Debian. Some issues I see:

- Acording to [wikipedia] all Cortex-A8 devices have the instruction set but 
on Cortex-A9 they are optional: we can't warrant it will be available 
everywhere → using it would need ld hwcaps (if applicable) and double builds 
but... is it worth the effort? Now it *might* really worth it for raspbian.

[wikipedia] 
<https://en.wikipedia.org/wiki/ARM_architecture#Advanced_SIMD_.28NEON.29>

- As I wrote above it will require double builds like we do on i386 thus 
increasing build time and possibly requiring more maintainership work. On i386 
we do it because we have no other choice... and that's not the case here :-/

- It will require that all ARM buildds (or maybe just the compilers in them?) 
support NEON to get it properly detected.

That being said if I where maintaining stuff for raspbian I would certainly 
consider doing this (again, as long as ld hwcaps can deal with it). Tip: not 
everything should be rebuilt, just check what we rebuild for i386 with SSE2. 
With those libraries covered the impact should be visible.

Hope it helps, Lisandro.

-- 
20:57  * m4rgin4l patento el proceso de invencion
20:57 < m4rgin4l> de aqui en mas cualquier inventor me tiene que pagar
regalias por inventar algo
20:57  * m4rgin4l tiene la patente pendiente del metodo cientifico

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Apologies to Rohan and some more

[Lisandro Damián Nicanor Pérez Meyer]

On 14 March 2016 at 20:01, Rohan Garg <rohang...@kubuntu.org> wrote:
> Hi
>> And again, Rohan, my apologies.
>
> Apologies accepted.

Thanks :)

> Let's move forward and keep doing awesome work together :)

ACK, and please re apply for membership as as far as I know it is not
possible to add people "by hand".

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

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

Apologies to Rohan and some more

[Lisandro Damián Nicanor Pérez Meyer]

Let's start with the most important thing: I screwed up with my handling of 
Rohan's commits access. So: Rohan, my most sincere apologies. Technical 
details aside, I handled it in the wrong way.

We failed at various levels, me being one of the most incisive ones. That 
doesn't changes my point of view of the repo handling, but we should at least 
have managed things differently.

I still think people should be mentored until we know they understand how to 
handle the repos and on the other side, in Philip Muskovac's (yofel's) words 
the ubuntu folks are unable to grant commit rights to their people.

I still think there is room for collaboration, but in another way: using the 
magic of git repos and proper hooks.

We can easily add hooks to push our commits to LP's servers (in a special 
branch maybe?) and if desired (and LP supports it), the other way around.

Of course, I would very much appreciate another ideas.

And again, Rohan, my apologies.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: kdeconnect repos mess

[Lisandro Damián Nicanor Pérez Meyer]

Replying on-list, Maxy told me that he's reply was intended to the list.

On Tuesday 02 February 2016 11:31:16 Maximiliano Curia wrote:
> On 01/02/16 21:33, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Currently we have two repos for kdeconnect:
> > 
> > = http://anonscm.debian.org/cgit/pkg-kde/kde-extras/kdeconnect.git/
> > 
> > = http://anonscm.debian.org/cgit/pkg-kde/kde-extras/kdeconnect-plasma.git/
> 
> The first one was the kde4 version of kdeconnect, the second one was created
> by kubuntu to work on the plasma 5 version of kdeconnect, and is still in
> use by them (check the branches kubuntu_xenial_archive and
> kubuntu_unstable).
> > - But simply removed the git history from the above one, pushing
> > everything as a single commit. Bad.
> 
> It should be easy enough to merge the branches to gain back the history from
> the other repository.
> > So what on earth I am supossed to do with these ones?
> > I'm tempted to keep the original one because it keeps the correct history
> > and remove the other one, which is useless for Debian.
> 
> Don't remove it, ping Riddel if you think something different should have
> been done. We pushed to have shared git repositories with Kubuntu, it
> doesn't matter it there things that aren't useful to Debian anymore.

I won't remove it for now until we clear up this then.

But please take into account:

- The shared repos where for the *kde* side of the team, not kde*-extras* nor 
Qt.

- kde-extras is a special case in itself. Each repo belongs to it's principal 
maintainer(s). We can, as a team, do updates from time to time but *always* 
with the ACK from the principal maintainer(s). In case of long absences in 
which the maintainers are not reachable we can of course notice the fact in 
this very list, wait some days (normally 5 is fine) and then contribute to the 
repo doing the best effort to keep the maintainer's workflow. That's team 
work.

- We can't overtake a repo without asking the original maintainer(s) first. 
Again, team work. For the kdeconnect special case I don't know the status of 
this, I asked recently and it seems my question was misinterpreted.

Now following kdeconnect's situation as an example. We might have two possible 
outcomes:

- It is agreed with the maintainer to use a new repo for the plasma5/qt5 
version. Tis is cool, but in this case do not imort old history, as we 
consider this a new source.

- It is agreed that we keep the old repo. In this case use branches as a 
special case. Of course, that fits well in Debian's normal workflow, having 
separated branches for Ubuntu stuff just gets things complicated in my 
opinion, but...

I might have missed something, but we really need clear rules to play along as 
a *team* who cares about *Debian* and not as to different entities sharing 
repos. In this last case I would simply prefer not to share anything.

Now, as Scott has once proposed on IRC: let's try to get a common ground here 
with clear rules. There is no other way to act like a team, if that's what we 
really want to achieve.

I'm listening you now.

-- 
Trabaja como si no necesitaras el dinero.
Ama como si nunca hubieses sido herido.
Baila como si nadie estuviera mirando.
Canta como si nadie escuchara.
Vive como si fuera el Cielo en la Tierra.
  Anónimo

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

kdeconnect repos mess

[Lisandro Damián Nicanor Pérez Meyer]

Currently we have two repos for kdeconnect:

= http://anonscm.debian.org/cgit/pkg-kde/kde-extras/kdeconnect.git/

- Original repo by original maintainer. Good.
- Outdated version wrt upstream, same as we currently ship in Debian. Just 
needs an update.
- Has the source code in it, possibly using gbp or alike, which is allowed by 
our rules for extra stuff.

= http://anonscm.debian.org/cgit/pkg-kde/kde-extras/kdeconnect-plasma.git/

- Repo created by J. Ridell (why?) which only has debian/ in it.
- But simply removed the git history from the above one, pushing everything as 
a single commit. Bad.
- Not shipped in Debian but with Debian references. part of kde-extras, not 
kde proper.


So what on earth I am supossed to do with these ones?

I'm tempted to keep the original one because it keeps the correct history and 
remove the other one, which is useless for Debian.

Will get to that if no one complains in ~5 days.

-- 
14: Para acceder y navegar en internet
* Debe tener conexion a Internet
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Bug#802659: dbus-python: Please drop recommends on PyQt4 packages

[Lisandro Damián Nicanor Pérez Meyer]

Hi Simon! For what it's worth Dmitry is the python-knowledgeable guy in the Qt 
packaging team. So I just trust him :)

Kinds regards, Lisandro.

-- 
Why should I care about posterity?
What's posterity ever done for me?
  -- Groucho Marx

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

[Lisandro Damián Nicanor Pérez Meyer]

Hi Sandro!

On Sunday 24 January 2016 03:22:47 Sandro Knauß wrote:
> 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.

On the same base that mails are important for users, should we ship something 
that might be security-compromised and with no upstream support for something 
so important as mails?

And mails fall exactly in the category of "app that handles unstrusted data" 
I'm afraid :-/

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

[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 ;)


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Qt4's Webkit in Stretch

[Lisandro Damián Nicanor Pérez Meyer]

Hi everyone! I would like to discuss the current situation for Qt4's Webkit in 
Stretch.

Let me first start with some facts:

= Facts =

- Both Qt4 and (by inclusion) Qt4's webkit are no longer supported upstream.

- If a security bug appears in Qt4 during Stretch's lifetime I'm pretty sure 
we will be able to come up with a patch. There is too much people depending on 
it out there so this won't be a problem for Stretch.

- For Qt4's webkit the situation might probably be the other way around. 
Actually we might already have (quite some?) security bugs out there.

= Removal efforts and options =

So last year we started to work on removing it [removal]. Progress is sadly 
far from good. We still have quite a lot of apps depending on qebkit in order 
to show things like doc. Most of them do not use it for web browsing.

[removal] <https://wiki.debian.org/Qt4WebKitRemoval>

This has been discussed in the Qt/KDE team quite a lot of times with different 
opinions. For what I could gather the possible options are:

(keep) Keep Qt4's webkit as it is in Stretch and warn users that they will get 
*no* security support.

(removeintesting) Remove Qt4's webkit from testing, file an RC bug against it 
so it doesn't transition and let rdeps be removed from testing until they 
switch. Of course we will need the RT's approval for this.

(totalremove) Remove Qt4's webkit from the archive together with it's rdeps 
(or leave the rdeps RC buggy in unstable).

Does anyone has a better idea?

= What do we do? =

If we take the (keep) option we need a good way to ensure users get the fact.

If we go for any of the other two options we will need the RT/FTP team to ACK 
the move.

So I would really like to hear the opinions of people in both teams. If you 
really think a certain way forward should be taken please speak now.

Kinds regards, Lisandro.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

[Lisandro Damián Nicanor Pérez Meyer]

On Friday 22 January 2016 17:16:26 Lisandro Damián Nicanor Pérez Meyer wrote:
[snip] 
> Does anyone has a better idea?

Not necesarily better, but an idea after all:

(partialremove) check which packages use qt4's webkit for web browsing and 
only remove those from testing.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

How to update kdeconnect

[Lisandro Damián Nicanor Pérez Meyer]

Today I talked with David and wanted to update kdeconnect. But found out that 
we have two separate repos for it.

The original had the source code in it, which is normal considering it is part 
of kde-extras.

The new one does not has sources on it, but all the branches have ubuntu-
specific stuff, even master.

I would simply remove the ubuntu specific stuff from master and use the 
necesaary updates in the other branch, but before breaking someone else's 
workflow I would really love to know how this should be handled.

Thanks, Lisandro.

-- 
No pienses que estoy loco, es sólo una manera de actuar
  De mí - Charly García

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Tightening dependencies within the source package

[Lisandro Damián Nicanor Pérez Meyer]

On Thursday 07 January 2016 19:59:30 Dmitry Shachnev wrote:
> Hi,
> 
> As you already know, in Qt 5.6 there was a change in ELF versions, from
> @Base to @Qt_5. I have developed a script for that (migrate-symbols.py)
> that scans the build log and updates the symbols files accordingly. That
> script changed the ELF version tags, but it did not touch the package
> version numbers.
> 
> Now I have a bug: qttools5-dev-tools dependency on libqt5help5 is not
> enough: it depends on libqt5help5 (>= 5.0.2), however fails to work with
> 5.5:
> 
> /usr/lib/x86_64-linux-gnu/qt5/bin/qhelpgenerator:
> /usr/lib/x86_64-linux-gnu/libQt5Help.so.5: version `Qt_5' not found
> (required by /usr/lib/x86_64-linux-gnu/qt5/bin/qhelpgenerator)
> 
> How can I make sure a proper dependency is generated?

Build-Depends-Package from deb-symbols(5) possibly. That's what I wanted to 
add to qtbase, but you where faster than I to package it and then I forgot 
about it.


-- 
Una sola bomba nuclear puede arruinar el resto de tu día.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Tightening dependencies within the source package

[Lisandro Damián Nicanor Pérez Meyer]

On Thursday 07 January 2016 19:59:30 Dmitry Shachnev wrote:
> Hi,
> 
> As you already know, in Qt 5.6 there was a change in ELF versions, from
> @Base to @Qt_5. I have developed a script for that (migrate-symbols.py)
> that scans the build log and updates the symbols files accordingly. That
> script changed the ELF version tags, but it did not touch the package
> version numbers.
> 
> Now I have a bug: qttools5-dev-tools dependency on libqt5help5 is not
> enough: it depends on libqt5help5 (>= 5.0.2), however fails to work with
> 5.5:
> 
> /usr/lib/x86_64-linux-gnu/qt5/bin/qhelpgenerator:
> /usr/lib/x86_64-linux-gnu/libQt5Help.so.5: version `Qt_5' not found
> (required by /usr/lib/x86_64-linux-gnu/qt5/bin/qhelpgenerator)

Now the real interesting thing is that I built qtbase 5.6 and run apps built 
against qtbase 5.5 without issues :-/


-- 
Sea estricto cuando envíe y tolerante cuando reciba. En otras palabras, solo
envíe paquetes que cumplan rigurosamente con lo estándares, pero espere
paquetes que tal vez no cumplan del todo y trate de lidiar con ellos.
  Andrew S. Tanenbaum, de su libro "Computer Networks"

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Tightening dependencies within the source package

[Lisandro Damián Nicanor Pérez Meyer]

On Thursday 07 January 2016 21:18:16 Pino Toscano wrote:
> In data giovedì 7 gennaio 2016 22:49:24, Dmitry Shachnev ha scritto:
> > Hi Pino,
> > 
> > On Thu, Jan 07, 2016 at 08:19:03PM +0100, Pino Toscano wrote:
> > > @Qt_5 symbols need to require version >= 5.6.0~beta, then: if not, the
> > > version filled in packages is not enough, causing runtime failures like
> > > the one you pasted above.
> > 
> > You mean I should bump the symbols versions, right?
> 
> Yes.

Dmitry went this way already, so things should work now. Thanks Pino for 
helping us with this :)

Now on a different but related matter we still had doubts on why applications 
built with Qt 5.5 would work with Qt 5.6 even if the version nodes changed.

As described in [0]:

  "When the linker finds a symbol defined in a library which is not
   specifically bound to a version node, it will effectively bind it to an
   unspecified base version of the library."

So basically ld will link any app depending on the @Base version node to a lib 
that fullfils the symbol no matter it's version node, thus apps compiled 
against Qt << 5.6 will still work with Qt >= 5.6.

[0] <https://sourceware.org/binutils/docs/ld/VERSION.html>

All in all it was a very good idea to start packaging 5.6 during it's beta. 
Thanks everyone!

-- 
Outside of a dog, a book is man's best friend.
Inside of a dog, it's too dark to read.
 -- Groucho Marx

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Building DigiKam 4.14 with libkgeomanip and other former "extras"

[Lisandro Damián Nicanor Pérez Meyer]

On Monday 28 December 2015 15:07:12 Dmitry Shachnev wrote:
> Hi Steve,
> 
> On Sun, Dec 27, 2015 at 12:08:45PM -0600, Steve M. Robbins wrote:
> > DigiKam itself currently uses (Qt4-version) libqtwebkit-dev.  I saw the
> > bug
> > about it and the web page https://wiki.debian.org/Qt4WebKitRemoval
> > What I haven't seen is a precise time for this.  The schedule for Digikam
> > 5
> > release is May, so I (hopefully) won't need to care after that.  Is the
> > webkit going to be removed before next May?
> 
> Actually I would like it to be removed before May. I am going to bump bugs
> severities to important soon (in January) and make them RC a couple of
> months after that (i.e. in March) to get the packages removed from testing
> (or fixed).
> 
> I am also going to remove the PyQt5 QtWebKit bindings very soon (in a couple
> of weeks).
> 
> So maybe it's not the best idea to introduce a new package using QtWebKit.
> 
> Lisandro, you did not reply to this part of Steve's message, what do you
> think?

We need a kf5-based kdepim in unstable first. I was told that current packages 
in experimental are not ready for unstable yet.

-- 
When the winds of change are blowing, some people are building shelters, and
others are building windmills.
  Old Chinese Proverb

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Building DigiKam 4.14 with libkgeomanip and other former "extras"

[Lisandro Damián Nicanor Pérez Meyer]

On Monday 28 December 2015 15:40:14 Lisandro Damián Nicanor Pérez Meyer wrote:
[snip] 
> We need a kf5-based kdepim in unstable first. I was told that current
> packages in experimental are not ready for unstable yet.

For what it's worth digikam is already in the archive, so just go ahead Steve.

-- 
Programming is really just the mundane aspect of expressing a solution to a
problem. There are talents that are specifically related to actually coding,
but the real issue is being able to grasp problems and devise solutions that
are detailed enough to actually be coded.
  John Carmack answers on Slashdot,
  http://slashdot.org/games/99/10/15/1012230.shtml

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: New Base for symbols in Qt5.6

[Lisandro Damián Nicanor Pérez Meyer]

On Sunday 27 December 2015 15:43:59 Dmitry Shachnev wrote:
> Hi Lisandro,
[snip]
> My script (debian/scripts/migrate-symbols.py in qt56-symbols branch) is
> *much* smarter than plain sed -i 's/@Base/@Qt_5/g'.

I have no doubt in that. My intention wasn't to check your branch but to check 
if the change in the version node [0] from Base to Qt_5 would make apps 
compiled against Qt 5.5 fail to be linked against Qt 5.6. Good news is that 
everything still works.

[0] <http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html>

On a side note this feature is analogous to what our symbols files do [1]. But 
that doesn't means we should drop symbols files ;)

[1] 
<https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html>

> Its algorithm is:
> 
> 1. Get the list of symbols in new libraries based on the build log.
> 
> 2. For each symbol in the symbols file, check if that symbol exists in the
>new libraries.
> 
>- If it exists, changes the version part of the symbol to Qt_5 or
>  Qt_5_PRIVATE_API, depending on what's found in the new library.
> 
>- If it doesn't exist, leaves it unchanged (maybe the symbol is for
>  another architecture) so that we can process it the usual
> symbolshelper- based way.
> 
> 3. For each old symbol that has disappeared, and is not optional or private,
> warns that it is removed. For qtbase its output is:
>http://paste.debian.net/355955/
> 
> And yes, changing the version part of the symbols does not break the ABI,
> however removing the old symbols does (so we need to be careful).
> 
> > So I think it's safe to go ahead with the changes.
> 
> So are you OK with merging my branch? :)

I was talking about the upstream change in symbols' nodes :)

But let me check the branch (done, see below).

> I have just updated it based on i386 build log.
> 
> > Dmitry: we still need to look for private symbols as we used to, IIRC
> > there
> > where some cases of upstream not marking private symbols as such. having
> > both methods at hand will surely catch those cases.
> 
> However I also know that our current algorithm has some false positives —
> i.e. it marks functions using *pointers* to private objects as private, even
> if they are part of public API. I thought that by fully switching to
> upstream algorithms, we will get rid of that bug.

Do you have an example of such a case? The script was being run over private 
headers only, so even pointers to private functions should be private.

> Do you have any examples of "upstream not marking private symbols as such"?

Forget that, I mixed stuff. The symbols are marked as private by using a list 
created by syncqt.pl, so things should be fine.

> In any case I think we should keep the logic in pkg-kde-tools package, i.e.
> replace the existing script with mine or extend its logic. I hope Python
> dependency is not a problem, is it?

I'm totally for it. If it becomes a problem for someone we can consider 
generating a new binary package from the same source and adding the python 
dependency there. We might even do that from the beginning.

> P.S. I will be offline most of today, will be able to look at anything only
> tomorrow (MSK time).

And of course I'll be AFK tomorrow, maybe come back online late on ARST's 
night. Gah, timezone are hard for us :)

OK, I've checked the branch and I merged it to experimental. Please do not 
forget to add the proper copyright headers to the scripts.

Should we keep the merging script? I think having it on git's story should be 
enough. I also don't mind shipping it once in the packages.

-- 
15: Que es el "Correo Electronico"
* El correo que te llega por la corriente
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Building DigiKam 4.14 with libkgeomanip and other former "extras"

[Lisandro Damián Nicanor Pérez Meyer]

On Sunday 27 December 2015 12:08:45 Steve M. Robbins wrote:
> Hi,
> 
> Thanks a lot to all who responded.  I sense a strong feeling against
> introducing new Qt4-based packages right now.  And this makes sense to me.
> 
> Given that my only motivation for a Qt4 version of these libraries is for
> DigiKam 4.x, I will propose instead to avoid the new library packages by
> bundling the sources into digikam.  This is, essentially, returning to the
> situation with DigiKam 4.4, which included sources for the following:
> libkdcraw  libkexiv2  libkface  libkgeomap  libkipi  libksane  libkvkontakte
> libmediawiki.  Some of these are currently in the archive as Qt4 versions
> and some are not.  My strategy would be to bundle the minimum necessary.
> 
> I know the Debian stance on "convenience" copies of libraries, but in this
> case (a) no-one wants or needs a new Qt4 version of these libraries, and (b)
> it is temporary as DigiKam 4.x is going away within 6 months.
> 
> Let me know if you have a better idea.

I would simply say: ship it. I think that in this *very specific* case it's 
the right way to go.

-- 
15: Que es el "Correo Electronico"
* El correo que te llega por la corriente
Damian Nadales
    http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

New Base for symbols in Qt5.6

[Lisandro Damián Nicanor Pérez Meyer]

As some of you might know for what we have been discussing on IRC Qt 5.6 
introduced the notion of adding symbols version to the symbols it generates.

I'm not an expert on this area (so feel free to correct me if you think I'm 
wrong), but basically we should stop seeing symbols like:

  foo@Base 5.6.0

To see:

  foo@Qt_5 5.6.0

If I understood things correctly this was added upstream in order to, in the 
future, allow certain compatibility between Qt5 and Qt6. For example let's 
supose VLC loads two plugins: one built against Qt5 and another built against 
Qt6.

In the previous form the Qt6-based plugin might declare a QString, and chances 
are that the linker would load the Qt5 version. With this change it should 
load the appropriate one on each case.

We also have special definitions for private symbols, so we will catch them 
more easily.

Now we feared that this change would create us problems with loading apps 
compiled against older versions of Qt. In order to test this I built qtbase 
5.6 beta with this changes:

- sed -i 's/@Base/@Qt_5/g'  # yes, private symbols would get this wrong.
- Build qtbase and get symbols changes.
- Process them with pkgkde's symbolshelper. In this step private symbols will 
get corrected by marking as missing the @Base versions and "new ones" 
appearing with @QT5_PRIVATE in them.
- Build again this time succesfully getting the binary packages.
- On a VM I installed both an app I compiled with Qt 5.5 and hexalate, which 
only require stuff present in qtbase and qt5.6~beta's qtbase5-dev and 
dependencies.
- ssh -X the VM and run them both without issues.

So I think it's safe to go ahead with the changes.

Dmitry: we still need to look for private symbols as we used to, IIRC there 
where some cases of upstream not marking private symbols as such. having both 
methods at hand will surely catch those cases.

Kinds regards, Lisandro.

-- 
Si vives cada día de tu vida como si fuera el último,
algún día realmente tendrás razón.
  Steve Jobs

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Building DigiKam 4.14 with libkgeomanip and other former "extras"

[Lisandro Damián Nicanor Pérez Meyer]

On Tuesday 22 December 2015 15:52:00 Dmitry Shachnev wrote:
> Hi Scott,
> 
> On Tue, Dec 22, 2015 at 07:08:06AM -0500, Scott Kitterman wrote:
> > It's not a new package.  It was just behind several releases and the
> > question was to either update to the last Qt4 release or an unreleased Qt5
> > version.
> 
> By “new package” I meant kgeomanip, which was never packaged.

As long as it doesn't depends on qtwebkit we should be fine.

Steve: if you need to add it just go ahead please. As you said Digikam is 
expected to switch to Qt5 later next year so it's worth the effort.

Thanks a lot for your time on it!

-- 
En 1975, a los 99 años, muere Leonor Acevedo de Borges. En el velorio, una
mujer da el pésame a Borges y comenta: "Pobre Leonorcita, morirse tan poquito
antes de cumplir los 100 años. Si hubiera esperado un poquito más...".
Borges responde: "Veo, señora, que es usted devota del sistema decimal".
  Jorge Luis Borges, en "Borges habla de su madre". http://2tu.us/2i7d

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Digikam

[Lisandro Damián Nicanor Pérez Meyer]

On Saturday 19 December 2015 23:58:34 Steve M. Robbins wrote:
> On December 15, 2015 02:17:51 PM Lisandro Damián Nicanor Pérez Meyer wrote:
> > Hi Steve! I'm writing you because you said you wanted to maintain digikam.
> > 
> > The last active maintainers where Pino Toscano and Mark Purcell. I think
> > digikam is currently maintained on svn,
> 
> Hi,
> 
> I have got a new version of digikam ready to go, but the svn commit failed:
> 
>   svn: E165001: Commit failed (details follow):
>   svn: E165001: Commit blocked by pre-commit hook (exit code 1) with 
> output:
>   /svn/pkg-kde/hooks/commit-access-control.pl: user `smr' does not have
> permission to commit to these paths:
> kde-extras/digikam/trunk/debian
> ... etc ...
> 
> I found the config file (commit-access-control.cfg).  Who is able to edit
> this for me?

I have just added you, just ping me if you still get problems.

Thanks!

-- 
Bebe a bordo (pero con moderación)

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: More unexpected [k]ubuntu_* stuff in qt repos

[Lisandro Damián Nicanor Pérez Meyer]

On Tuesday 15 December 2015 13:18:57 Jonathan Riddell wrote:
[snip] 
> OK I've set up a clone of Debian's repositories and a hook to tell our
> server to pull when changes are made to them.  I'll work out how to
> change the Plasma mobile images to build from them.  Let me know of
> any problems.

Excellent, thanks a lot!

-- 
All of us have bad luck and good luck. The man who persists through
the bad luck - who keeps right on going - is the man who is there
when the good luck comes - and is ready to receive it.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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