Bug#991907: libkpimgapicore5abi1: Kmail randomly prompts to reauthorize via OAuth2 when using Google Workspace accounts

2021-08-04 Thread Ronoaldo J L Pereira
Package: libkpimgapicore5abi1
Version: 20.08.3-1
Severity: important
Tags: upstream patch
X-Debbugs-Cc: ronoa...@gmail.com

Dear Maintainer,

I'm using Debian Bullseye as daily driver for a couple of months,
and recently setup Kmail for both my personal Gmail and Workspace
accounts, so I can have GPG signature and offline e-mail support in
KDE.

The personal account is working great, but after following some
suggestions in [1] for my professional account, I am now prompted
randomly to re-authorize Akonadi with the same OAuth dialog and no
new permission is required.

This issue seems to be fixed upstream by the KDE developers, and
the fix is quite a simple one-liner patch. I have verified the patch
applies against current Bullseye version, and I'm going to try the
fix on my machine.

I have not yet tested the new experimental packages, don't wanto
to bring too many dependencies from unstable now, but I can try
in a VM if that helps!

[1] 
https://www.reddit.com/r/kde/comments/kwsmhb/how_to_add_a_google_workplace_account_to_kde/
[2] https://invent.kde.org/pim/libkgapi/-/merge_requests/17/diffs

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.13.5-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libkpimgapicore5abi1 depends on:
ii  kio  5.78.0-5
ii  libc62.31-13
ii  libkf5kiowidgets55.78.0-5
ii  libkf5wallet-bin 5.78.0-2
ii  libkf5wallet55.78.0-2
ii  libkf5windowsystem5  5.78.0-2
ii  libkpimgapi-data 20.08.3-1
ii  libqt5core5a 5.15.2+dfsg-9
ii  libqt5gui5   5.15.2+dfsg-9
ii  libqt5network5   5.15.2+dfsg-9
ii  libqt5webengine5 5.15.2+dfsg-3
ii  libqt5webenginewidgets5  5.15.2+dfsg-3
ii  libqt5widgets5   5.15.2+dfsg-9
ii  libstdc++6   10.2.1-6

libkpimgapicore5abi1 recommends no packages.

libkpimgapicore5abi1 suggests no packages.

-- no debconf information



Bug#991798: Acknowledgement (qtcreator: No suitable kits found) [worked around])

2021-08-04 Thread Adam Majer

On 8/3/21 8:23 PM, Ross Boylan wrote:

If this is the intended behavior, I suggest the intentions should change.
At a minimum, some clues in a README.Debian would be helpful.
Ross


There are many ways to use Qt Creator. You can use it to make a Hello 
World C application. In this case, you only need GCC or clang compiler 
installed.


You can use it to make a regular C++ application, then you need a C++ 
compiler installed.


If you want Qt, you need to install the Qt modules you want to use. Qt 
Creator is not there to hand-hold you. In reality, if you installed 
upstream version, you would get the entire bundled Qt which Debian 
doesn't provide as a single package.


So, you have two choices here,

  1. find the -dev modules to install that your program uses and 
install them, or
  2. download some Qt version from upstream, and compile it with your 
parameters and then point Qt Creator at it.


#2 is not that difficult - that's what I've done for a decade.

As a regular user, you would expect a program to work mostly out of the 
box. But as a developer, you are expected to receive a little less 
hand-holding here.


So, if you run `cmake` or `qmake` and then `make` in a terminal and it 
works and Qt Creator still fails (after you define your kits, which 
actually should be automatic for system installed libraries), that's a 
bug. If the terminal method also fails, it's not a creator bug.


- Adam