kf5-gwenview on Big Sur

[21stcaveman]

Trying to install gwenview, I ran into an issue with kf5-libkdcraw. Seems like it needs this patch for libraw >= 0.19 : https://phabricator.kde.org/D15132

After applying that patch, libkdcraw was installed just fine. Currently, running into a configure issue with gwenview itself, where it fails to determine if the __GLIBC__ exists. Working to see if I can resolve that issue.

[RJVB]

On Tuesday July 06 2021 09:29:35 Hamid wrote:

Trying to install gwenview, I ran into an issue with kf5-libkdcraw. Seems like it needs this patch for libraw >= 0.19 :

Thanks for the heads-up. I take it then that you installed libraw from the main ports tree?

Currently, running into a configure issue with gwenview itself, where it fails to determine if the GLIBC exists. Working to see if I can resolve that issue.

The GLIBC macro/token you mean? You know where to find the more detailed errors that are logged by CMake I presume? I wonder is this couldn't be because of the compiler optimising certain things away.

Maybe I should simply upgrade the gwenview port. For me it balk on the exiv2 dependency, which might actually be too new. (I rarely use this app, so my build is 4 years old now...)

[21stcaveman]

Thanks for the heads-up. I take it then that you installed libraw from the main ports tree?

Indeed I did, I have libraw 0.20 installed. And yes, the macro/definition. glibc is a dependency, and in the configure step, cmake tries to validate if it is installed by checking that macro, and it fails. I can not find a port for glibc!

Maybe I should simply upgrade the gwenview port. For me it balk on the exiv2 dependency, which might actually be too new. (I rarely use this app, so my build is 4 years old now...)

That, might actually be the best approach. Obviously depending on your time and availability. I believe KDE has a new application which is a replacement for gwenview (or at least does the same thing), named "pix". Maybe worth porting as well.

[RJVB]

I believe KDE has a new application which is a replacement for gwenview (or at least does the same thing), named "pix". Maybe worth porting as well.

I'll have a look, but if it's indeed a new application there's a good chance that it was really written with more recent Qt5/KF5 versions in mind. Backporting a veteran application is rarely a big problem because there's usually very little code that never built against the older dependencies in macstrop.

At some point I'll decide to update the qt5-kde port(s) but when I do it will probably be with the really Mac-specific patches because I am less and less inclined to spend all the time it's going to take to get my Mac functioning the way I want it after upgrading it to a newer OS X version. It's 10 years old this summer, with a 2nd gen i7, I just don't know how justified the update effort is going to be (or worse, if somehow it's going to hasten its demise). Any Mac successor would probably be hardly younger because Apple stopped making computers that interest me not long after 2011, IIRC.

[RJVB]

OK, I updated libraw (to 0.20.2), kf5-libkdcraw and kf5-gwenview (both to 19.08.3). I added an option to build gwenview with support for the FITS image format, FWIW.

[21stcaveman]

Acknowledged, I have upgraded libkdcraw and installed gwenview, no issues. Thank you for addressing this.

I get your point on Apple made computers. I have to use one for work, and before this latest iteration, when I had a 2017 model, I used to just boot it off of a Linux USB-SSD drive, and all was good. However, getting the 2019 model, that was not possible anymore without losing functionality. Being a long time KDE user, I am most productive using that set of tools, and it was a relief to find your ports, making it possible to use KDE5 tools directly on my mac. Thanks for keeping them up-to-date so far.

[RJVB]

However, getting the 2019 model, that was not possible anymore without losing functionality.

Interesting, what subsystem(s) is/are not supported? Yet ... I'd expect that the Linux kernel guys will figure this out eventually, or does it have to do with a form of lock-in?

EDIT: for me it's not so much the OS as the hardware itself. Lack of ports, lack of upgradeability, even lack of space (I'm still a sucker for spinning rust...)

[21stcaveman]

There is a new security chipset, but that did not remain an issue for long. I could boot into linux, if I remember correctly however (been more than a year since I tried last), wireless did not work. Screen resolution had issues, and the touch bar did not work at all (not that big of a deal). A few minor issues here and there as well. For me, wireless was the deal breaker really.

I'm sure linux kernel will catch up soon, if it has not by now. Although, having KDE on macos is growing on me :))

