Accessing Google Contacts and Calendar

[Michael Schuerig]

In the past, KDE/Akonadi was able to access Google Contacts and Calendar by 
means of the resources contained in the package akonadi-kde-resource-
googledata.

Some time ago those resources broke and it was, to the best of my ability, 
impossible to connect them to a Google account. Just now I checked if 
something had changed in the meantime. As far as I can tell, it's still not 
possible to save the access credentials logging in at Google provides in the 
resource configuration.

However, what surprised me is that akonadi-kde-resource-googledata doesn't 
appear to exist anymore for amd64. Is there a replacement I haven't found?

Michael

-- 
Michael Schuerig
mailto:mich...@schuerig.de
http://www.schuerig.de/michael/

Bug#881542: qtcreator: Qt Creator requires Valgrind and gdb-python2 to debug programs but neither package is listed as a dependency or even as a recommendation.

[Rui]

Package: qtcreator
Version: 4.2.0-1+b1
Severity: normal

Dear Maintainer,

Qt-Creator requires Valgrind to debug and profile code.  Yet, no package is 
listed as a dependency or even a
requirement.


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

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

Versions of packages qtcreator depends on:
ii  libbotan-1.10-1   1.10.16-1
ii  libc6 2.24-11+deb9u1
ii  libclang1-3.9 1:3.9.1-9
ii  libgcc1   1:6.3.0-18
ii  libqbscore1.7 1.7.0+dfsg-4
ii  libqbsqtprofilesetup1.7   1.7.0+dfsg-4
ii  libqt5concurrent5 5.7.1+dfsg-3+b1
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5designer5   5.7.1-1
ii  libqt5designercomponents5 5.7.1-1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5help5   5.7.1-1
ii  libqt5network55.7.1+dfsg-3+b1
ii  libqt5printsupport5   5.7.1+dfsg-3+b1
ii  libqt5qml5 [qtdeclarative-abi-5-7-0]  5.7.1-2+b2
ii  libqt5quick5  5.7.1-2+b2
ii  libqt5quickwidgets5   5.7.1-2+b2
ii  libqt5sql55.7.1+dfsg-3+b1
ii  libqt5sql5-sqlite 5.7.1+dfsg-3+b1
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libqt5xml55.7.1+dfsg-3+b1
ii  libstdc++66.3.0-18
ii  qml-module-qtqml-models2  5.7.1-2+b2
ii  qml-module-qtquick-controls   5.7.1~20161021-2
ii  qml-module-qtquick2   5.7.1-2+b2
ii  qtchooser 63-g13a3d08-1
ii  qtcreator-data4.2.0-1

Versions of packages qtcreator recommends:
ii  clang  1:3.8-36
ii  gdb-python2 [gdb]  7.12-6
ii  konsole [x-terminal-emulator]  4:16.12.0-4
ii  make   4.1-9.1
ii  qmlscene   5.7.1-2+b2
ii  qt5-doc5.7.1-2
ii  qt5-qmltooling-plugins 5.7.1-2+b2
ii  qtbase5-dev-tools  5.7.1+dfsg-3+b1
ii  qtcreator-doc  4.2.0-1
ii  qtdeclarative5-dev-tools   5.7.1-2+b2
ii  qttools5-dev-tools 5.7.1-1
ii  qttranslations5-l10n   5.7.1~20161021-1
ii  qtxmlpatterns5-dev-tools   5.7.1~20161021-3
ii  xterm [x-terminal-emulator]327-2

Versions of packages qtcreator suggests:
ii  cmake  3.7.2-1
ii  g++4:6.3.0-4
ii  git1:2.11.0-3+deb9u2
ii  kdelibs5-data  4:4.14.26-2
pn  subversion 

-- no debconf information

Re: Kdepim is a pending upload?

[Sandro Knauß]

Hey,

> I wonder, why a pending upload now needs more than 2 month to be really
> uploaded.

