In D27474#676897, @Chipy wrote:

I also want to add my Google Drive account to Dolphin, but running into exactly the same problem.
I don't understand exactly, how I can fix it and which files I have to change.

It'd be very nice, if someone could help me, please.

On a second try it worked though:
https://invent.kde.org/multimedia/kmplayer/-/commit/0d94814d1821fbc11cd6d660c3745576bed0bdfc

Ok, it seems I can't push it to the 0.12 branch anymore (and master is no longer affected by this).

Well, it's probably no longer relevant, but as it's straight-forward (and obvious) anyway, I'm going to commit it still.

Commited with https://invent.kde.org/multimedia/amarok/commit/87c56f8a130b2ddf183922015ce5bb31173bd912

Ok, as it was accepted, and there were no further comments since my last question whether I should change it, I'm just going to commit it now.

One thing I should note though: we do use a patch to fix things on openSUSE currently, but that's not a problem of this change.

Sorry if you were waiting for me.
It's good to go in from my side. I actually built mariadb-connector-c without mysql support here as a test, and it still worked fine.

There were conflicts when I tried to merge the 3.3 branch into master, I think I better leave that to you... ;-)

Use connect() unconditionally.

Actually, callOnTimeout() is just a template that calls connect() anyway:

template <typename ... Args>
QMetaObject::Connection callOnTimeout(Args && ...args)
{
    return QObject::connect(this, &QTimer::timeout, std::forward<Args>(args)... );
}

This caused a crash in openSUSE:
https://bugs.kde.org/show_bug.cgi?id=421566

In D27905#660917, @wbauer wrote:

(I still have to manually "Restart" the resource to actually see the content of the new directory, but that's certainly unrelated to this change).

Sorry, I just noticed that I tested this *without* the patch applied by mistake.
With the patch, the change actually is picked up immediately now and the resource automatically shows the new directory's content.

PS:

In D27905#640353, @poboiko wrote:

but also sometimes KMail crashes with weird Invalid parent message.

That's probably https://bugs.kde.org/show_bug.cgi?id=380171.
Happens here too on a fresh account when starting kontact the first time (subsequent starts are fine).

No objections from my side.

On openSUSE, it doesn't enable MySQLe anymore:

In D28165#634060, @asturmlechner wrote:

In D28165#633145, @wbauer wrote:

The content of my /usr/include/mysql/mysql_version.h (which is just a symlink to mariadb_version.h):

I just went back and installed mariadb-connector-c in Gentoo in mysqlcompat-mode (a soon to be removed option) and interestingly, it does not provide that symlink.

Indeed, the symlink is added in openSUSE's packaging. From mariadb-connector-c.spec:

# add a compatibility symlink
ln -s mariadb_config %{buildroot}%{_bindir}/mysql_config
ln -s mariadb_version.h %{buildroot}%{_includedir}/mysql/mysql_version.h

In D28165#634404, @asturmlechner wrote:

Waiting for @wbauer to confirm it works as well

Yes, the latest version builds fine here (the previous did as well), and the embedded collection still works as well.

This breaks compilation here on openSUSE with MariaDB:

In D27905#630324, @wbauer wrote:

Also, I think this would now always change the resource name (to the name of the directory) when the user reconfigures the storage path, even if it was explicitly set to something (like "My mails") before.
I'm not sure that's really desired?

Also, I think this would now always change the resource name (to the name of the directory) when the user reconfigures the storage path, even if it was explicitly set to something (like "My mails") before.
I'm not sure that's really desired?

PS: AIUI, at least one thing that attemptConfigRestoring() does is trying to give every new resource a unique storage location, something like ~/.local/share/akonadi_maildir_resource_1/ (or ~/.local/share/notes/akonadi_akonotes_resource_1/), by default.

With this change, all new maildir resources are now named "local-mail" and use ~/.local/share/local-mail/ by default, instead of something unique as before.

This is intended for the 3.0 branch, master apparently will need similar (but different) changes (or a bump of the minimum Qt version).

In D24065#627077, @heikobecker wrote:

In D24065#594725, @wbauer wrote:

Maybe it would be good to make a new release as well, now that Python2 is EOL...

I prepared one, if you want to test before it goes public:
https://dev.exherbo.org/~heirecka/telepathy-logger-qt-17.09.0.tar.xz
https://dev.exherbo.org/~heirecka/telepathy-logger-qt-17.09.0.tar.xz.sig

Under that view point shrinking the library seems like a very reasonable thing to do and going with musicbrainz is probably the better choice as there seems to be more interest for it (and thus more/better data one presumes) than for freedb/gnudb. According to google trends anyway.

AIUI, gnudb.org will still be available though, and should be compatible to freedb.org.
http://www.gnudb.org/howto.php

When I committed D27474 to the 19.12 branch, I took the liberty to cherry-pick this as well, so that it will be part of the 19.12.3 release already.
I hope that's ok.

In D27454#620595, @leinir wrote:

In D27454#620593, @wbauer wrote:

Shouldn't this one be pushed to the 19.12 branch as well? (it's currently only in master AFAICS)
After all, it regressed in 19.12.0 (or actually 19.11.80).