Hardware wise, with everything converting to USB-C, I don't think one will run into too many issues at this point. The 2019 model has 4 USB-C ports. A bit weird to have to use USB-C converters for everything (HDMI, etc), but in the end I personally find it not too hard to manage.

[RJVB]

On Wednesday July 07 2021 10:24:49 Hamid wrote:

For me, wireless was the deal breaker really.

Actually, wireless is still a bottleneck on Linux. There aren't that many chipsets that have actually good Linux drivers, esp. if you want 5Ghz connectivity (and who wouldn't, on a fast machine).

A bit weird there were issues with screen resolution, unless those were caused by Intel's wonky i915 driver? Or does Intel indeed sell

I'm sure linux kernel will catch up soon, if it has not by now. Although, having KDE on macos is growing on me :))

I'm still glad I let myself be convinced to start hacking at the various issues caused by the transition to Qt5/KF5 ... and to figure out how to build the XCB backend for Qt. KDE's Konsole is so-so in native mode but it's become my default terminal emulator under X11 (which is where I do most of my terminal stuff).

Also, in case it's relevant to you: I managed to get the GDrive kioslave working again, meaning you can access your Google Drive in Dolphin. You do need to set up a Google API project which uses the Google Drive APIs, but you can then add up to 100 "test" users to it, download a client_secret_XXXX.json file, install that as indicated and ... you're set.

A bit weird to have to use USB-C converters for everything (HDMI, etc), but in the end I personally find it not too hard to manage.

Well, it's costly and cumbersome, and it's so many additional items that you could lose or that could break. But then I guess the average Mac(book) user doesn't work in places where s/he'd have access to an external screen, or a nice ethernet cable.

It's true though, my 2011 MBP has 2 USB ports, a DisplayPort/Thunderbold port and an RJ45 port. It also still has a FireWire800 port, but in practice I hardly use that one anymore (except when travelling, or making a backup clone). I do still use its SuperDrive though, hehe.

[21stcaveman]

Actually, wireless is still a bottleneck on Linux. There aren't that many chipsets that have actually good Linux drivers, esp. if you want 5Ghz connectivity (and who wouldn't, on a fast machine). A bit weird there were issues with screen resolution, unless those were caused by Intel's wonky i915 driver? Or does Intel indeed sell

Not sure to be honest. Regarding wireless, my 2017 mac with Linux worked perfectly fine, connecting and staying on 5G (granted, I disable 2.4 both at home and work! so not sure about it's switching behavior), no disconnections while roaming, no lag. Best speedtest I had on it was 800 Mbps I believe (802.11ac obviously), which was not too shabby! I have used both mint and CentOS (RIP) on that mac. But I also have had wireless issues on other hardware with same Linux-on-a stick setup, so, maybe Apple wireless hardware in that model was rock solid.

I'm still glad I let myself be convinced to start hacking at the various issues caused by the transition to Qt5/KF5 ... and to figure out how to build the XCB backend for Qt. KDE's Konsole is so-so in native mode but it's become my default terminal emulator under X11 (which is where I do most of my terminal stuff). Also, in case it's relevant to you: I managed to get the GDrive kioslave working again..

I personally am grateful you did! I have abandoned other file managers/terminals/IDEs in favor of dolphin/konsole/kate combination long ago. Gives me all I need, enables me to edit my code and run it on a remote server with ease. Good to know GDrive is working again, I'll give it a shot!! Thanks for the heads up.

Well, it's costly and cumbersome, and it's so many additional items that you could lose or that could break. But then I guess the average Mac(book) user doesn't work in places where s/he'd have access to an external screen, or a nice ethernet cable. It's true though, my 2011 MBP has 2 USB ports, a DisplayPort/Thunderbold port and an RJ45 port. It also still has a FireWire800 port, but in practice I hardly use that one anymore (except when travelling, or making a backup clone). I do still use its SuperDrive though, hehe.

Definitely is. I opted to use a USB-C hub, which charges my mac and gives me all the ports I need while stationary. While on the move though, it becomes a bit cumbersome! SuperDrive, really? :)) Are optical disks still around? been a while since I saw one!

[RJVB]