No there are no "real" reasons, why it takes that long staying in NEW 
queue[0], except than human capacity of the FTP masters to get through the 
list of all new packages and approve/decline them. So the acceptance of the 
packages is not in our hands :( 

> Does anybody know, when we (users not afraid to try ' debian
> experimental') can use kontact, kmail, kaddressbook, etc again. 

you can use the packages from experimental, but there are packages inside NEW 
queue are not accepted inside Debian, so you have to build them on your own. I 
don't know any way how you can reach the packages inside the NEW queue.

> Do you need help? Or do we have to compile on our own, if we want nearly 
actual versions of the most valuable kde packages and not be stuck in the 
depth of nowhere. In my opinion the best way to loose early adopters, the best 
testers on this planet.

Well we always need manpower - the Qt/KDE Team in Debian is quite small, so 
the workload is sometimes quite big. But unfortunately for this specific issue 
"to get KDE Application 17.08 to Debian", we can't do anything except helping 
the FTP masters (Don't know if and how they need help) or being patient.

Just to make it clear, we are not happy with the current situation and I share 
the point, that getting KDE Application 17.08 to unstable fast would be great. 

There is also a thread about this at the debian-kde ml:
https://lists.debian.org/debian-kde/2017/10/msg00039.html

Best regards,

sandro

[0] https://ftp-master.debian.org/new.html


signature.asc
Description: This is a digitally signed message part.

Re: Kdepim is a pending upload?

[Sandro Knauß]

Hey,

> I wonder, why a pending upload now needs more than 2 month to be really
> uploaded.

No there are no "real" reasons, why it takes that long staying in NEW 
queue[0], except than human capacity of the FTP masters to get through the 
list of all new packages and approve/decline them. So the acceptance of the 
packages is not in our hands :( 

> Does anybody know, when we (users not afraid to try ' debian
> experimental') can use kontact, kmail, kaddressbook, etc again. 

you can use the packages from experimental, but there are packages inside NEW 
queue are not accepted inside Debian, so you have to build them on your own. I 
don't know any way how you can reach the packages inside the NEW queue.

> Do you need help? Or do we have to compile on our own, if we want nearly 
actual versions of the most valuable kde packages and not be stuck in the 
depth of nowhere. In my opinion the best way to loose early adopters, the best 
testers on this planet.

Well we always need manpower - the Qt/KDE Team in Debian is quite small, so 
the workload is sometimes quite big. But unfortunately for this specific issue 
"to get KDE Application 17.08 to Debian", we can't do anything except helping 
the FTP masters (Don't know if and how they need help) or being patient.

Just to make it clear, we are not happy with the current situation and I share 
the point, that getting KDE Application 17.08 to unstable fast would be great. 

There is also a thread about this at the debian-kde ml:
https://lists.debian.org/debian-kde/2017/10/msg00039.html

Best regards,

sandro

[0] https://ftp-master.debian.org/new.html


signature.asc
Description: This is a digitally signed message part.

Processed: Re: Bug#880884: marked as done (qtav: Adapt to libva 2)

[Debian Bug Tracking System]

Processing control commands:

> reopen -1
Bug #880884 {Done: Pino Toscano } [src:qtav] qtav: Adapt to 
libva 2
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions qtav/1.12.0+ds-3.

-- 
880884: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880884
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#880884: marked as done (qtav: Adapt to libva 2)

[Sebastian Ramacher]

Control: reopen -1

On 2017-11-10 21:51:03, Debian Bug Tracking System wrote:
> Your message dated Fri, 10 Nov 2017 21:49:51 +
> with message-id 
> and subject line Bug#880884: fixed in qtav 1.12.0+ds-3
> has caused the Debian Bug report #880884,
> regarding qtav: Adapt to libva 2
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
> 
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
> 
> 
> -- 
> 880884: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880884
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Sun, 5 Nov 2017 07:41:36 -0500
> From: Jeremy Bicha 
> To: submit 
> Subject: qtav: Adapt to libva 2
> Message-ID: 
> 
> 
> Source: qtav
> Version: 1.12.0+ds-2
> Severity: serious
> 
> The libva transition has started [1]. qtav has hard-code dependencies
> on old libva libraries.
> 
> I don't know if it would help, but you should check if you can use dh_libva 
> [2].
> 
> One more thing: could you consider only building qtav on architectures
> where i965-va-driver is available (amd64 and i386)? I can file a
> separate bug for that if you want.
> 
> [1] https://bugs.debian.org/880355
> [2] https://manpages.debian.org/dh_libva
> 
> Thanks,
> Jeremy Bicha

> Date: Fri, 10 Nov 2017 21:49:51 +
> From: Pino Toscano 
> To: 880884-cl...@bugs.debian.org
> Subject: Bug#880884: fixed in qtav 1.12.0+ds-3
> Message-Id: 
> 
> Source: qtav
> Source-Version: 1.12.0+ds-3
> 
> We believe that the bug you reported is fixed in the latest version of
> qtav, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 880...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Pino Toscano  (supplier of updated qtav package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> We believe that the bug you reported is fixed in the latest version of
> qtav, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 880...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Pino Toscano  (supplier of updated qtav package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Fri, 10 Nov 2017 22:36:00 +0100
> Source: qtav
> Binary: libqtav1 libqtavwidgets1 libqtav-dev libqtav-private-dev 
> qml-module-qtav qtav-players
> Architecture: source
> Version: 1.12.0+ds-3
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Qt extras Maintainers 
> Changed-By: Pino Toscano 
> Description:
>  libqtav-dev - QtAV development files
>  libqtav-private-dev - QtAV private development files
>  libqtav1   - QtAV library
>  libqtavwidgets1 - QtAV Widgets module
>  qml-module-qtav - QtAV QML module
>  qtav-players - QtAV/QML players
> Closes: 880884
> Changes:
>  qtav (1.12.0+ds-3) unstable; urgency=medium
>  .
>* Team upload.
>  .
>[ Steve M. Robbins ]
>* Update standards-version to 4.1.1.  Add Vcs-* fields.
>  .
>[ Pino Toscano ]
>* Remove manual library and va-driver dependencies. (Closes: #880884)

I am afraid that this change is not enough. qtav still needs to be ported to the
new libva. Currently it links libva2, but dlopens libva.so.1, libva-x11.so.1,
and maybe others. It would now need to dlopen libva.so.2, libva-x11.so.2, and so
on. Hence I'm reopening this bug.

Cheers

>* Specify the buildsystem as qmake.
>* Use dh_auto_configure in its override.
>* Link in as-needed mode.
> Checksums-Sha1:
>  f1ad877aea60819a5992ec8461d79a61ad1c5979 2513 qtav_1.12.0+ds-3.dsc
>  

Re: Can we get a simple fix for #864927 into unstable/testing please?

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El 11 nov. 2017 6:14 p.m., "Steve McIntyre"  escribió:

On Sat, Nov 11, 2017 at 03:25:29PM -0500, Lou Poppler wrote:
>This seems to be OK as of the weekly testing live build of Nov 5, 2017,
with
>plasma-desktop-data (4:5.10.5-2)
>
>That live build boots OK here.

kde-l10n has been removed from testing, and that looks to have solved
the live build problem. Doesn't like the best of ways, maybe?


I *think* there are stuff in NEW still preventing Maxy from uploading to
unstable.