It probably does... what's the in-a-nutshell procedure for doing that? (since it's already landed, of course, arc won't do that)

Shouldn't this one be pushed to the 19.12 branch as well? (it's currently only in master AFAICS)
After all, it regressed in 19.12.0 (or actually 19.11.80).

Sorry for the delay.

In D27654#617946, @dfaure wrote:

Wait, you're actually passing the icon of the command being executed now (while the old code would end up using the stuff from konsole.desktop I think)....

AFAICT passing the icon of the command being executed is what is wanted here.
I.e. the konsole window should use the icon of the application menu entry it is being started from.
And the original code (with %i) actually does the same, I verified that with additional debug output.

Use KShell::quoteArg() in case the icon name contains spaces or other special chars.
No idea if that's possible/allowed, but better be safe than sorry I suppose.

Confirmed. I tried out the patch now, and that problem is gone.

Sounds like it would fix https://bugs.kde.org/show_bug.cgi?id=417780 ?

In D27474#614367, @wbauer wrote:

One problem I see already is that this slot is called twice actually, once already *before* the authentification window shows up...

Hm, after thinking a bit more about it, I suppose that means that this patch is probably not a good idea after all.
It would set the name the first time already, while the username may only be available when it's being called the second time (and as the name is not empty anymore, it would not set it again).

In D27474#614003, @leinir wrote:

i think that i'm with @wbauer here - but also Bhushan. This is most definitely a good fallback that i think we'll want in (also, good commenting), but a second patch to pull up more friendly names for accounts where that's possible/make sense/whatnot would also be pretty great. So... accept this one, and suggest further work i think (wow, it's almost like being at uni ;) )

Yes, I do agree with Bhushan too, I'm just not sure that this is the right place to do it.
As signon is used as an abstraction (isn't it?), it somehow feels wrong having to deal with specifics for some provider (or even authentification method) to me.

In D27474#613451, @bshah wrote:

Hm, ideally I'd say we can use https://www.googleapis.com/auth/userinfo.email to retrieve username instead of adding ad-hoc stuff? At this point we do already have a auth data, so we can just make a data request using auth data and get userinfo...

As the new "Online Accounts" KCM in 19.12 actually shows the account type (i.e. info.caption()) in brackets after the name, we could also use a more generic name if preferred, e.g. something like "Account1" (but that should probably be translated as well so is not really suitable for the 19.12 branch I suppose).
I'm open to suggestions here, that's why I added VDG as subscriber.

Committed with https://commits.kde.org/kcmutils/ea7120ed901bf6161bb483ab73211a6491daac8f

This change causes kontact to crash when opening its settings:
https://bugs.kde.org/show_bug.cgi?id=417396

In D16138#573026, @ngraham wrote:

To me it makes sense to ship an internal profile that's equal to the default settings. That's kinda what profiles are, so it's a little odd to have the feature but not ship with one.

There also is a problem with this though, it is not possible to modify system-wide installed profiles due to missing permissions.
I filed a bug report about this: https://bugs.kde.org/show_bug.cgi?id=416752

Maybe it would be good to make a new release as well, now that Python2 is EOL...

In D26479#589636, @hindenburg wrote:

I think this needs a Qt5 and KF5 check; there's no reason to remove in earlier versions.

In D26479#589560, @wbauer wrote:

But konsole's minimum KF5 version is 5.6.0 currently. Maybe this should be increased?

As the minimum Qt version is 5.9.0, I highly doubt that anyone would want to build konsole with KF5 5.6.0 (which is more than 2 years older) anyway...

In D26479#589291, @hindenburg wrote:

Thanks I just noticed this - I wonder when it started or if depends on KF5/Qt5 version.

That warning is new in Qt 5.14:
https://code.qt.io/cgit/qt/qtbase.git/commit/src/corelib/tools/qcommandlineparser.cpp?h=5.14&id=90c86d738e0f36eaa48c7f81f6f5cc035a339d6b

In D26439#588117, @hindenburg wrote:

Thanks nice catch. We are trying to migrate to gitlab; if you can in the future use merge requests.

https://invent.kde.org/kde/konsole/merge_requests

Seems to be fine.
It still finds gmock here on openSUSE and builds successfully.

Unfortunately, this patch won't work as-is anymore because the "new" file is not available for download anymore either:
https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/

In D25019#558919, @mart wrote:

Unfortunately, it has been pushed too near to framework release, so now it has been released, breaking several apps for a whole framework release.

It has only been tagged so far, it's not been released yet.
The release will be next Saturday, maybe you should ask for a respin before that.