Good to know GDrive is working again, I'll give it a shot!! Thanks for the heads up.

Be aware that the Google API project approach I described may require you to use the "new account" creation process regularly (once a day?) to re-establish authentication , or else I've missed something somewhere.

SuperDrive, really? :)) Are optical disks still around? been a while since I saw one!

Sure, I got loads of CDs that I still play occasionally, even more that I never digitised yet, and not to mention the movie DVDs that I prefer to keep as such rather than letting them eat HD space. I've also got a number of BluRay disks, but for those I need an external player (and typically an MSWin machine with the PowerDVD software that came with the player).

[21stcaveman]

oh man, brings back memories. I left all my DVDs behind when I moved to the US. Moved all my movies/music to a local Plex server, attached to a 12 TB NAS.

[21stcaveman]

Be aware that the Google API project approach I described may require you to use the "new account" creation process regularly (once a day?) to re-establish authentication , or else I've missed something somewhere.

Last time I used google APIs, I used an OAUTH2 refresh token to avoid this. It's a pain to figure out and implement though...

[RJVB]

On Wednesday July 07 2021 13:13:48 Hamid wrote:

Last time I used google APIs, I used an OAUTH2 refresh token to avoid this. It's a pain to figure out and implement though...

Something like that must be implemented in kio-gdrive, or at least was. Before KDE's "Akonadi Resources for Google Services" app stopped being allowed acces to the Drive APIs , I could log in at will whenever I wanted after having set up my account. Even using "QtKeychain" instead of KAccounts (which is way too much of a pain to package with its numerous dependencies).

Maybe you just need to invoke/use that refresh token more often nowadays, or for an app that not been vetted by Google?

R.

[21stcaveman]

Something like that must be implemented in kio-gdrive, or at least was. Before KDE's "Akonadi Resources for Google Services" app stopped being allowed acces to the Drive APIs ...

Apparently, Oauth2 broke in 2019 for Akonadi : https://bugs.kde.org/show_bug.cgi?id=404990

haven't had a chance to read the entire thread yet, but looks like they got it somewhat working, at least for kmail IMAP.

[RJVB]

On Wednesday July 07 2021 15:25:46 Hamid wrote:

Something like that must be implemented in kio-gdrive, or at least was. Before KDE's "Akonadi Resources for Google Services" app stopped being allowed acces to the Drive APIs ...

Apparently, Oauth2 broke in 2019 for Akonadi : https://bugs.kde.org/show_bug.cgi?id=404990

haven't had a chance to read the entire thread yet, but looks like they got it somewhat working, at least for kmail IMAP.

Yes, and if I look through gdrive-related tickets on BKO it seems others are not having the same issue as I have. Which is really weird ... unless there's a fix for whatever I'm experiencing in more recent libkgapi versions (grrr!) but I can't see how. The rejection happens on the Google's authentication pages, that is, in a call made from libkgapi's src/core/private/fullauthenticationjob.cpp. Besides the backport changes I made to get it to build and run with Qt 5.9 (which also involve not using a std::unique_ptr instance) I see no relevant differences between the latest and the 20.11.80 versions of that file.

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=439639

[RJVB]

Well, big thumbs-up for the kio-gdrive maintainer(s) ... turns out KDE is using new Google Cloud credentials corresponding to a new "project", and they never updated the QtKeychain backend to use those credentials.

With that it seems the token refresh works as it should, but I've kept my support for using a private set of credentials.

[21stcaveman]

With that it seems the token refresh works as it should, but I've kept my support for using a private set of credentials.

Man, you are a machine! Does that mean we get back one-time auth (with refresh token) with your latest commit?

P.S. Well, It works for me now! added GDrive to dolphin, granted access and BOOM, it works!

[RJVB]

Man, you are a machine!

I wish I were :)

Does that mean we get back one-time auth (with refresh token) with your latest commit?

From the looks of it! KAccounts uses 2 additional query items for the oauth2 connection URL , in particular access_type=offline, claiming that that is requires to get a refresh token, but I seem to be getting one just fine.

Note that the most complicated bit of this fix was figuring out where KAccounts gets its connection parameters from ... and then getting a new set of eyes to detect the typo that caused my git clone command to fail ... repeatedly ^^